Posts by Clemens Musterle

Quote from andybot

Great to hear there are more improvements planned! I did observe a noticeable increase in render times with this latest update. Obviously, going from like 30 seconds to 50 is nothing like the increase would be on a 15 minute rendering, but it does give me a slight concern that things like video rendering may end up taking quite a bit longer with these increases in render quality. My ask is if it's possible to add some finer control over render settings as these improvements come on line.

For example I just timed a 4k render of a kitchen interior with some stainless steel appliances and the render time was 78 seconds on Ultra. It was 55 seconds on High. I'll have to check what it was in 3.4 but I don't recall renders ever taking over a minute. I know people keep asking for that "give it everything you've got" quality settings, but I wouldn't want to mess up the current speed/quality tradeoffs that make Enscape such an incredible tool.

**EDIT: 11 seconds on "Ultra" in 3.4 -- This is going to be a serious issue if this is the direction render times are headed. **

It's definitely not our intend to go into that direction of just paying for increased quality with x-fold rendering times. Which is exactly why we've compromised on things like reflection quality before instead of "cranking everything up" to what's technically possible.

Keep in mind this is still a Preview release and thus a work in process. We'll make sure that rendering times will be comparable to prior releases even with the improved GI quality for the final release.

Thanks for your feedback - happy to hear that the improvements are well received

Regarding specular materials in reflections: We first wanted to focus on achieving consistent results - getting mostly rid of the clear "cut-off" line between screen-space reflection part and ray-traced reflection intersections, which could sometimes ruin the overall impression.

Ray traced ("off-screen") reflections had completely diffuse/matte materials in previous versions already - specularity in reflections could only be observed in the parts where the reflected surface was visible on screen (and this specular reflection was actually not correct, even though often it did look convincing enough I guess).

We're already working on further improvements for the upcoming release though - so the topic of better specular materials in reflections is still on the table

Quote from bsfranza

hi there,

i absolutely love the fix of indirect lightning in mirrors! super! finally

now if you could bring back some additional bounces for mirrors in mirrors we are there

i think that in older versions there where more bounces for mirrors in mirrors, or?

edit: just noted then when switching quality modes, while updating/refreshing the mirrors inside mirrors show correctly, its only when its "done" final image that the correct reflections vanish !?

i hope you can this soon

best, franza

Display More

Thanks for your feedback!

The previous mirror in mirrors rendering worked only if they both were in screen space (and thus they were also not entirely correct). We removed that to have more consistent lighting results in mirror reflections, but we'll evaluate adding additional mirror bounces before the release.

florin_nistor this particular issue has been fixed with 3.4 - therefore 3.4 and newer versions should not show this behavior anymore.

Here's the file you've attached with and without the glass - you can clearly see the reflections when the glass is present.

Hi Ren these "trails" behind the objects in the reflection are the areas where the reflection could not be resolved with on-screen information and Enscape falls back to ray tracing. Currently only the front-side material in Sketchup is considered for shading of the ray traced reflections. Please make sure that you're using the same material on the front & backsides of your geometry - then the difference should be a lot less visible.

This combination of so called "screen space reflections" and ray traced reflections hasn't been changed in 3.4. But we've improved the amount of geometry that can be considered for ray traced reflections.

Hope that helps!

Quote from andybot

I just tested it out.... um, you all seem to have over-corrected. Now the image isn't showing up at all in the reflection. (Please test against the file I uploaded earlier.)

As odd as it may sound, please test it in your regular scene with more geometry. Then everything should look as expected.

We actually came across the same issue when validating with your scene, but are tracking this as a separate bug with a lower priority, as it should only ever happen in such extremely simple scenes.

Quote

thanks for the update, do you know which custom assets it could be from the model, I could try removing these when I do tests on 3.4 later today hopefully. I am on a project so if I can find the time to do this I will but it might have to wait

Unfortunately the human readable asset names don't show in the renderer, just their unique identifier (e.g. 23139ce0-a45a-4d9c-90f7-b586b0df598c). As mentioned above, I'd recommend to hide all assets for testing.

Also in case the image shows up completely dark as in the screenshot above, it'd be interesting to know if that changes if you disable hardware ray-tracing in the renderer settings.

Thanks!

We've received the logs and also a project file and are still investigating. We're seeing a huge delay until the export from SketchUp is finished completely in the logs. Unfortunately we were not able to reproduce the reported issues on any of our systems so far.

Possible explanations could be that the issue is related to custom assets or SketchUp proxy files, that we're missing. But this is merely speculation on my end so far.

