Posts by Clemens Musterle

Glad it works for you!

Should also work with other formats that support an explicit alpha channel (like png or tga).

Quote from amendoim

Would the monochrome displacement be copied into the Alpha channel?

Exactly like that.

I'd be very interested in the log files comparing loading between 2.9 and 3.0 version. Loading times should be reduced signficantly with this version due to the multi-threaded texture loading (unless your system is I/O bound). We also did thorough performance benchmarks and have not measured any slowdowns compared to 2.9. If you have a project file that runs particularly slower with 3.0 we're of course also interested in that.

Hi SMT and welcome to our forums!

You might want to try and reduce the ambient brightness (Atmosphere settings). Also please make sure you're not using 100% white as your wall color. Such bright colors don't exist in the real-world and therefore look off in physically based renderer as Enscape.

PBR color reference charts like this one might help adjusting your materials:
https://community.acescentral.…a753aa5b36859cd11464.jpeg

Did you disable the so called 'Restmode' in the settings? Usually, with Restmode enabled, Enscape will stop updating as long as you don't move the camera around, also once the window loses focus the same should apply (you can see if Enscape is in restmode when the water waves or video textures stop moving). When Enscape is in Restmode the gpu should draw a lot less power than usual - if this still consumes 50W depends on the GPU I guess, difficult to say in general.

Hi Grasinko

please send Feedback with log files, so that we have all the needed information regarding which Enscape version you're on, and what kind of hardware it's running on.

There are limitations for the skybox resolution, but it should still look a lot crisper than on your rendering. Here's what I get with the file you've provided:

Enscape does use physical lighting units and calculates the rendering in high dynamic range. I'm not sure what the complete video is about, but hope that answers the question here. To translate that "raw" lighting information into an image suitable for display on your screen the rendering is tone mapped in one of the last stages based on your exposure and also your shadow/highlight settings. As DeKoetsier mentioned you can do some minor tweaks to the result with these settings.

If you want to have really fine tuned control over the tone mapping you can simply export your rendering as an HDR image and do the tone mapping e.g. in Light room or similar software to fine tune everything to your liking.

In that case there's a global toggle for that in the General settings:

Which CAD software are you currently using? When using a CAD that supports the Enscape material editor, e.g. Sketchup you can overwrite the wind settings for each water material individually. That should solve the mentioned issue already.

This looks like some sort of self-shadowing - is this tree an Enscape asset? If not, can you make sure that the trunk geometry isn't somehow duplicated in place?

Amazing work Love the hologram effect! I assume you used a video texture in combination with a cut out mask there?

As previously mentioned this preprocessing time also depends on how long Enscape has been running - we're actually utilizing multiple cores for these steps, so CPU utilization after starting Enscape should usually be higher.

Once a rendering is triggered, this is reduced to the models that need preparing for the next frame - if everything was already processed in the background previously this shouldn't take too long. Utilization might not always be optimal though, as different models might have significantly different preparationt time, based on their topology.

I get the sentiment of not making full use of the available hardware power, but overall in my experience Enscape does scale quite well with the available hardware, especially GPU. So especially your walkthrough framerate should increase very notably with a RTX3080, but also rendering times in general, eventhough in total probably not in the same relation due to the constraints mentioned.

Quote from zaklina

This Enscape is plugin for Revit 2021.

Hi zaklina

based on that information and looking at the screenshot you provided this perceived brightness is probably due to the grass texture you're using, which I believe is still shipped with Revit. It is known to be way too dark, which in return let's other assets/textures appear too bright, due to how auto-exposure works. Please try to find a different grass texture to compare the vegetation assets with and see if that helps!

Hi Julio

thanks for your report! Happy to hear that you're having great performance on the RTX 3090 (and I guess you're also lucky to have received one already ).

We're evaluating DLSS 2 for Enscape in the future, it does however require some larger rewriting of the renderer to be able to improve performance as it's only available on Vulkan and DirectX12 graphics APIs. So I can't give you an exact date when it's going to be released yet.

When rendering a video there are more things that come into play here For the ray tracing to work we have to do some geometry preparation work that is also done on a separate CPU thread. Since with RTX we consider a lot more geometry this means that these preparation steps take more time and this depends heavily on the scene geometry as well. For videos we have to update these acceleration structures every few frames so that you have smooth transitions when geometry is added/removed from the ray tracing acceleration structure - for image renderings this is done once at the start.

So in that case it's absolutely possible that rendering speed is actually limited by these preparation steps and not GPU rendering speed. To do a more "fair" comparison of GPU utilization you should probably do an image rendering, but wait until you can actually see an image (which means the preprocessing should be done).

What makes these kinds of timing comparisons even more difficult is, that some of the geometry preprocessing is happening continuously in the background (for quicker updates during walkthrough) - so depending on how long Enscape has been started in a particular scene more or less geometry might already be preprocessed and thus affecting the total time that the video/image rendering takes

Are you sure you're testing the exact same scene with the exact same settings?

What I can confirm is that with RTX enabled you won't get close to 100% load - that's simply due to the way RTX raytracing with Vulkan is currently integrated into the Enscape OpenGL renderer. As a simplification you could say that the GPU has to wait a small amount of time everytime when we switch from OpenGL to Vulkan for raytracing and then back to OpenGL - this synchronization also affects scheduling and therefore it's difficult to get close to 100% efficiency. That doesn't necessarily mean that the performance is worse though - when the raytracing tasks finish much faster than the synchronization overhead it's still a net win, also RTX allows much more geometry to be traced.

Another thing to consider, what kind of scene are you testing on? In the above screenshot it looks like there's mostly sky visible. That won't keep the GPU busy enough. For capturings there's added overhead due to GPU - CPU synchronization, so the GPU load will usually be lower than during walkthroughs (with Restmode disabled). We have in fact added some more synchronization for capturing to reduce driver time outs when rendering very high resolution images, this could affect GPU load, but won't be really noticeable when it comes to rendering times.

With a medium sized scene I can easily get a Quadro RTX 5000 to 99% GPU load on 1080p. With RTX enabled load is considerably lower.

We're currently busy on reducing the added Vulkan interop overhead, so in future versions the efficiency with RTX enabled will definitely improve.

Hope that clears up some of it

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

As already discussed here, we're aware that the current integration in Revit lacks fine grained control - we'll improve upon that in an updated version.