Posts by Pieter

Quote from Tobias Bauer

But as Joachim said, so far we received mixed feedback. We need to have more feedback from more users to make further decisions on a solid basement. Since not all our users are using the preview versions, we will wait after 3.0 is released to get more feedback. But again, this topic IS on our table and we are observing it. But we did not decide to change the current behavior, yet.

Although I personally don't mind how the current release works, I do have sympathy for Herbo's (and others) concerns.

Perhaps part of their frustration is that what they are proposing (keep the settings in the render window but don't start the renderer automatically) seems like a good solution, without compromising on the advantages of the current design of having the settings integrated in the frame buffer. It also (perhaps wrongly) sounds like relatively simple to implement. But maybe it's waaay harder than it sounds, and is that also part of what's holding you back?

@Demian and others, any idea whether this was fixed in the 3.0.7 release candidate?

There's another usecase for not wanting to have the model loaded on launching the Enscape render window: what if I want to go directly to a saved view with different geometry/render settings: do I first have to load the entire window with standard settings to then throw that load away to load the saved view?

I know In Revit there's still that dropdown, but with these new UI changed, my expectation is that most people will stop using that in favor of the viewlist in the render window.

Quote from cyrusinc

Is the fact that the models are vray models with vray textures a possible cause to this ? Though I do convert the scene to a regular max scene to the same result.

yup, vray materials will not be evaluated by most exports, including the gltf exporter.

There are scripts out there for max to convert vray materials into regular materials, but it's hit and miss. Vray can do things that regular PBR materials do not have support for (like explicit fall-off ramps etc) so a 1-to-1 conversion is impossible.

You can also of course manually do it, if it's only a handful of models.

Edit: it's not the active rendered that matter but what material nodes the materials use. I think gltf only supports the standards and physical materials.

Are you using the official enscape asset generator or the old generator?

I highly recommend using the official enscape generator. It's way better than my generator tool (I wrote that tool from before there was an official tool).

When you export from max, are the textures included in the export? (so do you see the exporter writing them to the selected folder)?

Submitted!

Crashes happened yesterday afternoon about 5 times, all in Revit 2020 with Enscape 3.0.6 preview installed. It crashed every time I tried to set my workplane.

do you want me to install the faulty version again first?

Just installed Enscape preview 3.0.6, but soon after Revit started crashing to desktop (this is without Enscape running, the render window isn't even opened).

I can recreate the crash by opening a 3d view, go to the architecture tab -> set workplane -> pick a plane -> select a plane in the model

Once I uninstalled Enscape and installed preview 3.0.4 again, the bug went away.

Pretty peculiar!

Quote from Rick Marx

Hi fEdeG

As Demian mentioned, changing the time in Enscape and then creating a view with Enscape should save the time in the saved view.

As we don't have any time parameter in our Visual Settings, it is not necessary to save and link these to a view.

Could you tell me what CAD you are using to see if there is anything else that might help here?

Display More

The problem is: there is no way to update the time of day or camera position. You'd have to create a new view and link the settings to it every time you want to do an update (and then go find the old view and delete it).

There's also no way at the moment to save sun overrides (ctrl U/I and alt U/I). They do not get saved when you create a new view.

I think it would be much better if we had the option to save the time of day and camera position inside an 'enscape scene'.

obj is unitless, so enscape has no choice than to assume your model is in meters. So when you export, you need to make sure that

1) the obj is exported in meters (either by setting your scene to meters, or by using an exporter that can scale it to meters on exporting)

2) make sure that all scale transforms are applied (I think it's called reset X transform in max)

That depends on your .obj exporter. The blender one for example keeps the material names.

Perhaps it would help to convert the object from vray to standard materials before exporting to obj? If you use normal maps, obj should be able to keep the material maps intact.

I believe there are converter scripts out there that can automate the vray-to-standard-material conversion.

That really looks like flipped normals to me.

It could be that the normals are being flipped by the exporter (or even by the importer in the asset editor). Hard to say without seeing the files.

could be inversed faces. When you go inside the mattress, and look towards the opening, do you see the faces or can you look through it?

Question about the feature design: will the views panel on the right eventually be retired? And if so, will there be a way to switch to a view so that it updates the camera/view settings but does not reload the geometry.

Yes it's rare that the previews are missing features, but I actually think it's a good thing because it allows the developers to experiment more and put things out for testing without having to polish everything first.

They are not removing it permanently, it's just temporarily turned off because it was not ready for testing.

I'm not sure what you mean with 'current'? Are you on 2.9.1 or a 3.0 preview?

Sounds like you are using the preview version, in which the video editor doesn't work currently. It's in the release notes of the alpha.

If you don't want surprises like this, you should stick to the official releases (2.9.1 is the most recent one).

Quote from andybot

Can you elaborate on any UI requests they are addressing? So far (from the outside looking in) the changes seem needless.

Addressing highly requested features is of course very important, but there should be room for developers to also put forward their vision on the product. Also, keep in mind that the people that request features on the forum tend to be power users who are only a small subset of the users out there.

My users (architect, not professional visualizers) have never been on this forum, yet they have been very enthusiastic about the UI changes in the last previews. They think it makes Enscape easier to use. I understand many of the power users here disagree so I hope the developers can find a way to address your concerns while also keeping all the things that make the new UI work well for my users

Edit: for what it's worth, I think Herbo's proposal of not launching Enscape rendered automatically while opening the enscape window is a great compromise.

That model has a few problems: it's 700.000 polygons (35 times the recommended limit), doesn't have any materials assigned to it and is off scale (it's 1.2 kilometer high).

You'll need to do a lot of work on this model to get it to work properly for Enscape. I'd recommend finding something that's closer to Enscape's recommendations.

Quote from andybot

I think batch panos are much more critical than fiddling with the UI.

That depends on your workflow though. If you use panormas a lot, I'm sure it's very important to you. We rarely use them, so for us it's not critical at all.

Regardless of our different workflows, we all use the UI, so I don't think it's crazy that they are spending some time on it (although we may have different opinions on what's a good UI )