Batch Rendering Inefficiencies with 2.7

Enscape Host Applications Enscape for Revit
1

So at the company I work at we tend to do quite a bit of batch rendering out of Revit. Often times we will set up 100+ views and then just let them render over lunch or at EOD. However, with the 2.7 update I’ve noticed that it does batch rendering quite differently. Before, I would go into a 3D view, change all of the settings to what I need, then Batch Render. The batch renders would then just use the same settings as the 3D view and all of the renders would be done in maybe 10-20 minutes.

Now, for some reason it wants to “re-print” every single render. Which means that now it takes a minute or two for each render. Long story short, my render times for batch rendering went from 15 mins to about 2-3 hours…

Am I missing something? For the time being we’ve had to downgrade to 2.6

2

Yes the batch rendering now exports the model per view to support batch rendering views with different geometry in them, we cannot know if the geometry is the same without exporting it though. Revit does not provide functionality to discern if two views contain the same geometry.

3

The ability to have different design options in batch rendering is great, but with heavy models this is indeed going to slow things down very significantly.

What if we for each favorite view could select to use the “active view” (the one in the enscape dropdown in the ribbon) or to get the geometry from 3d view? This behavior could then also apply to the favorite views in the Enscape render window.

Most of the time when we do a batch rendering, the geometry doesn’t need to change.

4

We are currently working on a campus containing multiple buildings. In earlier versions, we previously did batch rendering of each building and everything went smooth. In 2.7 however, Enscape loads the geometry in each rendering. That’s not how it’s supposed to behave.

5

Obviously need to be able to control this. If it is Revit only, then they are the ones who need this control.

How about use the existing button currently used to “disable scene updates” in interactive mode?

If that is enabled when batch rendering, the same scene is used for all views.

Thanks!

6

Glad I’m not the only one with this issue, as people have mentioned previously I think having a “update scene geometry” toggle box or something similar would be incredibly useful. Until then, looks like I’ll be sticking to 2.6

7

@Demian_Gutberlet

…Any chance thae addition of way to disable scene updates whem batch rendering could speed up the process? I would ideally like to render multiple views of a scene at a similar speed to movie rendering. Thanks!

8

This issue hasn’t been solved.
I will advice our office to downgrade.

Batch rendering has serious issues. I’m surprised this hasn’t been resolved yet.

When rendering standalone pictures everything works fine. However, when using batch rendering, everything gets slow, model reloads again to each render and what’s even worse is it exports wrong geometry.

Currently looking into transitioning to Lumion. We are unable to work like this.

9

Reloading geometry is necessary for batch rendering so that the visibility state of objects in each view is rendered accurately. Previously Enscape would only render the visibility state of the Active Document, only changing the sun and camera location. Batch rendering now respects each views setting for visibility, section box, phase, design option and more.

Can you be more specific?

10

Hey Phil,

You’re right it’s a powerful option to have, but most of the time the geometry/design options/phasing doesn’t change per view (in our workflow). If you have a large model batch rendering with lots of views and you don’t need to update the geometry for each view, batch rendering now got much slower.

Having an option for each camera to ‘update geometry’ could be a compromise perhaps?

11

The old default (only) function was to not update geometry between scenes.

The new default (only) function is to update geometry between scenes.

This seems like a no brainer request from users simply pointing out that we would like the option to choose :slight_smile:

If this will speed up batch rendering for cases that do not need to update geometry (which is almost always for me) why not?

I have already suggested you do not even need to add to the UI. There is a button for enabling / disabling scene updates for interactive rendering. You could simply make that toggle control batch rendering as well.

Thanks!

12

I am supporting this suggestion 100%.

Before 2.7 we could batch-render 30 views in just a few minutes and now the machine is locked doing this for 5-10 times longer.

I do understand why you would add this function, but the fact is that if I need geometry to change ei. using designoptions or likewise, its much, much faster to use batch render on every single view in 2.6, change the desginoption and render every single view again, than it is to just let 2.7 render the views once. This needs to change or the user-friendliness and easy of use is gone.

The thing is that this needs to be corrected ASAP, because I’m sure there are alot of people like us who has had to downgrade to 2.6 which means all the new updates arent available! Something as simple as a toggle-switch as many others suggested is the easiest fix to implement, but very powerful indeed! Then maybe down the line you find a way to make the scene-update process much faster and then it is actually usable.

Please fix this soon!

  • HRRenner
13

How long does it take to render 30 views in 2.6 vs. 2.7?

14

I think he said his experience is 5-10 times longer in 2.7 vs 2.6. Why do you ask? Are you having the same problem and considering downgrading?

15

