Posts by Clemens Musterle

    I would like to ask if I did something wrong in this situation?

    While both Bump and Displacement maps are greyscale images of height information they usually contain a different level of information. Bump maps usually contain highly detailed/small surface bumps, while displacement maps should only contain more significant height information on a much coarser level. Therefore it's usually not a good idea to simply use a bump map for displacement, as it will look way too noisy. That's one of the reasons you'll ultimately have to explicitly select the effect in the material editor.

    Also some disclaimer on the current Preview version: We're currently not making full use of displacement maps with 16bit precision, which can lead to some visible banding effects in some scenarios. This is of course also going to be fixed for the final release. In the meantime it's good practice to ensure your displacement map uses the full value range, meaning there's maximum contrast between the lowest and highest height level in the image.

    Ah. That's a bit disappointing.

    I understand why Revit hasn't gotten the Enscape material editor yet, but this was exactly what I was afraid of when it was announced that Revit would be the only platform without an enscape material editor: more and more great features being added to the material editor while Revit users are left with a subpar experience. We see a similar problem with grass and water control.

    I'm not sure what the best solution is here, but please don't forget about us Revit users.

    Rest assured, we're very much aware of that situation and not really happy with it ourselves. However I can assure you that there won't be any difference on a functional level regarding displacement maps with what you can achieve with the Revit material editor, even though it will require some workarounds as mentioned before.

    We did not forget about the Revit integration, but also don't want to stall the rest of the Enscape rendering advancements because of current limitations in only some of the plugins. Improvements/new features of the renderer are usually completely independent from any CAD integration, so it's not like we're working on Sketchup-only solutions and leave the Revit part out. ;) It's usually the other way round: We're developing something for the renderer and then we'll have to make it accessible in the Plugins - for some of them that's straightforward and in some of them we have to overcome a lot of hurdles, so it might take longer. I don't think it'd be fair to hold back those improvements for the other CADs, just so that we can say there's equality on a user interface level for all CADs. Hope that's understandable ;)

    Revit users will most likely get an "implicit" integration similar to the approach in this Preview (maybe with the option to enforce it via certain filename suffixes) for the 2.9 release.

    Yes, displacement will of course also work on (custom) assets. :)

    Yay for displacement (parallax) mapping and continuous animations as an option!

    The continous animation is such a small feature, yet it will provide a much more immersive client experience in standalones. :thumbup: Displacement mapping is also a great addition - improved visual fidelity without any serious performance impacts? Yes please! 8)

    Happy to hear that :)

    Just keep in mind: The feature is not 100% done yet. It'll get a fully fledged material editor integration and details like support of 16bit heightmaps and self-shadowing are not part of the Preview yet ;)

    Hi jtubb

    sorry, no announcements to make yet in that regard. Of course you can expect much improved performance over the previous generation as usual. It's an incremental improvement of the RTX 2000 series - ray tracing can be expected to be noticeably faster, but that might not always be the bottleneck. As of now there aren't any RTX 3000 series specific features planned - we will increase the usage of HW accelerated ray tracing for future features, but that's not tied to a certain generation of RTX HW.

    Hope that answers your question at least somewhat ;)

    Hi, you might want to check (reduce) your Bloom and Chromatic Aberration settings, those effects might contribute to a little blurry result. Other than that I personally can't see anything wrong regarding the image quality here. Of course you can also increase the output resolution and see if that helps.

    It's going to be accessible via the heightmap/bumpmap slot of Revit materials. Once you specify a depth amount above a certain threshold Enscape will utilize the displacement mapping technique to provide a much better depth illusion than normal mapping alone.

    Hi Hillmeister

    with the upcoming 2.9 version Enscape will support displacement mapping, so this will cover the heightmap already :) As for Ambient Occlusion - this is likely not going to happen, as Enscape does a full global illumination calculation already (including screen space ambient occlusion for small details), so a prebaked Ambient Occlusion map would look off and result in worse quality.

    Those baked AO maps are usually intended for game engines without proper real-time global illumination.

    It's going to be a technique similar to parallax occlusion mapping (but higher quality). We evaluated (gpu accelerated) tessellation based displacement, but deemed it unfit for our Archviz use case, as we don't have much control of the incoming geometry data (and its mesh) and this will lead to poor results with tessellation.

    Thanks for your reports. Unfortunately we missed that the density of low cut grass was reduced so significantly during our tests. It's neither a limitation of the new texture, nor is it related to the carpet material or the animation. We'll adjust this to reflect the behavior of the previous version more closely.

    In case you find the animation distracting you can always reduce or disable the wind strength in the atmosphere settings.

    Hi pibuz

    thanks for the report. What's happening here is that Enscape is trying to determine the optimal influence limit (or radius) for each light source by shooting a number of rays in it's surrounding and then we evaluate their length. This allows us to reduce the influence radii for lights in very enclosed spaces on the one hand and on the other hand it allows to enlarge the radii enough in more open spaces, that the light still reaches nearby surface (think street lights for example).

    In your example the light source is very much constrained in each direction by opaque geometry, therefore we determine a very low influence radius, which you can see for the light on left. As the radius estimation is a stochastic process (taking random samples) the results may vary depending on the surroundings, thus the different result for the light on the right.

    For the effect you're trying to achieve here I'd personally suggest to use emissive surfaces instead of actual light sources. There are other downsides (as they might not always be considered, e.g. from afar), but the other limitations mentioned above and also harsh shadows don't apply to them.

    Hope that helps :)

    We do hope to improve direct light calculation (& shadowing) for area lights with ray tracing based techniques in the future, but this is probably going to take a few release cycles (& will probably require more advanced hardware accelerated ray tracing than we have available now).

    If the opacity <95% the material will currently not receive any light from artificial light sources, therefore it looks dark during night time. For curtains like that I'd definitely go for a 100% opaque material with a cutout texture (like you already did) for best results.

    It looks like you're using 100% white (255, 255, 255) or close to it as albedo color. Such whites don't exist in the real world and therefore look implausible in a physically based renderer like Enscape. Even white ceramic would only be something like 80% white, please have a look at this chart for reference (note: relevant for the material editor are the sRGB values):

    Hope that helps! :)

    We know correct physically based material setup is not always intuitive, which is why we plan to add some material parameter validation feature in the future.

    Very difficult to say what's going on based on the screenshots. But auto-exposure would explain the phenomenon: While the bright emissive surfaces of your lights are in direct view, auto exposure is reduced and therefore the brightness of other parts of the image reduced. You can try to disable auto-exposure to see if that applies.

    I'm not seeing anything that would classify as a light leak though.

    Hi Joegeorge

    yes, there will be some difference in quality. If you're buying a RTX capable graphics card you'll see some slight improvement of global illumination quality (more geometry visible in off-screen reflections and more precise indirect lighting). Also in case you've maxed out the available memory on your GTX1060 before by using a lot of textures in your scene you might also see some improvement in texture resolutions. However these improvements are probably rather subtle - as tagounits samir already said, scene content (models, textures, lighting) will have a much larger impact on your rendering quality than this.