Posts by Pieter

Quote from Harrigan184

To create a material, simply open the open the Materials tab in Rhino, or type 'Materials' into the Rhino command line. Click on the large + symbol and then choose 'Enscape' as the material Type.

I think Toscano is referring to a faster method to open the right material by just clicking on it with an eyedropper in the enscape render window.

That would save a TON of time in my opinion. You can vote for the suggestion on the voting portal here: https://portal.productboard.co…ge-materials-from-enscape

I understand. If the image would look worse overall, I think turning SSAO off would not really be a solution.

Thank you Demian!

Thank you for the explanation, it does help knowing that you guys are aware but that there's no immediate solution. It's unfortunate, but I understand that with real time visualization (or any visualization really) some trade offs have to be made, and that's a process of continuous improvements.

Presumably the SSAO is baked into the rendering and cannot be turned off through the UI, right?

Clemens Musterle Demian Gutberlet

Is this on your radar? Are we doing something wrong?

Demian Gutberlet is there any news about this? Did the developers have a chance to check the technical feasibility?

There are keys to increase the speed: hold shift to move faster, hold shift+ctrl to move even faster. Also, you can double click on any object to 'transport' to that point.

I did some tests and made an asset of 2k and instanced it a hundred times. I didn't get the "the model is >20k poligons!" in the asset editor, but that doesn't mean of course that Enscape is rendering the instances using GPU instancing.

Sometimes I need to make an asset that has many duplicates of the same object. For example: a bowl of fruit with 20 apples, but all the apples are identical duplicates. Or for example a tree with leaves, but each leave is duplicated (using the 'instancing' method) many times. Meaning, in my GLTF file, the mesh of the apple (or leaf) only exist once.

Does Enscape support the instanced drawing of GLFT instances? And therefor, will my assets be performing better in Enscape when I use instanced duplicates of objects inside my asset? Or will it treat instanced duplicates as regular duplicates?

Some more info on GLTF instancing here: https://community.khronos.org/t/instancing-in-gltf/106027/2

It could make a big difference. Some assets might be only 20k poligons with instancing, but 250k without instancing.

If you can share an example file here I can take a look.

What format are you exporting to from Blender? Have you applied the transforms in Blender (CTRL+A -> all transforms)?

My plugin wasn't processing 3D data, I just took the .gtlf 'as is' and just applied the necessary naming conventions to make the asset workaround work. I would expect that anything that you put into my plugin, would also work when loaded into the official asset editor.

Quote from ap1

The "additional render appearance paths" method is what I have used, but I'm thinking that only works for Revit material browser textures?

This feature works for all materials in my experience, whether or not they originated from the Autodesk material library.

Quote from ap1

I haven't really dug into the Enscape duplication of the material library yet and how those textures work/interface with Revit. I guess I'm getting old enough to be a bit more stubborn in my ways

It's quite simple really. When an enscape material is brought in from the library, two things happen:
1) enscape creates a new revit material