30 views in a few minutes vs 5-10 times longer isn’t very specific. For example 30 views in 2 minutes vs. 10-15 minutes IMO is worth the wait for the ability for each view to render with respect to view properties. In previous versions if you wanted to render views with different view settings you would have to manually make each view the active document and then select the render button. To do this for 30 views was a very tedious process probably taking nearly an hour. Now it is much faster taking only 10 minutes.

16

The feature request is to add the “ability to choose” if we want batch rendering to update between scenes.

If we had the “ability to choose” would you choose to wait 5-10x longer to batch render scenes with only changes in viewpoint?

How would the ability to choose be a problem for you?

17

Having the ability to chose is not a problem and could be an option. But present feature saves significant time based on use case of batch rendering views with different visibility states, design options, phases, detail level, section boxes as well as different visual settings in Enscape.

18

I think that’s exactly the point. It saves time for some use cases but adds significant overhead for others. We are also seeing 10x in load times for some batch series. This is why we advocate for a toggle.

19

I’m digging deeper into this because it reveals a larger workflow issue.

As a bandaid, I think Enscape devs need to quickly provide us with a checkbox to “untie” view-specific properties from views so that we can swiftly print multiple camera angles that use the same view properties. I’m happy that some users now benefit from batch rendering VG-differentiated views but for the users that have the same VG across multiple views, it seems we can no longer benefit from the ease of them all sharing the same VG properties.

At our firm, we tie all of our Enscape ciews to one VT (view template), so all of this is being managed from the Revit side before printing. For example, if we have 12 perspectives and 4 design options, we’ll just batch print once, change the VT properties, and then batch print again, and then collate the images into a PDF on the bluebeam side.

So this leads to an important question:

Does the API give the devteam a chance to have Enscape quickly check if the view properties differ? And therefore prior to batch rendering it could theoretically it trigger a reload of the model ONLY when it sees a difference? OR is the API “blind” to these nuances and you are just having it reload the model for each view as a “failsafe” to meet the needs of users who are differentiating the VG across their views? Generally speaking, I think any software development using a ‘failsafe’ strategy is inappropriate as it will generalize the problem and cause larger issues in the community.

I think the word “tie” is operative here and could be a good spatial metaphor to use from a design UI perspective.

We need a comprehensive UI that can organize our views for batch rendering. I’ve seen the development of it thus far its different forms attempting to tackle the big issue here but it hasn’t been holistically addressed yet.

This is my main issue: either the view properties for Enscape are managed in Revit (which means view-specific), or they’re managed in Enscape (Enscape swallows all of the possible switches in a comprehensive interface of its own). I believe that the latter is really the only way to solve this problem, but I understand thats a big change. What I’m suggesting is that Enscape develops its own way of adjusting view properties in its own interface, and completely ignore what the view is telling it, because its managing everything on its own. Ultimately, this seems like the big move that would make Enscape a better product, as I’m sure it could also pre-cache changes and effectively eliminate the gratuitous cycle of having to “PRINT” the model to Enscape. Imagine Revit prints to Enscape only when a model update is made, not a visibility change!!! This could also potentislly mean that the CPU bottleneck of Revit will be relieved. That means all design options are pre-cached within Enscape, and you can flip through them using the power of the GPU, not the CPU. I’m sure there are many issues this improvement would need to consider.

Until then, we should at least not lose control of efficiencies we have had in the past. Here are my three major points:

  1. We should be able to decide to “tie” view properties or “untie” view properties, and distinguish that from “camera position”, essentially letting the view template do all of the work. Part of me suspects people who need to batch render a bunch of differentiated views are not using VTs and doing a bunch of manual overrides, and I would prefer if Enscape not compromise its effectiveness for users who are not using the software effectively.

  2. We should be able to save “print sets” akin to the print manager. It should be up to the user to set up the print sets in a way that would heirarchically differentiate VT differences. The whole favoriting idea is nice but does not speak to the complexity of the problem. In effect it simplifies it and minimizes the issue. We can have numerous sets of views in a drawing and they should be

  3. If sun position is importantly differentiated per view (aka the sun kisses the concrete at the lip of a wall edge at 11:45am differently than 11:56am, and I want to be able to imprint that value into the view, I should be able to do so) Enscape should be able to “push” the solar data to a specific view upon saving IF and ONLY IF the VT has Lighting in the GDO unchecked. Remember that the VT ultimately has control. But locating that 1 minute difference in Revit’s Lighting dialogue box is terrible and unsustainable, so if Enscape can help us record our preferred solar timestamp back to the view that would be ideal.

thanks for reading.

20

@Pieter_2 @Clemens_Musterle @Demian_Gutberlet ^