Posts by mattendler

    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

    In Revit, A change in a linked model is not reflected until that model is reloaded. Only then should Enscape look for changes in links and re-export them.

    Additionally, when there is a sync to central, this does not update links so enscape shouldnt be looking for changes in linked models at the moment either.

    Currently, moving a column in the host model will trigger Enscape to look for changes in all models and export all of them. Its inefficient - can we change that?

    bump. This is still valid. Its additionally helpful because when you mouse away from property tab changes it tries to auto-enter, and sometimes there's a loss in UI stability when the auto-enter and auto-printing (live updates) function are on.

    I would prefer the screen to say "Needs update, click this button"

    Sorry for replying so late - as of yet, the plan is to have FOV, among other settings, saved in the corresponding views with Enscape 2.7. While I cannot make any definite promises yet, I'll still forward your feedback to our developers too. :)

    Demian Gutberlet That sounds good thanks. Lets just make sure there's a way to change the FOV of a view once its been set. A management workflow of some kind to check all the FOVs being used across all project views.