Posts by burggraben

Quote from Demian Gutberlet

We are currently still waiting on 3DConnexion to also implement a fix from their side with their next driver update release in particular when it comes to this particular problem which others experience as well. They have identified the cause internally already and said fix will be come with the 10.8.15 Windows Driver Release soon.

Just update to their 10.8.15 driver and the behavoir is exactly the same. When opening a Revit view in Enscape the view becomes unusable in Revit. I still have to use the workaround to have dedicate Enscape and Revit 3D views, which works fine, but require careful clicking.

Maybe we are not talking about the same bug?

I saw in the release notes of the latest alpha that you split up the previous denoiser into a GI Denoiser and a Shadow Denoiser. Is that supposed to help with the issue from the thread or should I expect to see improvement in some other area?

See this post and following for a fix: RE: Previous Release / Preview Threads Merged

Quote from Demian Gutberlet

Thank you for the further reply and your patience burggraben .

Our developers were able to find the cause behind this now, and we are currently looking into resolving this as soon as we can. I cannot say when exactly yet, but at this point thanks once more for the cooperation with troubleshooting this.

Awesome, great to hear you managed to reproduce and find the cause. Finding the cause is always half the work to squashing a bug.

Quote from Ilias Kapouranis

This is why there are only a handful games that have great graphics in VR. The effort it requires to get that level of detail cannot be afforded by small studios; and they know what geometry the use and optimize/bake it before shipping. Enscape has to deal with anything on the fly.

Just an idea: Maybe Enscape doesn't always have to do everything on the fly. On-the-fly mode is great while developing a model and making changes.

Once it is semi-finished, VR performance become more important than making real-time changes. It would be nice having a packaging-export-feature which would package everything for optimal performance. It could produce an unchangable exe or something. It would be fine if this process took several hours because it optimizes things, bakes lighting etc just like it takes a long time to compile a game.

Just an idea. I know you probably don't have time for it, since it is an epic task.

Quote from Ilias Kapouranis

That is a controversial topic and I understand where you are coming from. In my previous role I was working on VR for mechanical engineers and they, too, wanted the best possible image and they didn't care about FPS; they just wanted to stay still and look at the point of interest. The point of controversy is that Enscape is designed to be real time and at least try to stay at specific framerates. If we provided that "real" ultra quality, then customers would think that the program is just bad because it can only produce 5-10 fps at the quality. Quality image in VR is just so hard to produce both in high fps and consistently.

I would agree that real-time, high-FPS VR is the more important of the two for Enscape VR. Currently I run Enscape Desktop as pretty as possible and Enscape VR on whatever gets me to 90 FPS. VR is great to get a sense for how big a space really is, or to let someone stand in their new kitchen and see if the space between island and table is big enough.

Having this as-pretty-as-possible VR mode would just be the cherry on the cake, but it would see much less use than 90-FPS-VR.

On more question, since you seem to be very knowledegable about this (great to see that Enscape has some new devs with VR expertise):

On VR Medium I get crystal clear 90 FPS, on VR High I get lower FPS around 50 or so, which isn't great but acceptable.

There is another reason I don't use VR High and Ultra and stick with Medium. It's a little hard to describe, but I'll try. Whenever I turn my head to a new spot, the image is more grainy and the it take a couple second before it "loads" additional pixels and gets rid of some of that grain. Like a classic TV-show picture loading animation. It is distinct from the noise from the diffuse and specular reflections we discussed above, because that is permanent. This goes away after a few seconds or looking in the same direction. Any idea?

Quote

Is the issue still present in 3.5.2? I could retry reproducing it then because I couldn't see anything close to that behavior before. What is the resolution that you are using?

Yes it is present in 3.5.2. My resolution is 2880 x 2720 px per eye @ stable 90 FPS on industry-grade Varjo Aero headset. But this also used to occur on my much lower resolution consumer-grade Valve index before I switched. If you can't manage to reproduce I can test again on the Index. It seems to be GPU load independant however. There are certain geometries which just cause crazy CPU loads, but only sometimes, depending on how far you are from them, how long you have been looking at them, etc. With the table Revit it is pretty reproducible if you hover over it and move around.

Did some more testing on this and the problem still persists. A box without holes doesn't cause any problems. It would probably take me houre to find out, how many holes are the exact breaking point and I am unsure if that would give you any more valuable insight.

The CPU throttle goes red 100% on 16 cores. When you run a CPU profiler if should be very ovious which function needs optimizing.

Of coarse you have to be able to reproduce it. I switch machines and GPU and am able to reproduce with the same file I sent back then. Could you give this another whirl?

Quote from Ilias Kapouranis

- VR is so much more demanding that desktop. Having 2 4k screens in VR doesn't mean that it will just take double time than rendering 1 4k screen in desktop. There are a lot of things that don't scale very well with resolution, so the GPU utilization doesn't scale as expected every time. For this reason, we reduce the VR quality by one level compared to the desktop quality; VR ultra quality is actually desktop high quality.

