Posts by AugustR

Hi all, not to revive a dead thread, but I believe I may have encountered this issue myself. I originally attributed it to Revit, and posted here - Solved: Re: Revit 2022 Crashes while making changes in Material Browser - Autodesk Community - Revit Products. Another user who had the issue there noted they also had Enscape running when it happened...hence I wound up here.

Using Revit 2022.1 with the latest hotfix, and using the latest version of Enscape. In my case, Revit crashed when I was trying to edit the material of a family while Enscape was running - however Enscape was running in the main model, not the family (so I wasn't interfacing with it).

Let me know if there's anything else I can provide to help investigate this issue further.

I'd love to see this!

I'm not an expert, but it certainly sounds like a GPU issue to me, especially if changing the view to draft quality brings them back on. Maybe the Enscape Team can confirm if there are systems in place to auto-turn off geometry (in this case, light objects), when the rendering task becomes to taxing for the computer.

It looks like you are rendering out a video in the first image - does this happen if you render out a still image as well?

I'd agree with others, it looks like auto-exposure may be the culprit. In the view with your lights turned off, the image doesn't actually look any darker - this leads me to believe that the scene isn't being lit by the light objects, but by something else. Maybe ambient light, maybe exterior sunlight. In either case, I'm betting the exposure level is causing the problem, most likely as you noted because you also have a lot of very dark surfaces that are causing the exposure to be bumped up significantly. This is allowing the detail of the dark planes to show up, but is blowing out your white surfaces. This is a pretty common issue, and actually can easily happen with a camera in real life too - it's really a function of our eyes being very good and looking at light and dark portions of our vision at the same time, when in reality the contrast would be too strong.

One thing I frequently do to get around this is I rarely render with surfaces as true white, unless I'm doing everything white for a more diagrammatic look. Otherwise, all white surfaces are actually a very light grey. As long as that light grey is the lightest surface in the image, you won't see it as grey but just white - but the addition of the grey helps cut out some of the wash-out effect of the exposure.

Since those lines aren't actually geometry, they won't be rendered. Sorry. In most cases that's the preferred functionality anyway.

It would be cool if they added a way to support it - maybe some day.

I agree, it feels like the min and max height for the grass is a bit arbitrary... I've had instances where I both want the grass to be shorter (trying to make a turf material which would be very short, like a putting green), or longer (for a field or a planter with wild grasses, which could be as long as a couple feet). It would be nice if we could have that control over the slider - I get it may not look as good but I'd rather an option that doesn't look great than not being able to do it at all (bump-maps for short grass only work if you're far enough away, and I don't want to have to manually place hundreds of grass assets to mimic a field).

To the original poster's point - I haven't checked out the newest version of Enscape so I'm not sure if this is how it works, but is it possible the "clumping" of the grass is due to a wind setting?

EDIT: While we're on the subject of grass...I'd also love the ability to have multiple grass materials, each with their own height setting. Sometimes I want to have two different types of grass in the same render view (an area that is mowed or is turf, vs a longer, wilder area, for example).

I don't believe SketchUp supports multiple section planes being active at the same time...? Perhaps someone else can correct me if I'm wrong.

I would say your best bet is to physically cut the model where you want the section taken, select all the stuff that should be hidden when the section is active, group it and hide it in that view - this will create the illusion of a section being active. You could then turn on another section (or do this process again) to make it look like there are two, simultaneous sections.

Or maybe I'm wrong and SketchUp does support multiple sections, in which case the issue would be Enscape doesn't...but even if that's the case, my suggestion above would still be a viable solution.

So the "default" color is just that, the default. It isn't explicitly white or black or any other color. My guess is at some point the default material has had its color changed, causing this result. This could have been done through the material dialogue, or it could be through the current style settings. Under the "Face Settings" section you can change the front and back color of faces for that style - which should then show up on any face that has the default material applied.

Alternatively, perhaps you are in a group that has a material applied to the group? if you assign a material to a group as a whole (rather than going into the group and painting specific faces), it will make the default material for that group be whatever you painted - so in your case, some sort of black materal.

Hope this helps.

As DeKoetsier mentioned above, displacement maps are probably what you really need - but in their absence in Enscape, you very well may be able to get away with using a bump map (depending on how close you are to the object). https://enscape3d.com/communit…wledgebase/sketchup/#bump

Quote from renderwiz

Some of the survey responses do not fit my answer to the question. Ie.

How do you feel about the usability of the video editor in Enscape?

Complicated is not the word I would use. It is un-intuitive and overly simplified.

The timeline editor would be easier to use if the UI were more "complicated looking" because we would then have direct access to more variables, rather than having to repeat specific steps in sequence in order to achieve something like change the relative time that a keyframe should be set to.

Try studying existing packages like 3dsmax or Cinema 4d, their timeline / keyframe editors may "look" more complicated, but are actually simpler to use when attempting to achieve a specific type of movement.

Even better than attempting to write a perfect video editor that can be both simple and capable, would be to allow import of camera animation from another package. This way you could keep a simple UI for Enscape's native "video editor" AND allow complex animation by those who likely already own and use 3dsmax, Cinema4d, Blender, etc.

Display More

I would like to echo this 100%. Being able to create video walk-throughs would be great (and would be a great alternative to exporting .exes - one of the big problems with these is not being able to curate the way that a client sees the project, for example if areas are not done or if the sequence of spaces is important), but currently we don't use it as the system is so dumbed down that it's actually very difficult to get a final product that looks good. Since there isn't much fine control, it is very difficult to make small adjustments to the camera and to have a video that doesn't appear "swimmy."

Quote from renderwiz

While I hope Enscape will eventually allow for this type of animation I won't hold my breath. It will take significant effort, and this type of functionality exists nowhere else which indicates it may not be feasible.

Lumion has a (relatively) robust animation system built into the engine. It allows for translation/rotation/scaling of objects over time based on their internal origin/axis. It can be a bit of a pain to use sometimes but it definitely works.

I ran into that problem too. Sounds like it may come down to your machine's hardware and the settings at which you are rendering at. I would recommend adjusting overall quality, as well as FPS to see if you get better results.

I'm not sure what you mean by "jumps of speed", but...

If you're talking about the fast portions of the video - did you preview the video path before rendering? I find that the path system tried to guess how much time you want between waypoints, but sometimes doesn't guess correctly and you wind up with particularly fast portions when the camera position doesn't move much between the waypoints. Previewing the path can give you a good idea of which areas are too fast (though depending on your machine the preview will overall still be slower than the final rendering), and you can adjust before rendering.

If you're talking about the subtle but still perceptible "skips" that happen periodically - I had this problem with my machine, and I think it's simply an issue with the power of the computer. I bumped the quality down a notch and that problem went away. You can also adjust framerates to "lower quality" without actually lowering the quality - in most cases, you shouldn't need more than 30fps anyway.

Supported as well.

Related thread located here: It is hoped to improve the stability of the asset library window

Quote from Demian Gutberlet

Release is today!

Well! That works out splendidly! Keep up the great work guys.

Demian Gutberlet Do you have any sort of estimate for a 2.6 release? I understand completely if you don't want to promise anything - I'm just trying to get a sense of timing (like is the release closer to a month out or more like another 6 months? A year?). I'm hoping to introduce Enscape to our wider office and get other employees here to start using it as I think it could be a very helpful tool. However I saw on the Development Agenda that part of what is coming is a Settings Overhaul, and if this is something that is coming sooner rather than later I'd prefer to hold off on the office-wide introduction so people don't learn one thing and then get confused a month later when the update lands.

Surprised relative paths for assets hasn't been implemented yet. Absolutely adding my support here.

As Demian Gutberlet mentioned above, it is on their agenda but there no details of its implementation have been released yet. See this topic for more back and forth about the suggestion.