Batch Rendering Inefficiencies with 2.7

Whenever you encounter any issues with Enscape or your subscription please reach out to our dedicated support team directly through the Help Center or by using the Feedback button as detailed here.
  • Do you need 4k? 2k may render in 1/4 the time.


    Also have you stepped back and considered that rendering 4k images in 1 to 1 1/2 minutes is amazingly fast? Like how much faster should we reasonably expect it to take to render a 4k image? 30 seconds? 10 seconds? Less?


    How does Enscape render speed, quality, ease of use and price compare to other applications?

    I think you're missing my point. What I'm saying is that rendering resolution on my computer doesn't change render times by all that much, maybe a few seconds here or there. My issue is with the way Enscape integrates with Revit. Where it has to reload the entire model into Enscape for every render it does in a Batch. Whereas before, this wasnt the case.

    So before, it would load the model once (roughly 1-5 mins depending on the model), then would take maybe 4 seconds to render each of the 150 renders at 4K.

    Now it reloads the model into Enscape 150 times... so my overall render time went from 10-20mins to 2.5 HOURS at the bare minimum, usually upwards of 5 hours.

    That's my issue, and that's why I'm frustrated

  • Bump, we're still using 2.6 at our office due to this issue alone


    Just tested it with 81 images rendered at 4k. Enscape 2.6 took exactly 12 minutes. Enscape 3.0 on the other hand... got through 22/81 renders over a span of 45 minutes before I finally shut it down....

  • There are also advantages to Enscape batch rendering in a way that respects the view settings of each view. Would be useful to have an option to not reload the model when batch rendering. In the meantime the best workflow would seem to be temporarily install v2.7 and batch render.

    • Official Post

    There are also advantages to Enscape batch rendering in a way that respects the view settings of each view. Would be useful to have an option to not reload the model when batch rendering. In the meantime the best workflow would seem to be temporarily install v2.7 and batch render.

    To add to this, we plan to implement a dedicated option to allow users to disable the automatic geometry reload with each view switch. How exactly it'll be added is not yet completely decided, but it's in the works.

  • To add to this, we plan to implement a dedicated option to allow users to disable the automatic geometry reload with each view switch. How exactly it'll be added is not yet completely decided, but it's in the works.

    Although an on/off switch would be a good step in the right direction, a cleaner integration would be to make the view linking to the native programs more modular and optional.


    Ideally one should be able to save an 'enscape view' without having to link it to a native application view. And if you do link it to a native application view, it could be more granular with options for "link geometry", "link sun position", "link camera position".


    With such a system, Enscape would only need to reload if you switch between two views that are linked to different native application views with link geometry checked.


    It would also solve other long standing issues like: not being able to save sun position and not being able to save changes to sun position or camera position (+it would make batch rendering significantly faster while still being able to switch design options)

  • Time of day, time of year, project orientation and project location is already in the Revit file. Date and time is saved in the Revit view. Creating a view template allows you to quickly and easily save / manage the date and time across multiple views.


    https://twitter.com/PhilRead/status/1356276171130941440


    If you need to batch render without reloading the view download Enscape 2.9 here:


    https://installer.enscape.io/Enscape-2.9.1%2B34079.msi

  • Time of day, time of year, project orientation and project location is already in the Revit file. Date and time is saved in the Revit view. Creating a view template allows you to quickly and easily save / manage the date and time across multiple views.

    I'm aware :)


    But this doesn't align with our workflow. We set the project orientation and location correct in Revit (so sun paths are realistic). But from that point onward we play with the sun position in Enscape (changing time of day as we see fit and even overriding sometimes with CTRL / Shift u/i). It is an artistic approach that mimics our traditional 3ds max workflow: we don't want to enter a bunch of numbers put experiment with it in Enscape.


    When we now save a scene we have the following problems:

    - our sun overrides are not saved

    - every time we tweak the sun position we need to create a new view, favorite it and link the settings to it, then delete the old view


    My point is: the current solution only captures a part of the possible workflows. It works great if you want to make a shot at April 16th at 3pm, but not so great in a more artistic flow. Better would be to make this linking optional, and allow sun position saving in the view directly for people who prefer that.

  • Just wanted to say that with Enscape 3.2, it does indeed add a toggle button for Exporting Geometries in Revit. However, for batch rendering this still seems to be an issue. Even with Export Geometries turned off. It still exports the view for each of my 80 renders I'm trying to get out. Incredibly frustrating having to use 2.6 still and miss out on a lot of the newer features...


  • mahammed I've read your comment twice and I don't understand the question. What are you trying to accomplish?

    The problem was described precisely over and over again. I got in contact with one of the customer support team on a meeting a few months ago where I described the issue LIVE, and they clearly saw and admitted there's an issue.

  • mahammed I've read your comment twice and I don't understand the question. What are you trying to accomplish?

    Guess I'll explain again. So we often export 80-100 renders at the same time for a fairly specific reason (we upload these renders into a 360 viewer which we can embed into webpages. So essentially we're rendering a 360 video frame by frame. And no, for our use case, we can't use Pano's).


    So within this workflow, we have no need to re-export geometries from Revit for each render, since all of the settings, time of day, exposure, etc. remains the same for each of the 80 renders.


    In 2.6 and earlier, we would load up Enscape, set all of the lighting, TOD, etc to what we want and then batch render all 80 renders. This would take maybe 15 minutes.


    With 2.7 and onward, every render within a batch is reloaded from Revit into Enscape. So this is similar to closing and reopening Enscape 80 times... So our render times for these 80 renders went from 15 mins to sometimes 3-4 hours depending on the model complexity.


    I understand how this may be useful if for example, we have 15 renders, all with vastly different settings. But for our workflow and what we need, this has been and continues to be a huge issue. And I'm not the only one.


    What we suggested was implementing a toggle which turns this off. This was implemented in the latest update but for some reason, at least for me, turning the toggle on or off has absolutely no effect on whether or not Revit exports geometries each of the 80 times.

  • Thanks - I understand the situation more clearly. My understanding is turning off the toggle would not refresh the geometry - only change the time of day and camera location. And this would effectively create faster batch rendering when the user does not need the geometry to reload.


    My understanding is turning the toggle to the off position only changes the time of day and camera location. Can someone from Enscape clarify the effect of turning the toggle on or off?

  • I think there are 4 ways the "reload geometry" toggle could be improved


    - Add it to the to the batch rendering dialog

    - When off: display what view your enscape geometry is based on (right now you just have to remember what view you were on when you turned it off)

    - Make it visually more clear (it's hard to understand when it's off an when it's on)

    - Remember the slider setting across sessions

  • To your point Pieter, isn't the toggle already in the Batch Rendering dialog? And when off, it turns transparent, I think that's easy enough to understand.


    But I agree with your other points


    • Official Post

    I can add this to our internal UX bug backlog but tbh. I personally disagree with point 3 because that toggle button follows all usual conventions.




    The problem was described precisely over and over again. I got in contact with one of the customer support team on a meeting a few months ago where I described the issue LIVE, and they clearly saw and admitted there's an issue.

    Let me verify your bug report this is not the expected behavior :) the whole purpose of that toggle button is to manifest the exact thing you want only change the camera position, time of day and apply any linked preset not re-export geometry.

    • Official Post

    Pieter; mahammed; Voxel

    Okay so in general the toggle works as expected (for me at least with the default Revit project) running 3.2 I can just batch render all views without a re-export:


    It appears though as if as soon as you add another linked project we run into a scenario where we actually re-export the linked projects:


    I will file this as a bug and we'll look into how this can be fixed and packaged into a 3.2 service pack, for now you could (I know that this is inconvenient) try to merge the linked projects together by binding the link or something similar. Sorry for the inconvenience we'll add this as a test case internally to prevent stuff like this from happening in the future once we have found how to prevent this.

    • Official Post

    Update: This issue just shows up more using linked projects it likely already exists for single projects as well but is less visible. Anyhow we are looking into a fix for this right now. We'll try to include this within a service pack of some sort for 3.2