We'll keep you posted on new developments of course either here or through the customer support channels .

andybot this issue should now be fixed with today's 3.4.1 Preview release

hbc_visual thanks for providing the feedback. We've had a first look at the log file and there appears to be a problem with several (custom?) asset files that cannot be loaded. I'll double check with my colleagues on possible causes and we'll get back to you.

In the meantime: If you don't mind giving the 3.4 version another try: Do you have the option to hide all assets (e.g. if they're all on a layer) and start Enscape without them, to verify if this is merely an asset loading issue or if there's something else in addition to that? Thanks in advance!

Hi wemake

thanks for your report. We are already aware of the issue and have implemented a fix, which will be released soon. See also this existing thread:

RE: mirror not rendering alpha cutout correctly (3.4)

As described there, a possible workaround would be to set the Material Type to Foliage instead.

Hope that helps!

Hey andybot , thanks for the report! We've reproduced the behavior and will fix this for the next update. Fortunately, right now this affects only generic materials and not foliage materials, which are most often used with cut-out textures. So setting the material to foliage should fix at least this particular case.

Which quality level are you using? Ultra quality does more bounces when doing a capturing. You could try to see if exporting it in high quality results more in what you expect. Another thing to look into would be the ambient brightness setting - try to reduce this one. It's actually there to help get *some* indirect lighting in closed spaces, even if people don't have any lights setup - in your case it might not be needed/desired.

Hope that helps!

Thanks for the updated report - now we have some crucial context information: You're working with a very large project and viewing it from afar. What we're seeing here is not actually image aliasing, but geometric aliasing due to floating point precision, that gets worse the further away from 0 (-> the origin) you are. This is expected in such a case unfortunately.
You can verify that if you test the same thing in a (properly centered) smaller project (e.g. the Revit sample) - in that case it should not happen.

When working with that big project you can also check your current Enscape log file (%APPDATA%\Roaming\Enscape\Data\Logs) for the following log:

"New Bounding Box exceeds dimension constraints: ..."

It'll also give you an indication if the project is not centered on the origin of the coordinate system, which makes things worse.

Quote from Adam.Fairclough

That’s great thanks, good to see displacement maps use it.

Also, is there an upper limit on the resolution that Enscape will use for textures?

16.384² is the maximum supported texture resolution. But this resolution is only kept if really required based on the actual scale of the texture on the geometry. You can utilize it e.g. for texture mapping environment geometry with a high-res satellite image, if only used for a poster on a wall Enscape will automatically downscale it to a more reasonable resolution.

Sorry to disappoint, but if it's mostly the edge aliasing you're after purchasing a higher res HMD seems overkill. You could "emulate" the higher resolution just by manually increasing the SteamVR supersampling further. Of course the better display will be noticeable in other regards, such as less screendoor effect, but I'm not sure how noticeable this still is with the Valve Index.

We have not tested Enscape with the Varjo HMD yet, it should run as any other HMD that supports SteamVR, but there's no "official support" from our side so far.

For regular scene textures (except displacement maps) only (the standard) 8bit precision per channel is used - going higher there (e.g. using EXR) doesn't make sense for regular renderings.

Quote from burggraben

Running at 150% supersampling on the Valve Index, eg rendering at 2468x2738 per eye. What's the cuttoff at which point the 4xMSAA is disabled?

That's already above the threshold (2180) and I wouldn't recommend to run with 150% super-sampling with Enscape. It's very likely that what you're seeing isn't actually pixel aliasing but reprojection artifacts because with that kind of resolution you're probably way below the native framerate of the HMD (you can check that if you enable developer settings in SteamVR I think). I think your overall experience will probably be better running at native resolution (100%).

Quote from burggraben

Just the VR controller models or the entire world? The flickering and jagged lines happen all over the Enscape world, not just the controllers. I just used the controller models an apple-to-apple comparison between Enscape and SteamVRHome.

Just the VR controllers, the rest is done via Temporal AA. There shouldn't be much "jagged lines" with this kind of HMD resolution - regardless of the AA technique.

The VR controller models are rendered with 4x MSAA (only for very high resolution displays this is disabled for performance reasons) - usually this is enough to get clean edges. I'm not exactly sure what's going on there - what kind of resolution is SteamVR using with Enscape? You can see that in the settings.

Yes, if you don't care about file size than always prefer lossless file formats - there're no other drawbacks I can think of (assuming you're not loading the bigger files from i.e. a slow network drive).