Posts by Clemens Musterle

    comcasa good question! Actually yes, depending on the resolution and the number of textures we need to resize this might add substantially to the loading time.

    As we speak, we're optimizing this for the next release to run in parallel, so that you can navigate through your model while textures are still beeing processed.


    But if you know beforehand that you don't require the textures to be in full resolution you can downscale them before hand and this will definitely speed things up either way. If you look into the log files (%AppData%\Roaming\Enscape\Data\Logs) you can actually see which textures are getting resized to what resolution. :)

    Hi bsfranza


    the downsampling to 2k is gone for several releases now. We're now evaluating the scale of the textures in the scene and only do downsampling if the resolution is vastly too large for it's usage (e.g. using a 4k texture for a piecer of paper) or if we can't fit all the textures into your graphics card's memory.


    Do you have an example where you think your textures get downscaled too aggressively?

    Hi grant & welcome to our forums!


    That's a very cool rendering already - the custom skybox fits quite nicely! Some suggestions from my side:

    - set the opacity of the window glass materials to 0% - that will make the windows looks more realistic (if you're not aiming for that frosted glass look)

    - the sun light appears quite harsh - maybe you can try reducing the intensity a bit (Atmosphere tab -> Sun brightness) to better match the surroundings

    - maybe add some color variance to the building design? it looks all very white right now ;) To get a more realistic look you can also experiment with roughness textures - they can add a lot of detail to the surface appearance and will thus reduce that "consistent" CG look of materials.


    Hope that helps! Looking forward to your progress :thumbup:

    I'm not sure what Lumion does regarding reflection maps. After loading a normalmap (which should be an RGB image file) in Photoshop (or similar) you'll need to add an alpha channel. Then copy the greyscale displacement map into this channel. You can safe it in every image format that supports transparency (aka alpha channel) and can be used by Enscape, such as tga, tiff or png.

    The article mentions

    Quote

    AMD will support all ray tracing titles using industry-based standards, including the Microsoft DXR API and the upcoming Vulkan raytracing API.

    But generally yes, I do expect that they've internally already implemented support for it or are at least currently working exactly on that. However there's nothing available in that regard yet - we'll probably get more updates on that closer to the actual shipping date of the new gpus I assume.

    Currently Enscape does rely on a Nvidia specific Vulkan extension for RTX raytracing support. However in the meantime there exists a basis for a cross vendor extension for hardware accelerated raytracing in Vulkan (https://www.khronos.org/blog/ray-tracing-in-vulkan). As the upcoming 6X00 GPUs from AMD are supporting DX12/DXR raytracing, we do expect AMD to implement the Vulkan ray tracing extension as well at some point. In that case Enscape users with an AMD 6x00 GPU will benefit from hardware acceleration, just like Nvidia RTX users. Of course no one knows how the performance of those two compares in that regard yet.


    Hope that clears up some of it :)

    @Clemens:


    maybe there's something different with the heightmaps I am using? (although I tried multiple different providers).


    Could you perhaps give this material a shot (free download): https://www.poliigon.com/texture/bricks-01

    So I had a look at this example and it's basically two things coming together:

    1) What they offer as a displacement map is not really suitable. It's a very poorly post processed greyscale version of the diffuse texture (On a side note: What is offered on this site are not proper PBR textures. For PBR rendering it's important to use an Albedo texture without any lighting information in it as a base color. They're offering diffuse textures that still contain lighting information such as self-shadows).

    2) The current Revit integration via threshold of the bump amount doesn't allow for fine grained displacement control, which could avoid getting completely off the charts results with these kind of low quality displacement maps. I think we should remap the value range above the threshold, so that you can also utilize displacement mapping with an amount of only 1 in Revit.



    1. No, there's no direct way to control these. The self-shadowing is very limited, as it's just an effect calculated in screen space based on the normals, since the displacement doesn't actually modify the geometry.

    2. It depends, there's a slight blur in the pre-processing of the displacement map to avoid precision artifacts (banding) when loading low precision (8bit) displacement maps. This could explain that. Ideally you'd only have that kind of micro detail in the normalmap, you can achieve that by combining an existing normalmap with the displacement map into a single RGBA texture and load it as displacement. We'll improve upon that in later versions for an easier workflow.

    preview.6 camera crashes when rendering. It means that the preview image is normal but the image is stuck to the ground, I'm not good at English so I use google translate

    Thanks for your report. I assume two-point perspective was enabled? We've received reports about that issue and have fixed it in the meantime. It will be fixed for the release or shortly after it in a hotfix.

    Auto-contrast should not be requried anyore, we're doing that now by default. I can't really reproduce those results:


    Especially irritating for me is, that in the above screenshots the heightmap seems to be completely inverted in the displacement shot, which is kind of curious.

    Hi,


    2.9+6 has a big impact on materials for me. Any materials that have a bump map of more than 499 seem to be multiplied by some factor.


    I've attached some images ; one with a bump of 499 and the other with a bump of 500.

    500 is indeed the threshold for Revit materials to switch to displacement mapping. However the result still shouldn't look like the posted above. Can you share a project file for us to reproduce?

    The render panorama in 2.9 is extreme slow!

    beta 6 seams to be a bit faster than beta 4, but still much slower compared to previous versions

    We actually did look into this very recently and could not measure any notable performance loss compared to 2.8. Which version are you comparing the Preview with? Can you do a comparison run with both versions and send us feedback with log files afterwards? This will help us to get clear numbers and in case it's connected to a specific setting.

    I just would have loved if the Animated Textures (and water/ wind) could have kept playing even when keeping the camera (view) stationary. But it's not a train smash.

    There's actually a setting for that now in the General Settings/Performance called 'Restmode'. It'll keep animations playing as long as the renderer window is in focus.

    Hi Ted,


    thanks for your report! Happy to hear you're enjoying the video textures feature :) Which Preview version were you using when this happened? We've recently fixed a bug for Preview 5 that should solve similar behavior. If it still occurs in Preview 5 could you please send us your log files via the Feedback button. That might helps us figuring out what was going on!


    Thanks in advance!


    edit: I can now reproduce the behavior (also with the latest build). We'll investigate!

    The LOD naming only has an effect if it's applied to a a geometry (group) in your 3d application. The filename or texture names don't have an effect.

    Hi Julio Puccini


    thanks a lot for your report! It looks like you've indeed accidentally discovered our LOD (level of detail) system for assets. I assume the table geometry does contain the character sequence "lod"? This was primarily designed for our internal assets of course, but is still part of the assets infrastructure. We'll have to check how we're going to handle that to avoid accidental LOD fadeouts like in your case.

    You can workaround that easily by renaming the geometry to something else than "lod". If you want you can experiment with it of course, by defining the exact LOD range "lod1" displays the geometry only for the clostest LOD distance, "lod1-2" shows the geometry for the 1st and 2nd LOD distance, "lod2-3" would show the geometry only for the 2nd and 3rd LOD distance, which means it's invisible for the 1st LOD distance. As you can see by combining different geometry with different LOD-tags you can control which geometry is visible at which distance ;)


    Edit: After checking back internally, we're going to disable the implicit LOD feature for the external Asset Editor for the current release, until there's a more transparent/user friendly implementation.