2) enscape downloads the maps (if they aren't download already) and sets the paths in the revit material

So at the end of the day when an Enscape material is brought in in Revit, it's just another Revit material. There's not really anything special to them. It would be similar as if you would create them manual from scratch.

We should also note that Revit has a built-in system to deal with the missing textures called "additional render appearance paths".

If the architect could give you a folder with all the missing textures (it's important that there are not in subfolders, just a single folder with all the textures), you could point Revit to that folder and Revit will go look in that folder for any missing texture files automatically. I think this might work well for what you're trying to do.

Quote from TimAlsop

My understanding from the info shared so far is the following:

1. When my architect installed Enscape, the Enscape materials are installed into his user folder, e.g. C:\Users\<architect user>\Enscape\...

2. When he used the Enscape textures/materials in the Revit project, the Revit software links to these textures/materials in his user folder (see 1 above).

3. When I open the Revit project on my PC, it can't find the textures/materials because they are in a folder that doesn't exist on my PC.

Is above correct ? Have I understood the issue correctly ?

Display More

More or less. Just for anyone else that might find this post by googling: the Enscape materials aren't actually 'installed'. I think the idea is that the texture library will grow over time (just like the asset library does). Including all assets and materials would make the installer huge, and it would mean that enscape would take up a ton of space on your hard drive. For that reason Enscape has the assets and textures on the cloud. The individual materials or assets are downloaded when you actually place them (but only on the computer of the person who is doing the placing of course).

When another user opens the model, the missing assets will be downloaded automatically by Enscape (you won't notice anything, this happens on the background). But with materials textures this is not the case (and it would be hard to do so given how Revit and other BIM programs deal with texture paths).

Note that you can actually configure the folder that Enscape uses to store them. By default this is in the <my documents> folder but nothing is stopping the user to configure this. But this needs to be done before you start placing materials. If you change your location mid project, it will not affect materials that have already been placed.

I understand the sentiment of 'there should be a better way', but it's not trivial to come up with a way that will work well from both the Enscape and Revit perspective. This is why I made the plugin: I couldn't think of a way to fix the issues without some kind of external application to do some of the troubleshooting.

There's a parallel here btw: 3dsmax has the exact same issues for over 20 years and people just deal with it there using plugins.

I want to release my plugin at some point but I'm a hobbyist programmer and don't have a ton of time to work on the installers and upgrading to the recent Revit versions. Maybe Enscape wants to sponsor the project so I can wrap it up and release it to the community for free ... ?

It needs some small code changes and especially a new installer for revit 2023.

Your architect could run it to collect all the textures, and you could fix the paths manually on your end then. That might be a small job if we're only talking about a few materials and you know what you're doing.

You can send me a direct message here for a download link to the plugin.

For this kind of workflow I made a plugin that exports all textures to a folder, and then you can use the same plugin to fix all the paths on the receiver's side.

It's working and I'm happy to send you an experimental link, but I'm afraid I only have a Revit 2022 version of the plugin at the moment.

Quote from TimAlsop

I shared this with my architect and he said that the materials are standard materials supplied with Enscape and not custom, so he doesn't think it woulld be necessary to do what you said.

I'm wondering if the issue is somehow due to the fact he is using Revit 2022 and I am using Revit 2023. I think the version of Enscape we are using is the same (latest version).

Revit version has nothing to do with this.

I believe the architect might be mistaken here. Unless I'm mistaken, texture maps that came from the Enscape material library aren't automatically downloaded when you open a model (unlike assets, which are automatically downloaded when launching a model). It's in fact a bit tedious to transfer textures from one machine to another, as even if you had the textures, the path's will likely not be the same and you would need to repath all of them.

Have you considered using the .exe exporter for Enscape instead? That one has all the textures baked into it. Or do you want to edit things in Revit?

My asset creator was useful when Enscape didn't have their own solution. Since Enscape 2.9 Enscape has a great custom asset creator that's much better then my editor so I recommend you use the official one instead (it's what I do as well).

There a few updates to the official asset editor in beta right now that will make it even better (you can download the preview and test it out yourself).

The only thing I still miss from my asset editor is being able to see the statistics (placeholder polycount, gltf file size, texture file size) because that was very handy to QA/QC.

Unfortunately Enscape only shows materials of the 'generic' type in the Enscape material editor. To convert a Revit material to generic do the following:

1) open the Revit material editor

2) open the missing material

3) rightclick the "Appearance Tab"

4) select "duplicate to generic"

5) hit Ok

Now the material should show up in the Enscape material editor.

Maybe to extend on that: in our models a significant (probably the vast majority) of the policount and texture load are because of the assets that are placed in the scene.

Currently when I update something in my CAD (for example move a door), will it also reload all the assets from scratch? If so, would there be a way for Enscape to detect when this is unnecessary? I realize this isn't trivial as updating the view in the CAD could trigger certain assets to show up/hide. But perhaps there's an option to skip reloading (part of) the buffers at least?

I'm afraid I don't have a ton of free time atm to write up a detailed tutorial. Also, I imagine that the tutorial might become obsolete quite quickly as asset overrides have been requested so many times by so many people that I would be surprised it wasn't introduced as a feature at some point.

The field of view is defined in the image settings, so if you want to save it, you'd need to create a new image setting and link it to your view. But I think the more intuitive behavior would be, as you describe, to FOV it inside the view itself.

Time of day should be saved, although in Enscape 3.3 you cannot adjust it after the view is created (unless you go through the host application). But it's on the roadmap to be able to change time of day.