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.
Our firm will be downgrading until this is fixed...
