Posts by mattendler

    No because these concepts only exist in Revit. For me it makes sense that these things are left to the host application which already has many tools (like view templates) to handle all these settings efficiently. It would also be a gigantic development effort.

    The only 2 settings that I'd like to be governed by Enscape (in an ideal world) are the camera positions and sun position. You would still select a revit view from which Enscape should get the geometry, but camera positions and sun positions would be managed by Enscape. This is similar to how many other applications do this (as mentioned by renderwiz). It's interesting that you can re-use a revit view as an Enscape view, but it's kind of limiting that you NEED a revit view if you want to save a camera position or time of day in Enscape.

    But like I said, I think given the current implementation that's unlikely to happen. And there might be other solutions to get to easily reproduceable renders. Like suggested in the other tread, an easier way to update cameras (so we can tweak camera position and time of day and save that back to the camera) would be a good step in the right direction without needing a major overhaul.

    Pieter not sure I agree with you. They've already implemented a BIM mode. It seems like the only way to really solve the problem. Anything else is a workaround.

    I see that we have BIM data now but it hasn't really proven useful to us yet. Can anyone state for the record how this feature is working for them? And how they are using it in meetings, etc?

    I'm still waiting for the essential feature of measuring from one point to another point in the Enscape environment...are we still developing that feature?

    yea we struggle with this as well...we end up just re-saving the view and deleting the original because there's no way to "push" the nuances in sun setting or camera re-positioning BACK to the view. Which is a confusing pain point for some projects.

    But furthmore...

    And even if it did, what if that view has a VT that is locking that from changing? Would Enscape tell us that it cannot complete the transaction? Or would it be able to update the VT? Or remove the VT from the view?

    And if it cannot, seems like a valid point to suggest that Enscape should catalog its views in its own browser UI? Independent from Revit's project browser?

    Pieter Your point about a level playing field across the applications is well taken.

    Pieter  renderwiz i'm interpreting your above points support the idea of having Enscape handling the properties of the view directly in its own UI, is that correct?

    Like...are we suggesting that Enscape control the below elements within its own dialogue box (it will basically have its own VGO Panel)???

    aka..all of the below controled DIRECTLY in Enscape UI (not pulled from a view's view properties)

    Model Categories and Subcategories

    Imported Categories



    Design Options

    Detail Level

    Parts Visibility

    Discipline Setting

    Lighting Settings


    Phase Filter

    Section Box

    Temporary Hide/Isolation

    Manual Override by Element

    Linked File properties for all of the above

    Yes, we do have plans to support both for the material editor. Right now normal maps are only supported for the new Revit 2019 materials.

    However if you've got normal maps for your material right now, you might want to rename them with an _n at the end of the filename (e.g. myfile_n.png). Enscape will pick that up and interpret it as a normal map ;)

    Hope that helps :)

    Clemens Musterle Woah I've never heard of the "_n" suffix. Does that mean that it won't be a normal map unless that suffix is present? Please clarify.

    Thank you - I'll file a feature request for this accordingly. Anything else you'd like to enable/disable via a hotkey? Just so that I can also add it as further feedback. :)

    If we can change the UI for the sync instead of ON/OFF, set it to "PUSH". Meaning its off by default but we hit one hotkey and then it pushes the data once. Basically syncing as needed instead of ON/OFF

    Demian Gutberlet Thanks for your reply -- I think we should have the dev team describe techinically what is happening so the userbase can provide better feedback. Give us an understanding of the back end so we can help you with the front end. I remember older versions of Enscape where this was not as big of a I crazy to think that?

    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.


    I have 5 views that all use the same view template.

    In previous versions of Enscape, I would just star them all and it would run through each vantage point really quickly and export renderings for each of them.

    Now with the latest version, it's re-exporting the model for each view, taking twice if not three times as long with no benefit to quality.

    Is there a reason why the model needs to get re-exported everytime? Why did it change?

    If I want to make a table and chairs family with people already loaded in them it doesn't work. Can we fix that?

    Ideally would prefer to pre-load assets into furniture families and have an instance based parameter to turn on/off people