Posts by Clemens Musterle

REMINDER! If you encounter any issues with Enscape (e.g. crashes, installation problems) or your subscription please reach out to our dedicated support team directly through the Help Center or by using the Support button as detailed HERE! Thank you for your understanding.

    TonyChang we've had a look at the Sketchup project you've provided. Unfortunately the performance problem is due to the extremely high number of light sources on the ceiling that are placed very closely to each other (I assume to simulate an LED-stripe). I would recommend to remove these small rectangular light sources and replace them with geometry that has a self-illuminating material instead.

    This is by the way not only a performance problem on Mac, but even on a high-end windows PC (Nvidia RTX 4080) you will have terrible performance with a light setup like this.

    @kgruenewaldcharch which Enscape version exactly was the second image rendered with? There was a bug with 2d billboard shadows (with enabled ray-traced shadows) in the initial 3.5 release, but it has already been fixed months ago in the 3.5.3 release. Please make sure you're on the latest version (you can also disable ray traced sun shadows to verify if it's this bug in the rendering settings).

    That reminds me - are the emissive materials screen spaceonly in their effect?

    I had it in my head this was the case, but I seem to get inconstant results during my testing where they appear not to be, then later down the line they will be again.

    No, emissive materials have also an effect on GI if they're off-screen. However, and that's probably where the confusion comes from, there's no guarantee all (off-screen) emissive geometry will always be considered for GI. Depending on their size, geometric complexity and distance to the camera they might not be selected. This can indeed lead to inconsistent results depending on the scene. But if you're using hardware ray-tracing the geometry budget for GI is usually big enough that most nearby geometry will be considered as can be seen in the examples Paul provided.

    Regarding LED strip lighting in Enscape - is there a light type that is the least resource intensive? Does it make a difference if I use an IES light versus disc light, etc? I've done the same thing (adding hundreds of small lights to better mimic the LED light source, used as lighting in a scene)

    On this scale it doesn't really matter what types of lights you use - it's primarily the sheer count. So if you can reduce the number of lights by half, by using rectangular/line lights instead of e.g. discs it will also simply half the computation/loading time in this particular case. While IES lights are theoretically a little more expensive to render in general (look-up of the IES profile for each shading operation), I would guess you will hardly notice an impact on your frame rate using them.

    Out of interest, would there be an alternative solution you'd recommend for doing curved LED lighting, I need to find another way clearly, but not sure if there's a solution?

    That's indeed a tricky problem to solve currently. If it's not crucial to have the LEDs light up their surrounding (e.g. on a day-time scene), I'd recommend to only use geometry with an emissive material. This unfortunately might introduce more noise in the Gi calculation, as the stripe is thin and the probability that a Gi ray will hit this geometry, is therefore low. You can reduce that noise by choosing a rather low emissive intensity value.

    We've had a look at the project internally and found the cause for the extremely long loading times, which will eventually abort, leading to the broken Gi lighting:

    It's in fact a combination of two things in this scene:

    • There are thousands of small model instances which are the different railing posts
    • There are more than two thousand light sources in the bar room

    There's currently a code-path handling scene updates that can be extremely slow in such cases, which is responsible for the long loading time. I'm optimistic that we can optimize that to a large degree (I've managed to bring down the overall export & loading time to ~3minutes) and we can ship that fix in a future service pack.

    In the meantime I'd recommend to rethink simulating the LED-stripes with thousands of individual disc lights. This approach not only affects the loading times, but also real-time rendering in general struggles with that many lights concentrated on a small area.

    I'm not a Sketchup modeling expert, so I don't know if there's a good way to model the railings differently, so that not each post is exported as an individual instance. But in the end this is something users cannot really control well themselves, so we'll have to see if our CAD export developers can come up with some optimizations in that regard in the future.

    Hi minh and welcome to our forums!

    The difference in noise that you can see on the sideboard are related to different techniques used to denoise the rendering during walkthrough or for capturing. In some cases the denoising in capturing can currently result in these speckles on surfaces with a material with medium roughness.
    Unfortunately there's currently not much you can do, except try if other roughness settings of the material look ok and reduce the effect.

    We're already working on an improved denoising solution for capturings!

    Curious if there's any estimate for when this is getting fixed. I can't use 3.5.3 until this is resolved.

    There are currently two issues at hand here. The original issue reported at the beginning of this thread is unfortunately a known limitation in certain indoor scenes with our current denoising solution for video renderings. We're internally working on completely overhauled solution for the next major release.

    The recently reported much more severe problem (video export image quality bug) is in fact a bug that unfortunately was released with 3.5.3. We've fixed the cause and hope to ship it with the next service pack release soon.

    Is there any artificial light source in the area that could light up the scene? If yes, maybe make it brighter. The "false lighting" you see comes from indirect lighting inaccuracies, the darker the overall scene, the higher the exposure setting of the camera and with a very high exposure value small inaccuracies like this can stand out quite strong as in your screenshot.

    Which version of Enscape are you using and what are your visual and renderer settings?

    Using 3.5 and hardware ray tracing (renderer settings), should solve that look. If you don't have the option to use hardware ray tracing, try reducing the "Ambient Brightness" slider in the visual settings. Also switching to Ultra quality should improve the lighting quality there.

    Hope that helps!

    Unfortunately 3.5.2 doesn't fix the over-exposure / everything beeing too bright bug that is present in VR mode. Is there any workaround other than downgrading? Currently I am dialing down the expose setting manually, but things get a bit dark then.

    We'll provide a fix for that issue in the next service pack release soon. Unfortunately it didn't make it into the 3.5.2.

    Is there some sort of logic I can follow to avoid automatic downscaling of my materials? I'm not sure I understand why Enscape would do that on it's own, when it's very simple to replace the material maps with higher/lower resolution files individually as needed. Plenty of memory available.

    Here's another example of a nice Carrara Marble that loses a lot of the vein definition. It's scaled per the Poliigon guidance (8'-2" x 8'-2") within SketchUp and Enscape, but it being compressed it seems still.

    Right now, there's no option to avoid that. We discussed adding something like a check-box to the material editor like rifkin suggested, but it wasn't a priority yet. The reason we do it, was quite frankly, because people are simply not aware how much memory such high resolution textures consume and it'd be a cumbersome manual task to go over potentially hundreds of materials and manually downscale their texture maps. Running out of GPU memory is actually one of the most common issues people are facing with Enscape and texture maps can eat up a significant portion of that.

    While the current behavior might not be ideal to do a close-up shot of a textured surface the texture resolution is usually high enough not to be noticeable for any 'regular' camera perspective.

    For what it's worth I'm not aware of many complaints in that regard, however we might revisit the parameters for future releases as we see that more people upgrade to newer GPUs with more VRAM.

    Hi Tim

    what's the texture scaling in the material? Enscape automatically downscales textures that have a small scale in the scene to avoid unnecessary memory consumption. Thus if you increase the scale in the material the 4k resolution texture should look notebly different from the 2k texture. We support up to 16k resolution for largest scale use-cases, e.g. using satellite images on an environment model.

    Here's an existing thread on the topic:
    RE: Material albedo maps rendering at low quality - blurry

    Thanks for this but, as far as i am aware, there is no option to select the alpha channel when export to jpeg.

    That's correct. Can you select png first & make sure the "apply alpha channel" checkbox is not set, then switch back to jpg and try rendering again?

    This might be a settings glitch.


    I'm getting some weird black blocks for some reason, and the color got really weird (not supposed to be that yellow) But this gets me in the ballpark of what I'm trying to do. I'll fiddle around with the settings to get it looking right.


    Hey davidhard , those blocky black artifacts were a problem we've had in one of our Preview version releases. Did you upgrade to the official release 3.5 version yet?

    This blue tint is caused by indirect lighting by the sky, as probably some of the building's geometry is omitted that would otherwise block the visibility of the sky. Unfortunately without reducing the polygon count you only have limited options. But you can try to place a single, big plane (thus it only adds 2 triangles to the polygon count) right left outside the camera's view into the hallway. If you've surpassed the polygon limit our algorithm tries to select geometry that has a big surface area relative to it's polygon count first, so it's likely that it will consider this plane for the indirect light calculation and it'll block the sky's light.