Posts by burggraben

REMINDER! If you encounter any issues with Enscape (e.g. crashes, installation problems) or your subscription please reach out to our dedicated support team directly through the Help Center or by using the Support button as detailed HERE! Thank you for your understanding.

    I built a new model which removes some of the complexities of the older model and isolates the issue more.

    A 100mm thick plate with a grid of 50x50 holes. In addition to the slow CPU frametime of the other demo this also manges to get the actual CPU utilization pretty high.


    Here is the interesting observation: It works just fine in the beginning of the demo. I can fly around the objects and move my head fast and CPU frame time stays near 2ms for the first whole minute of the demo. However it feels like some CPU-intensive "CPU black hole" is build up during that time inside Enscape and at several points in the demo after frame spikes spike high that this CPU intensive "CPU black hole" disapears again and frametime goes from >40ms to 2ms again.


    The fact that Enscape at first managed to render the object with perfect framerates, but then after a while slows down, and then becomes suddenly faster again, tells me that the is something that can be done in the code to improve this situation.

    Yes, I have double-checked and confirmed that it is not some background-process eathing up the CPU.


    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Different problem: I used 3.4 before but just tried 3.5 latest alpha to see if it is fixed. Unfortunately the alpha crashes on VR startup. The feedback dialoge freezes, so can't submit the log files. I'll send you the crash logs on the alpha. You need the latest .og and .dmp right?

    I don't see this with an empty scene or other projects. It is related to particular objects that where placed in this particular projects. If you get close to the drill stand or the welding table in this workshop then the CPU usage spikes. These are custom objects we modeled in Autodesk Inventor and imported into Revit as a family. I tried placing an objects in isolution in an empty scene, but it wasnt enough to reproduce the issue. It is some combination of objects. The original file is 365MB, I can share it if you would like and don't post it publicly.

    I can also try to reproduce the issue in a smaller scene first.

    A video would be helpfull as I am really not sure what you mean by striping. It's has been a long time since I used high/ultra in VR, so I actually don't know if antyhing changed with the Aero. I can try for you. But even on the Valve Index and the HTC Vive Pro it used Medium. Even when I got full frame rates that was a weird effect on high/ultra that the image never to render for a second after moving my head. I it not striping though, it is cust that the image isn't crisp/sharp for a second before it becomes sharp. Immersion-breaking in VR.

    Personally I never run Enscape VR in High or Ultra. Even on a 4090 GPU the Medium setting is the only option that gives me a (near) constant 90FPS on the Varjo Aero.

    Not sure what you refer to with striping / pixel binning. Maybe make a video? I do see lower FPS and some slower rendering (scene building up in a similar way to pixel apearing in renderd 2D images) when moving my head in high/ultra. On Medium this does not exist.

    There's a weird bug in VR in where the CPU usage is normally low, even in the single digit range. But when moving my head in certain spots and keeping it still inside that spot the CPU usage goes extremely high. When moving through such a spot in a regular walking motion, this results in strong jitter.

    This happens on a high-end system with a RTX 4090 GPU and an AMD 5950x 16-core CPU. Here's a video of the problem. Note how the CPU usage goes red when moving into that problematic CPU-black-hole spot. There must be some algo doing something in some very inefficient way. CPU usually isn't a problem in VR, the GPU is.


    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Just the VR controllers, the rest is done via Temporal AA.

    Upgraded to the Varjo Aero and it solved all of my issue with jaggies. The much higher resolution display is a perfect fit for Enscape in a professional environment. Up to now I have been unable to run that kind of resolution in Enscape on my old 3090, but with the new 4090 I get acceptable VR framerates, with the GPU maxed at 99%, raytracin turned off and Enscape rendering quality set to medium . I am wondering one thing though:

    With Aero-kind of super high resolutions, do we even still need Temporal AA. Maybe the GPU cycles spend on AA would be better spent on higher FPS?

    I'd love a way to turn off AA with a checkbox in setting similar to how I can turn off ray tracing. Maybe even more fine-tuning of individual graphic engine setting would be nice to strike a better balance of FPS needed for VR and graphical fidelity.

    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.

    Sorry for the late response. I can confirm that this is the case just as you described it. When moving to the origin, eg teleporting to the house modeled in Revit, the geometric aliasing is gone.

    Burggraben,

    Good luck with RTX 4090, let us know how it goes.

    PS I noticed that MSI is going to have a LIQUID COOLED version of the RTX 4090 (no price listed yet)

    Trying to buy a 4090 for the last few days now. I'll stay with air cooling though. The pumps in water cooling system tend to fail on me and since that is a central point of failure, it is much worse than a 1 of 3 fans failing which sit on top of a massive cooler.

    Should be almost effort-less to enable VRS to improve performance further. I read over on the Varjo blog that "the huge benefit is that apart from providing a shader rate coefficient matrix, the application does not have to be modified".

    Thank you for your feedback.


    Since we are making use of Vulkan, not DirectX 11 which is required for VRSS to work, this may not be supported anytime soon. Perhaps NVIDIA is able to implement a (similar) solution for Vulkan-based applications as well in the future, but for now, there seems to be no compatibility I'm afraid.


    I've still forwarded your feedback accordingly, to also keep an eye on its further progression.

    Read some more about it. You're right. VRSS (super sampling) isn't supported on Vulcan, however VRS (shading) is supported on Vulcan. See: https://developer.nvidia.com/v…phics/variablerateshading


    So maybe some poerformance could be gained with VRS.

    Guys, here a way to improve Enscape quality without any coding work on your side. At least for those of us with eye-tracking headsets.


    "NVIDIA Variable Rate Supersampling (VRSS) leverages NVIDIA Variable Rate Shading (VRS), a key feature in NVIDIA’s Turing architecture, to increase VR image quality while maintaining high performance. And developers don’t have to write a single line of code to use it."


    Please consider applying to have Enscape support this:


    Apply here:

    https://developer.nvidia.com/v…eshading/vrss_application