Ahhh, got it. So that's why I don't see the bug where the Shelf 010 looks like a light source in the highest VR quality setting.

Correction: Just tested it and Shelf 010 appears like a bright light source (but is probably technically hyper-reflective?) on Deskop high and ultra, but not is VR Ultra. So there is some difference between VR Ultra and Desktop High, which makes Sheld 010 behave this way in VR only.

Quote

- In addition, it is not just GPU work that is doubled, there is a lot of processing on the CPU for the preparation of the GPU commands for each eye. We don't use any Single Pass Stereo technique currently to reduce the CPU overhead of the draw calls.

Just googled and read your blog post on SPS and it sounds interesting. Any plans to use to to improve VR performance?

I am usually not CPU bound in VR high/ultra. The CPU is typically bored, and a 4090 GPU sits a 99% on a high resolution Varjo Aero headset in high and ultra. (Medium is fine). There is only one CPU problem which I identified and reported, but it looks nothing happened on that front.

Extremly high CPU usage in certain spots

I just tested again, the issue still is present. Maybe you could try reproducing it again? I do have the simplified testing file still available which I sent to Demian last year.

Quote

- The 90s TV effect that you see is actually noise from the diffuse and specular reflections in the scene. For VR we perform a lot less ray tracing calls to try to stay on a specific framerate and that shows in these areas. Of course we apply a denoising step on the ray tracing results but this can not be enough in some cases. That's why these are mostly resolved when you disable hardware accelerated ray tracing.

Shame, it looks so pretty on desktop, but not pretty and very distracting in VR.

I would actually still prefer if you have a "real" Ultra in VR instead of what we have now.

Even with a 4090 currently I *have* to use Medium Quality to get 90FPS.

But I'd like to something switch to Ultra to get the prettiest picture in VR. Currently that gives me 50FPS or so, but I don't use it because it looks worse than Medium. Ultra and High both looks worse than Medium in VR.

I want a "real desktop quality" version in VR, even if I only get 3 FPS. I do architecture, so mostly I just navigate to a spot and looks at it with my head still.

Quote

- DLSS is also a bad candidate for VR. DLSS produces weird artifacts that can be almost invisible on desktop but become very obvious in VR. I would suggest to keep it off because it can also mess with stereopsis of people with more sensitive eye sight. There are also people who don't notice anything at all.

Shame, it seems to be a coin toss right now. Some VR apps / games work with DLSS, others don't.

Quote

Since we will be resolving the issue of the washed out image in VR in the next version, I would like to ask you to try that version and come back to us with what problems still remain.

Happy to.

Quote from Adam.Fairclough

I would hazard a guess that some of the temporal rendering is not there in VR and that perhaps that settings are changed so that the performance is kept higher - as you need it really really high framerate to not feel awful in VR.

From my experience, the opposite seems to be case. Performance in VR is worse than you would expect.

When rendering a model at Ultra Quality on a 4k desktop @ 60Hz I typically have less than 25% GPU ultilization on a 4090 to render 60 frames / second.

When in VR I need to render two 4k screens @ 90Hz, so 180 frames / second, which would mean that I should be able to render Ultra Quality with 75% ultilization or something like that. But typicall I can't and get 99% GPU utilization with 50 frames/second and need to drop down to Quality Medium to get my 90 frame / second with 75% GPU.

I understand that these are only paper estimates and in reality it probably doesn't work that way, but still -- performance and rendering quality in VR seem to be worse than it should be, based on the good desktop rendering quality and performance.

After some more testing: It is related to ray tracing. If I turn off ray-traced sun shadows, then the Shelf 010 stop beeing brighly lit and in VR the noise is noticaly reduced. When ray tracing is switched off entirely it is reduced again.

So in essence ray-tracing doen't work in VR.

Same thing with DLSS which works fine on desktop but not in VR. I wonder what makes VR so different. I figured Enscape would just use the exact same render pipeline, but render it from two different perspectives, once for each eye, but this doesn't seem to the case?

Here's another image, showing the TV-noise effect in a situation where it is much less pronounced. However in real-time VR it is still very distracting because the TV-noise is constantly animated, making the scene very busy.

Other things to notice: The lighting at VR Ultra seem very different from Desktop ultra.

VR might actually be a better lighting than desktop if it werent for the TV noise.

- On desktop the Enscape Shelf 010 acts as a light source for some reason on quality Ultra (not on Medium).

- In VR the Shelf 010 is not a light source.

- Light scattered across the floor from the door window actually looks better in VR than on desktop, but that might be because of the self-illumating shelf on desktop.

- Shadows on wall in VR Ultra would actually look better than Desktop Ultra.

- The chairs seem to cast a shadow in VR from the light from the door windows, but they don't on desktop.

- VR Ultra seem to use way more resources than Desktop Ultra, even after accounting for the fact that VR has to render two images, one for each eye. That scene would use around 20% of a 4090 to render on desktop, but maxes out the GPU in VR and would probably need twice the performance a 4090 offers to render smoothly.

