Posts by Clemens Musterle

    OK, I understand this but, does this not mean we are basically talking speed here ?

    Speed is one factor, memory another. Whereas speed is a twofold issue: The actual runtime cost of tracing more geometry during rendering (and this is also largely dependant on the kind geometry, so this doesn't scale linearly, but also the required preparation. So it's not a simple equation of taking 2x the geometry and receiving 2x rendering time. Memory is even more critical - if the resources don't fit into your memory, there's not that much you can do.

    I absolutely understand the urge to get more control of these kinds of things as a "power user" and trust me, we've discussed those options internally for many times as well. We do want you guys to be able to achieve optimal results, but at the same time we want Enscape to stay accessible and straightforward to use in a stable way. We're confident to achieve both of these, getting better and closer with every release. I don't want to exclude the possibility of having more options in that regard in the future, but most likely the focus will remain on further optimizing our "1-click" approach e.g. by leveraging more of the available capabilities based on your gpu, which will benefit all user demographics.

    with all due respect , this is not correct IMHO.. I think we are already discussing things a little more specific here, please read the posts a little more thoroughly. Clemens already stated that enscape is in fact already calculating twice as much reflections when rendering vs. live view.

    This means that the engine can do it.

    To some extend yes (when talking about content beeing visible and not other features), but there're still hardware dependant limits and those are not as easy to control as a user. And please beware that as Gadget already mentioned - still image and video rendering are just some features among others and depending on your focus as a user might or might not play such an important role when using Enscape. That beeing said you still can expect further quality improvements in that regard in future versions, however the basic concept of Enscape beeing a very accessible (real-time) rendering tool for everyone is not planned to change.

    Clemens Musterle - if there was a way to render a 'standard' capture in the same manner that panoramas are rendered (meaning how the render frame scrolls from left-to-right across the image field), that would be fantastic, and would seemingly eliminate the problem... I don't export very many panoramas, but when I do they are always set to High resolution, and I have never had Enscape fail while exporting one.

    Yes, that's an option we're evaluating for that - however for Panoramas we're already tuning down some of those screen space effects, so one of the downsides of this approach would be that higher resolution renderings that are stitched together wouldn't have the same fidelty as lower resolution ones.

    Hi Herbo

    we're sorry to hear that. We didn't come across issues like that during the Preview phase of the release, but since 2.6.1 has been rolled out we've received multiple reports like yours.

    Since you're using a RTX gpu this might be due to a higher memory demand (and other memory management requirements) by the RTX raytracing implementation, we'll have a closer look at this. Please make sure to submit your log files, so we're able to track down the issue. In the meantime it could also help to minimize any other video memory overhead, e.g. by avoiding multiple CADs (or even Enscape instances) beeing open at once.

    Enscape freezes my computer at 10% Revit model export. My cursor freezes and my computer freezes. CTRL+ALT+DELETE is not even functional. I have an RTX Quaddro 5000 and was very excited for the added support. Anyone else having this issue? I have a BOXX Apexx 7-series, 32 gigs RAM, RTX Quaddro 5000, Core i7-9700K.

    Hi cbonfield

    sorry to hear about that! Did you send us feedback with log files yet? There's a button on the Enscape ribbon for that. Since you're using a RTX graphics card please make sure to run the latest available drivers from Nvidia.


    You can download previous versions from our downloads page (there's a link below that lists all previous releases of Enscape), so can roll-back to a release that worked for you easily. Please also make sure to send log files for us in order to troubleshoot your issue.


    Did you update to 2.6.1? I had no problem w/ exporting at 8k before 2.6.1., updated yesterday, now it's broken. Already filed a support request.

    If you're using a RTX gpu this might be due to a higher memory demand (and other memory management requirements) by the RTX raytracing implementation. But of course we'll give you more dedicated feedback once we've had a look at your log files.

    I would love to find a way to do this where the images line up perfectly edge-to-edge without stitching manually.

    I'm afraid with this approach you're going to see lot's of seams in your image, as Enscape does utilize so called screen space techniques that will lead to different result depending on your current camera window.

    We're generally very much aware of the demand to render in higher resolution than current graphics cards are capable of and will work on this issue for future releases.

    No, this affects all geometry independant of where it originates - the main factors are geometric complexity, size and distance to camera. So large low poly geometry will be visible much longer than small and highly detailed geometry.

    This appears to be working as intended. Trees are rather high poly, so in order to maintain performance they're removed first when the distance to the camera is increased. However please beware that for rendered images and video there's twice the amount of polygons allowed in reflections, so those might yield better results in that case. Also in case of videos reflections are blended to avoid any visible popping of disappearing geometry.

    Hi KMarren

    thank you very much for your report! This is useful information for us that'll help us make future releases more stable. Did you send feedback with your log files already? Are there any specific differences in the files? E.g. does one have lot's of light sources and the other one doesn't?

    This information might already help us narrow down the cause of the issue.

    I think there's some confusion going on what the EXR/high dynamic range export is actually doing. It's not expected to match the output of the standard low dynamic range export options, since it does something different. It stores the "raw" brightness information of your scene without doing a so called "tonemapping" operation, which translates brightness information to low dynamic range colors which you can display on your monitor. If you open an EXR file in Photoshop you have to do some sort of tonemapping first in order to display the image. This usually consists of selecting an exposure and other params like gamma.

    If you're not familiar with the procedure I'd recommend to work with low dynamic range image exports instead and let Enscape handle it.


    High Dynamic Range images are scene-referred. This means that an HDR image stores the values of light as captured by the camera.

    Unlike output-referred jpeg files produced by cameras, HDR images are not pre-processed for the purpose of a pleasant display on monitors. The values of an HDR image remain proportional to light, i.e. they are linear values. So, the gamma for an HDR image would be just 1, which is the same as to say that they do not have a gamma.

    The linearity of HDR images makes them unfit for direct display on standard monitors.


    Via the Nvidia settings,even when you set custom a profile for Enscape, Enscape is still binded to Archicad's GPU.

    This probably related to the core of Enscape.

    What are the chances for this to be resolved. I am sure this step is also leading a multi GPU functionality but for the moment an independent GPU just for Enscape will make workflow better.

    When Enscape is executed by the ArchiCAD plugin it's running in the same process as ArchiCAD. This is currently limiting your options on setting up specific driver profiles etc: Since it's the same process the driver can't distinguish between the two.

    We did some evaluation on if it's feasible to run the Enscape renderer in a different process than the plugin/CAD, however this would have a signficant impact on the export/update performance. So that is probably not going to happen anytime soon.

    In case of a multi-gpu setup there might be other options to actively select a specific gpu for Enscape to run on. This is however something we'd have to look into first, I'm able to give a comment about feasibility.

    Hope that helps!

    The field of view slider does still the same thing as in all previous versions. We removed the focal length notation in MM again for the release 2.6, as it could be highly misleading as this depends on additional parameters like film/sensor size of the camera, which are not explicitly defined in the settings window.

    Most noticeable the preview safe frame and the rendering progress bar. Once again the safe frame which is very important for shot setup immediately renders the image out but when doing so no progress bar shows up so it look like its about to crash

    Which version are you referring to here? There was a known issue in that regard, but that has been resolved soon after the release. Please make sure you're either using the latest stable release or you might also want to try the 2.6.1 Preview version.

    We're sorry to hear that you feel that v2.6 isn't to your liking. Unfortunately based on your description I can't come up with an explanation why this might happen at the moment. Not aware of any changes to how auto-exposure works between 2.5 and 2.6 and neither any material brightness related differences either.

    What certainly did change is the quality of indirect lighting - it's usually much closer to reality now especially in indoor scenes with artificial lighting. This might have an effect on brightness, since indirect lighting is now a lot more precise, e.g. where previously light was able to leak through walls this isn't happening anymore.

    We'll gladly have a look at some before/after screenshots or even the project file if you're able to share that with us!

    So I was running the preview versions for the RTX support but had to revert back to 2.6.0 b/c there were too many bugs and missing settings

    Hi jtubb which Preview versions exactly are you referring to? The current Preview for v2.6.1? If that's the case, can you please elaborate on the bugs or missing settings? That'd be very helpful for us, thanks in advance!