Extremly high CPU usage in certain spots

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.
  • 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.

    • Official Post

    Thank you for sending in a feedback report burggraben.


    Our developers would like to receive the project with which you experience this problem if possible as well. Is there a chance to share it (via wetransfer.com for example or any other upload provider of your choice) so that we can try to reproduce this behavior for further troubleshooting?


    If the scene is confidential, you can of course send me the link to the file(s) via a direct message.


    Also, do you experience this in other projects too, and/or even with an empty scene?


    Thank you again in advance for your cooperation.

  • 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.

    • Official Post

    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.

    We will of course handle any project/files you'll send us confidentially. If it's not too much effort feel free to indeed try reproducing this in a smaller scene - I do reckon that this will not occur under these circumstances, so receiving the project would be great thereafter. I appreciate your time!

  • 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?

    • Official Post

    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?

    Please kindly mention this other issue in the support case as well - You can indeed submit those files with your next e-mail, ideally alongside any other log files you will find here:


    Enscape main plugin log files:

    C:\Users\%USERNAME%\AppData\Roaming\Enscape\Data\Logs


    Revit plugin log files:

    C:\Users\%USERNAME%\AppData\Local\Temp\Enscape\Logs\EnscapeRevitPlugin


    Usually submitting a report through 3.4 should also submit previous crashdumps / logs generated with the preview it doesn't seem to be the case here.

    • Official Post

    Hi burggraben - Thanks a lot for your patience while one of our developers had a closer look into troubleshooting this issue.


    To sum it up, the scene you've shared with me, more specifically that object in the scene you've been referring to is basically not optimized to render with sufficient performance while raytracing is enabled. The next obvious step would thus be disabling raytracing via the General Settings to see if that makes a difference.


    Could you kindly try that and let me know whether or not you're successful? We'd like to know if that is one-hundred percent the cause since we could not reproduce the high-cpu usage issue itself, but what I detailed above should be the cause.


    If so, then feel free to check out my direct message which I'll send you with a few more screenshots regarding what exactly seems to cause this behavior in your specific model, so that you can recreate/optimize it thereafter.

    • Official Post

    I am afraid it has nothing to do with ray-tracting. I run VR with ray-tracing disabled and on Medium quality by default. I'll make another demo with graphic settings for you in the DM thread.

    Thanks a lot - To clear up things further, even with raytracing disabled, we still make use of this technique partially, to an extend that it cannot be entirely turned off. As this seems to be the cause here for this behavior still, I can only reccomend to adjust the model based on the guide/screenshots I've sent you via our private conversation.


    If you're unsuccessful or doing so makes no difference, please get back to me.

  • 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.

    • Official Post

    Hi there burggraben , and thanks for your patience of course - One of our developers took another look when it comes to this behavior as promised and I wanted to forward you what he stated:


    The problem is hidden in a library that we use for physics. This library is used to cast rays into the scene using the CPU; not the GPU with RTX (which we have more control over and it offers performance benefits). Since that library is considered a "black box" for us, we don't know what goes wrong inside of it except that the problem is model specific.


    At the moment we can't do anything about that unfortunately for now, other than of course recommending to remodel the problematic objects. I hope that is possible for you. If any further questions come up regarding this subject just let me know, I'm happy to help!

  • Thanks so much for digging deeper into this. Unfortunately it happens with several of my custom models and I can't pin point exactly what to avoid.


    Two questions:

    1 --

    Is this library which is using the CPU to do raycasting, avoided if I enable RTX in VR and do the raycasting on the GPU? (Probably not.)


    2 --

    Can you name the library? Is it open-source or proprietary? I am willing to give up my rights to the latest Revit model I sent you, so it can be reported as a bug upstream. Since your library probably wont work with Revit natively I am even willing to export in a format that reproduces it for the upstream library.

    If it is an open source library I am willing to dedicate dev resources to have it fixed.


    Yes I will have a fix developed and pushed usptream to the library if possible. It is that important to me.

    • Official Post

    burggraben , our developer who is checking this out looked into this behavior once again, so allow me to forward what he shared with me:


    "Disabling the CPU library doesn't completely solve the problem. There are some specific cases of head movement and position on the same model that cause our RTX solution to also take more time.


    This will make the FPS to drop below 45 and SteamVR will start producing these spikes in the CPU graph. The cause will be in the GPU because the passes that use rays will be slower but it will also be visible in the CPU graph due to SteamVR's additional synchronization in very low FPS scenarios."


    In this case he recommends that you kindly check the models again especially for the following:



    (I've already shared these tips with you through our direct messages of course but just to reiterate.)


    You mentioned that you got rid of the long triangles in the last scene you've shared, but hereby also make sure that any holes in your scene are triangulated like the one above, as you stated you weren't entirely sure whether or not they aren't.


    If I'm missing something or you need any further assistance with that please let me know. I appreciate all of your time and cooperation. :)

  • Hi Demain,


    I can try optimizing the model, but I have no control over the specific triangulation model used. This model isn't modeled in a software like 3ds Max which would give you total control over optimization. It is a typical architectural workflow where models are created in Autodesk Inventor and exported directly as a Revit family. This is a BIM-specific workflow and intented by Autodesk to be used as a BIM-workflow. It suppors creation of 3D models for graphical purposes, but also allows to add BIM-data to models. In particular BIM-data like ducts and pipe, etc.

    Guess what one of the most important shapes in BIM devices is? Correct, it's a circle. Every pipe, every duct that I model is based on a circle. After creating the circle I tell Inventor it is a hot water pipe and Inventor exports is in a certain way that I have no control over on the triangulations level, but which is specifically intented for BIM and Revit.


    I would suggest that the Inventor > Revit > Enscape workflow is one which should be supported in Enscape.


    The optimization your developer suggest is a workaround at best. And - judging from the picture - it would only reduce the triangles by a factor of 6. We're talking about a truly trivial amount of triangles to handle for a modern PC with a 4090 graphics card and high-end CPU. Rather than hand-optimizing millions of circles in thousands of models after the Autodesk inventor export, I would much rather devote my resources to fixing the bad implementation in that proplematic secret library you're using.


    Like I said if that an open source library I will gladly devote developer resources myself to it.

  • The cause will be in the GPU because the passes that use rays will be slower but it will also be visible in the CPU graph due to SteamVR's additional synchronization in very low FPS scenarios."

    Sorry but this doesn' make any sense at all on a technical level. There are at least two things that don't make any sense.


    1 As you can see from my video the GPU is bored. Total GPU usage as a percentage is low and individual frame time on the GPU is fantastic. The problem is the CPU and the CPU should *not* be a problem when displaying a trivial model with 50x50 holes.


    2 SteamVR "additional synchronization" (whatever your dev refers to) would not cause this to be "visible in the CPU graph". Windows task manager also shows a crazy 90%+ CPU usage after a while of looking at the model.


    I really mean no offense. Really, from my heart. But it feels like your developer is guessing where the problem is. In my personal team - at this point - I would elevate this issue to a senior developer.

    • Official Post

    Thanks for the further replies burggraben .


    Right away, sorry about the confusion and I could've been a bit more clear as well - Generally what our developer states is mainly what he was able to reproduce on his machine, but there are of course some differences between his and your setup that is why our experience varies here.


    More specifically your case of severe red bars is present for the CPU only and not the GPU, for us/him it seemed to be both.


    Still, we would like to investigate this further with just a bit more help from you:

    - Could you create a "box with holes" once more but this time see if there is a "breaking point", by basically gradually increasing the amount of holes until you experience these CPU spikes? It does not have to be an exact number, but if you find out more let us know please.

    - And just to make sure again, when creating this test box but without any holes (or long triangles), you do not experience this behavior at all, correct?


    As we cannot reproduce this exact same problem here locally as said, your cooperation would still be appreciated in order to get behind this further.

  • 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?