Posts by Clemens Musterle

    After testing, version 2.8 with RTX on has more realistic shadows and reflections, but the rendering speed is much lower. Maybe this version is not fully optimized?

    Which resolution were you rendering the images at? When you run out of gpu memory rendering does become a lot slower, since we have to swap resources to the main memory. This has nothing to do with RTX technology in particular though. As a general rule of thumb a gpu with 6-8GB of memory is usually able to do a 4k rendering without swapping, anything above is going to be much slower.

    Was animated vegetation added to this preview? Or is that coming in a later release? Saw it on the development agenda.

    This will come in a later Preview release. It's currently work in progress as far as the engine implementation goes, but it also requires setting up all the assets for it as well, which will probably take a while.

    Sorry it's difficult for me to say exactly what's going on here based on the screenshot. However some notes on reflections in general:

    - For Sketchup in particular we can only take the front face material into account

    - There's limited resolution for textures visible in reflections (therefore delicate detail like the cutout texture here might get lost)

    - Especially high detailed geometry might not always be visible in reflections, please see explanation here: Why are some of my objects/parts of my project not displayed in reflections?

    - So all in all: please consider Enscape is still a real-time renderer, therefore you can't expect reflection quality to be on a level with offline path tracers :)

    Hi Ray G and welcome to our forums!


    Based on the right screenshot it doesn't look like it's beeing rendered as a point light to me. However area lights do have a size limit (3 meter) in Enscape. If you want larger area lights you'd either have to combine them from multiple light sources or as v-cube suggested use an emissive material instead. However you won't get as crisp illumination from an emissive material as you get from a light source.


    Hope that helps! :)

    Hi Jeanvo90 & welcome to our forums!


    Thanks for your report. We've had similar ones from two other customers before, that had a very similar problem after upgrading to 2.7. We've since then identified the source of the issue based on their provided project files and will ship a fix in the upcoming 2.7.1 version, which should be released next week.


    To make sure that we've got your case covered as well you're welcome to submit your project file to our support (please contact Demian Gutberlet in a direct message to discuss details).


    In the meantime you might want to try and see if it helps to reduce the brightness of your light sources.


    Hope that helps! :)

    +1 for normal and/or displacement map support.

    In the meantime, I saw some talk earlier in the thread of adding a "_n" suffix.
    Does this work in sketchup? in Rhino? And where is that suffix containing normal map added, to the bump slot?


    thx!

    the _n suffix is basically a legacy feature, which was required back when we didn't have our own material editor and no automatic normal map detection. So as long as you're working with a plugin with a dedicated Enscape material editor this is no longer relevant and will be ignored (so this applies only for legacy Revit versions that didn't support normalmaps at all).

    Hi AhmedAkader


    how did you create those images? Did you render them via the Render Image button on the Enscape toolbar, or did you take a screen capture of the Render window? To a certain extend such noise in specular reflections, especially on rougher materials are a known issue, however it should usually converge a lot better, when rendering a still image via Enscape's render image functionality in comparison to the real-time walkthrough.

    I guess I can shed some light on this issue:


    First of all, what you're comparing here isn't entirely the same, as the normalmap contains much more noisy detail compared to the height map. However that's not a shortcoming of the normal mapping technique, but rather depends on how the normal map was generated. In this case I suppose it was created simply based on the albedo map, which sometimes works out, but often results in quite noisy shading.


    However what's actually wrong with this normalmap in particular is, that it doesn't match the normalmap standard Enscape uses and therefore the shading is off, please compare the images below between heightmap and normalmap and see the shadow above for reference:


    This is just a convention thing and in this case can easily be fixed by inverting the green channel of the normalmap. This will then result in correct shading, that aligns with the geometric shadows (but of course will not fix the noisy micro detail in it):



    Please beware of that, when using precalculated normal maps and check if the shading actually matches the light position/shadow direction. Enscape uses the OpenGL normalmap convention. Here's some explanation on that.

    Hope that helps :)

    Transparent materials can't be handled neither in a material or objectid nor a depth output, since they'd cover the geometry behind it. You also can't properly postprocess them anyway with a single layer material or objectId, since you'd modify the geometry/materials behind it with it.


    Having layers of object/materialId has been requested but is not really viable, as there could be arbitrary layers of transparencies.

    Thanks Clemens. Do you think it would be possible to get close using other map channels, ie. roughness and reflectivity?

    Not exactly sure I understand the question correctly. Do you mean, if you can already achieve that effect by using multichannel textures for roughness and reflectivity?

    In that case that'd be a no. Right now we only have a roughness map in our material model (alongside Albedo, Mask and Normal/Bumpmap of course). If you have a non greyscale texture in the roughness slot we're simply converting it to greyscale, so in worst case adding metallicness in there would distort the roughness map (as conversion of rgb to greyscale is luminance across all channels).


    If the question was if it's technically feasible to have roughness, metallicness (and or reflectivity) in a single texture map. That'd be a yes, however we'd have to see how that would map to the existing material editor's capabilities, especially for Revit as there's no Enscape specific material editor for that.

    Hi medmonds


    right now this is not possible, as our materials only allow for a single metallicness value per material. However we'll evaluate metallicness textures for future versions - usually it's not a common requirement for materals in an architecture context in my experience (you'd usually just model the different components separately and apply different materials to them), however it certainly does allow more flexibility, which also our own assets could benefit from ;)

    Hi Petar Karuza


    that's actually not a prompt. I guess that you've set a custom image overlay in your settings? We've had another report that said, you have to reselect the image file in the settings to make it work correctly after the update: Enscape 2.7 Invalid Texture

    It might be that the file path stored in the settings is somehow invalidated after the update.

    First and foremost, I can't get my Revit decals to show up in Enscape 2.7. The decals appeared in older versions of Enscape, but after updating they have disappeared.

    Hi Nctorstenson & welcome to our forums!


    Sorry to hear that you're experiencing issues with the new release! Decals should definitely work with 2.7 as before. Could you please contact our support via the send Feedback button, so we can figure out what's going on at your end?


    I could reproduce some issues with the batch rendering while beeing in 'Walkmode', this looks like a bug, so we'll investigate that. I would suggest to simply workaround this by disabling walkmode before starting a batch rendering. The camera positions should then exactly match the position from where you saved the view.


    Please let us know if this doesn't solve your issues!