Revit Live Updates: Are they Really Working As Intended?

  • Hi,


    I understand that the underlying problem of what I'm about to address is deep in the code of the Revit API, Revit, and how a PC's resources are made available (or unavailable, for that matter), but I need to present this as an important challenge for the Enscape team, which is:


    How can live changes occuring in Revit get delivered to Enscape faster to the point where it truly feels seamless?:/


    For reference, I have a powerful PC (4.7 Ghz Overclocked, Windows 10, 32GB RAM, GeForce 1080 Titan Ti, M2 PCIe SSD) and I've been running it on a campus project of 4 buildings, probably totalling in 1.2GB in size. If I move a bench family in the garden areal with an arrow key, it take approximately 15 seconds for Revit to "re-print" back to Enscape, and for Enscape to update. Additionally, the Revit window steals focus from Enscape during this process, so I can't really make the move, and then quickly jump back into Enscape. Recently I've been using the pause live updates because I can't get the seamless integration with the software yet.:sleeping:


    I can imagine for some of you that this may seem unreasonable, but at our firm, the design cooker is a fragile, quick, and spontaneous process where every billable second counts, and every 15 seconds waiting on the computer is another 15 seconds remembering your steps, and even more than that if you get distracted while you're waiting. :cursing:


    How can this be reduced to less than a second? Whichever company can deliver the speed we need will be the one we truly invest in.:thumbsup:


    Thanks

  • I second this kind of wish for Rhino. It could be great if there could be a more direct connection between the host 3D CAD software and Enscape. I think it's a problem of all render engines and since the speed of the rendering grows, the update time problem get more wight. I could be great if Enscape could be implement like a display mode like the standard fast shaded view.


    For example I can render an animation per Octane and each frame needs 20s render time and 15s scene export. That's a bad relation. At Enscape this relation would be more worst, since the render times are shorter.


    Looks like Enscape has so much potential that the developing team needs to be ten times bigger to get all the work done. ;)

  • Hello,


    tl;dr A large part of the lag is based on the CAD software and cannot be reduced in any way.


    Here is what happens in detail:


    1. Every CAD software takes it's own time when changing the project, even if Enscape is not running or even installed. This time grows with the size of the project.
    2. Each CAD software provides a possibility for plugins like Enscape to get notified when something in the project changes. Enscape is told which elements/objects/entities were added, removed or changed. The notification does not produce much overhead.
    3. Now Enscape has to read the geometry of the added and changed elements. In SketchUp and Rhino the geometry of these elements is queried from the CAD software directly - small changes should take much less time than large changes. In Revit we must start the export of the complete view to get the data we need. We can skip unchanged elements early, but skipping many elements also takes some time. In some large projects from our customers Revit needs many seconds even before the first element can be skipped. If you use the latest preview version for Revit, a progress window is shown for this step after approximately two seconds.
    4. The data is now sent to the Enscape renderer, which maintains it's own data structure of everything visible. This should not take much time if the changes are small. After this step Revit should be responsive for further changes again.
    5. Enscape has to update some precalculations, mainly the geometry used by the physics engine. During this time the Enscape render window does not react to mouse/keyboard movement. The needed time depends on the amount of changes, again.


    mattendler Are you able to tell, what steps take so much time? You can also send feedback - in the logfiles we are able to see some basic timeframes for these steps. We are always striving for the best performance, so if you have any suggestions on where to improve it or how to adjust the behavior of the live updates, we will always be listening.


    Micha How many seconds do updates take on your typical Rhino models?

  • Micha How many seconds do updates take on your typical Rhino models?

    My dental box scene is part of an animation where the cover is opened. After a cover movement the scene needs approx. 11s vs. 1..2s render time. I don't know so much about graphic technology, but a dream would be if Enscape could react like the standard shaded view per OpenGL.

  • mattendler Are you able to tell, what steps take so much time? You can also send feedback - in the logfiles we are able to see some basic timeframes for these steps. We are always striving for the best performance, so if you have any suggestions on where to improve it or how to adjust the behavior of the live updates, we will always be listening.


    Thank you Simon,


    I appreciate you detailing the issues that are not in your control.


    As for what you can control, here is a list of suggestions for improvement:


    1. Ideally file changes should only trigger Enscape if they are made in the active view and/or in the model. The following items currently trigger Enscape and I think they should not:

    -Detail Lines

    -Pinning Objects

    -Dimensions

    -View specific changes to views that are NOT the active view (ie. Temporary Hide, Temporary Isolate, Selection Box Manipulation occuring in a working 3D view)

    -Etc


    2. Please make sure we have access to toggle START/PAUSE live updates using the same hotkey


    3. I'm seeing the loading bar re-process linked files after making local model edits. Links should only be checked when they're reloaded or their workset is closed and re-opened.


    4. Is there a way to prevent Revit from stealing focus when the update occurs? I will make the change in Revit, then ALT-TAB back to Enscape and have a few seconds to peruse the view while it's loading, but then Revit steals focus.


    5. Is there a way that Enscape can cache an environment from the day previous and then update what's changed? Rather than loading from 0% to 100%...


    My two cents for now..

  • I think the issue of disappearing geometry when reloading something is a far bigger issue than having to wait 15 seconds personally. We're still getting walls being removed when the model has reloaded on some occasions causing us to have to undo what we've just done and redo it or close Enscape down and start up again.


    I do second the notion that small things like Detail Lines, Dimensions, anything annotative should have no adverse effect on Enscape.

  • mattendler Thank you for the input.


    Regarding 1) and 3) we might be able to improve something, but I can't promise anything because the Revit API might not give us enough information for an intelligent filtering.


    4) If I need geometry from Revit, Revit itself opens the view in question. You can see it quite well if you don't have the views maximized. If it's our code that somehow steals the focus we might be able to change it, but if it's Revit there is nothing we can do but to steal the focus in return - which I'd like to avoid. We will check it.


    5)

    If you mean a cache over several Revit starts: That would be nice, but unfortunately impossible to implement in a safe way. Of course we could cache our data, but we can't tell the changes between the cache and the opened document. So it's either 0% caching or 100% caching. As soon as the document is closed we are forced to clear the cache, otherwise you could see wrong geometry. And there's another lag we can't get rid of - the first time Enscape reads geometry from Revit it takes longer because Revit needs to create the geometry first.


    If you mean a cache between several Enscape starts without closing/opening the document: That would indeed be possible, although one would still need the possibility to explicitly read all data again from Revit for the rare case of bugs in the live update feature. And you have to know there are a few changes that look small, but force us to read the whole data because we simply can't determine the changes.

  • My comments inline: