How to isolate materials in White Model Mode

  • Is there a way to direct enscape to keep the material properties of certain materials when entering white model or polystyrol mode? Default settings keep glass to have their material properties, but I would like to use a generic emissive material with color and have that color remain. The end product is intended to be a white model with a bright, colored light that runs through it. The best I have been able to do so far is to use yellow glazing, but this loses the emissive quality.

  • We have a story on our agenda that would allow you to exclude materials from the white/polystyrol mode by adding a keyword.

    =>Got your upvote.

    Just curious: by adding a keyword to the material name or by adding a string in the settings of the white mode?


    I think it would be better to have a include/exclude list of material names in the Enscape dialog. Biggest reason: material names are part of the documentation of the Revit model (in some areas like some schedules you only have access to the material name). So having to mess with a material name in order to render is not ideal.

  • @Jonathan


    We would not want that tag to show in the schedules as it has no value for the contractor/client/consultants.


    The door schedule would now read


    Door Finish: Black Metal [EXCL FROM OVERRIDE]


    That's going to be problematic in a real world workflow. Contractors are going to be very confused. Can't it be implemented as an exclude list in the enscape settings dialog so we don't have to mess with material names? For example a list where you can type (part of) material names. So I can type in "Black Metal" in the exclude list and it would exclude all materials that have "Black Metal" in their name?

  • Totally agree. Any solution excluding further material name messing in revit would be very appreciated. The same goes to grass variations (instead of using grass neme - it would be better just to include sliders for grass height/variation into enscape settings (I know it's more complicated for programming, but it's deffinitely better approach for most of the issues))

  • Pieter , I hear you, your proposed exclude list suggestion is now added to the topic.


    some1new , to make sure I understand you correctly, you'd like to keep the "grass" keyword, but add the ability to define whether its "tall grass", "wild grass" or "short grass" via the settings? Otherwise, how would you be able to add grass to a material? We could implement a separate functionality for that, but that would be quiet some effort to avoid using one keyword, but I can file it as a feature request. Maybe you have another solution in mind? Further, the ability to adjust the general height/variation of grass in Enscape for Revit is not yet available, but I'll happily file this as a feature request as well. :)

  • some1new , to make sure I understand you correctly, you'd like to keep the "grass" keyword, but add the ability to define whether its "tall grass", "wild grass" or "short grass" via the settings? Otherwise, how would you be able to add grass to a material? We could implement a separate functionality for that, but that would be quiet some effort to avoid using one keyword, but I can file it as a feature request. Maybe you have another solution in mind? Further, the ability to adjust the general height/variation of grass in Enscape for Revit is not yet available, but I'll happily file this as a feature request as well. :)


    The problem is that for some applications (Sketchup and later Rhino), you are providng (and using) the ability to add custom Enscape parameters (like water settings, grass height,...) while in other applications (Revit, Archicad) you're strictly sticking to the provided native material parameters. That creates feature disparity every time a new custom parameter is introduced. The problem already exists for water and grass, but it might get worse in the future if additional features are added (rounded edges, grass on vertical surfaces, for example)


    Different solutions are possible here:


    1 - provide Enscape material editor everywhere (in sync with the native materials so if we change a material diffuse map it changes it for the Revit material as well) (this would also open the option of a shared "enscape material library" between different applications)

    2 - provide minimal material editor that only give access to parameters that don't exist in native application

    3 - provide custom keyword builder so we can build our own tags (for example"grass_long" = render as 3d grass + height 10cm)


    If you go the third route, it would be an interesting idea to also scan the Revit Appearance Name (not the same as the material name) for keywords as well because that field is never scheduled or tagged, while the material name is part of the official documents and therefor cannot be changed just because we want a different look (see screenshot).

  • Pieter , my apologies for the delay in response. I'll happily file a feature request regarding this topic so that our developers are aware of the demand for this kind of implementation, please just let me know, which of the three proposed solutions do you prefer the most? :)

  • I don't really have a strong preference, it would depend on the implementation. Each one has up and downsides.


    Perhaps #1 would be the best but if would have to be

    1) in sync with the Revit materials (as many parameters as practical but at least the albedo)

    2) ideally, it would not be a standalone editor but rather an overlay in the Enscape rendering window (combined with a pipet tool), see workflow example below (click on 'see more')



    Having the same experience (and UI) in all platforms would also make the for training and documentation. It would also be easier to learn from each others work if we shared the same material UI.


    I know it's a big ask but this is more of a 'this is how it could look in a perfect world'