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?

    Quote from Simon Weinberger

    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.

    Quote from Simon Weinberger

    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:

    I'm resurrecting this thread because I haven't seen it get touched upon and curious to know if more feel the same way. I would like the differential update that occurs to be more selective to useful changes, not every change possible. Things that occur in isolation to other views, annotations, creation of reference planes, moving tags, etc. have little to do with the Enscape viewer so Enscape should not be looking for changes to those categories.

    I don't know how other users feel, but I can tell you the reasons why nothing has changed so far:


    When you perform changes in the Revit model, Enscape gets notified about added/modified/deleted elements. Theoretically Enscape could ignore changes of annotations, tags, reference planes and other things without visible geometry. But in addition to the one thing you really changed, Revit often reports changes in some rather generic elements in a generic category. Enscape can't simply ignore all of these generic elements, because some of these do have visible geometry.


    I suggest you tell us exactly about the specific actions/changes that annoy you the most, and we will check what's feasible.

    Hey Simon,


    Perhaps it could make sense to create a list of changes that Enscape could safely ignore. It might be that the API does not allow for distinguishing these events from other events but you never know:


    - changes to the properties of a view (scale, ...) that is not the active view that Enscape is looking at

    - changes to legends can never have geometry consequences

    - changes to sheets can never have geometry consequences

    - all changes to annotations: dimensions, text, regions, tags, ...

    Quote from Simon Weinberger

    I don't know how other users feel, but I can tell you the reasons why nothing has changed so far:


    When you perform changes in the Revit model, Enscape gets notified about added/modified/deleted elements. Theoretically Enscape could ignore changes of annotations, tags, reference planes and other things without visible geometry. But in addition to the one thing you really changed, Revit often reports changes in some rather generic elements in a generic category. Enscape can't simply ignore all of these generic elements, because some of these do have visible geometry.


    I suggest you tell us exactly about the specific actions/changes that annoy you the most, and we will check what's feasible.

    Alrighty, thanks Simon.


    There are two categories:


    1. Anything that is annotative in nature (Changing a view type, moving/editing tags and view markers, Moving/changing a detail item, add text, symbols, tags,

    2. Anything that is view-specific that is NOT the Enscape Active View (hiding and isolating elements in a different view, editing a section box in another view, etc)


    RE: Reference planes, I would keep in the update check because there is always a chance that a model element is hosted to it and you probably don't want to have Enscape query what reference planes are constraining model elements. That would be adding more energy, not eliminating!


    In addition/replacement to all of this, it might be better to have a "Push Changes" button that empowers the user to tell Enscape when its time to do the check, rather than a toggle between auto-updating everything and not updating anything. If the push key is on a hotkey that would be crucial. It's a UI/UX issue.


    Usually I will make 4-5 small adjustments before I want to see the next revision, and I don't want the differential update interrupting me while I'm making those adjustments. Typically having a "interaction mode" creates another thing for someone to cognitively manage, rather than something that as needed.