Are the rendering engines fundamentally different in VR vs desktop? That scene looks very different in VR than on desktop, VR and desktop seem to have different bugs, and different performance characteristics.

I am seeing some rendering artifacts when using quality high & ultra in VR, which so not exist in desktop-mode (at any quality setting) and do not exist in VR at quality medium.

Generally in can only use VR in medium because of these artifcats. With a 4090 I could sometime use High quality performance wise, but the rendering artifacts are too distracting.

What's the cause for these? They do seem to be worse when the lighting isn't 100% sunlight, but some artificial. Maybe more pronounced the dimmer a scene gets. However: On desktop the exact same scene with the same lighting renders crystal-clear, and when switching to VR mode , the rendering is very distracting. While wall, get a 90's TV noise artifcat animation. Pics (the color difference might be due to the fact that I have to adjust exposure and saturation to counter the current bug where VR is way too bright):

Quote from Clemens Musterle

We'll provide a fix for that issue in the next service pack release soon. Unfortunately it didn't make it into the 3.5.2.

Thanks Celmens! Mucch apreciated.

Unfortunately 3.5.2 doesn't fix the over-exposure / everything beeing too bright bug that is present in VR mode. Is there any workaround other than downgrading? Currently I am dialing down the expose setting manually, but things get a bit dark then.

Quote from Ilias Kapouranis

Nice to hear that the problem has been resolved! We will provide more information about the washed out colors when we have something to share

So I tested it some more and I can live without the eye calibration and just run the headset on SteamVR instead of the VarjoOpenXR engine. The only major problem left with 3.5 are the washed out colors. Does this affect every hearset or just a few? Do you need me to provide any log files or are you able to reproduce it on your end?

Quote from Ilias Kapouranis

Hmm does it perform the eye calibration / pupil distance every time? Did it remember the previous setting before doing the workaround?

In 3.4 we didn't use OpenXR; everything went through SteamVR again. Only in 3.5 we have the ability to use Varjo's runtime directly but this causes problem and we have to launch through SteamVR again.

Yes, by default the Varjo headset does this every time the headset is put on. Makes it really convenient to switch users. For a single-user headset you can set it to remember the eye calibration permanently. I'll test again today if it really is the case that it doesn't do eye calibration when set to SteamVR, or if it just didn't do it last time because it recognized I am the same user. Might have been a false alarm, if 3.4 always used SteamVR.

If eye distance calibration works with SteamVR, I am not even sure what the benefits of using VarjoOpenXR would be. I guess maybe eye tracking / foval rendering (if the app would support it). In that case - I'll just live with using SteamVR as runtime.

@Demian @Enscape

Because of the bug above I have seperate 3D view for Revit only and for Enscape only. But I found that this is a good practice in larger project anyway, even if this bug wouldn't exist, because Revit and Enscape have different optimal visibility settings.

*However*, it is cumbersome to manage the fact that some 3D view should never be opened in Enscape. Currently I am prefixing the name of Revit-only 3D view with something highly visibly like X___ to make sure the go to the bottom of the list in Enscape's View Management. It would be great if we had a way to exclude certain 3D models from Enscape's View Management. Or maybe the other way araund, explicitly tag the 3D model which are for Enscape and only those show up in View Management.

Quote from Ilias Kapouranis

Nice to hear that the problem has been resolved! We will provide more information about the washed out colors when we have something to share

Works perfectly as a workaround. I guess it would be nice if you would add VarjoOpenXR to your whitelist eventually. VarjoOpenXR did seem to work just fine with Enscape 2.4.

But it work fine for now. Not even sure what I am missing by setting is to SteamVR instead of VarjoOpenXR. It seem to not do the eye calibration / pupil distance measurment in when putting the headset on and I guess eyetracking isn't available either (but almost no software supports that anyway).

Quote from AsisNath

Once the Enscape environment is opened revit's 3d model becomes unstable and move quickly out of axis with slight touch of space mouse compact.

I have had this happening for two years. I feel your pain.

The only workaround that I have found is that I dedicated 3D views for Enscape and for Revit.

I never open the 3D view intented for Revit in Enscape and this way they stay fine.

Quote from Ilias Kapouranis

To understand more about this problem could you please:

• Close SteamVR, uninstall 3.4, install 3.5.1, restart your PC, open 3.5.1 and enter VR. Does the problem persist?
• Set the SteamVR runtime as the default OpenXR runtime instead of the Varjo one. In SteamVR settings you will have to enable the advanced settings and navigate to the Developer tab where you can set the SteamVR as the default OpenXR runtime.

Reinstalling, restarting doesn't make a difference.

Seeting the runtime to the SteamVR runtime allows me to enter VR mode in 3.5.1. the Varjo runtime does work for 3.4, but not for 3.5.1.

I can confirm that the thumbsticks work are expected in 3.5.1. Now if only the world wasn't washed out, I could jump onto the 3.5 bandwagon.