Posts by Clemens Musterle

halshute wrote:

It would be interesting to hear your experience in developing for RTX for those of us who know nothing about how that side of the business works. We just enjoy the pretty pictures...

What challenges are you faced with?

How is it different from the technology you currently implement?

Does the RTX tech provide you with variable levels of raytracing to balance the performance / quality or is it all or nothing? Meaning can you control the amount of time that is raytraced to maintain the real-time aspect of Enscape but also use more time when saving out the image for a final render?

Anything else you want to share?

Display More

TowerPower already gave quite a good overview on the topic in his answer.

Here're some of the details I can share which you've asked:

One of the main challanges up to now was that we've got our existing rendering engine implemented completely based on the graphics API OpenGL. However Nvidia's RTX technology is only available for the recently introduced APIs DirectX12 and Vulkan, which differ greatly in the way they work compared to DirectX11 or OpenGL. To my knowledge we're one of the first/few developers that now have Vulkan RTX working in interoperability with an OpenGL engine.

The main difference is "just" how the ray intersection with your scene geometry is calculated, which is required for lighting calculations in a path tracing algorithm. But since this operation is the most expensive one when it comes to path tracing, ray intersections with hardware acceleration allows quite some speedup compared to previous implementations in software. It's basically the same step as when you still had real-time rasterization of 3d graphics done in software back in the 90s up until gpus were introduced with dedicated hardware for that.

RTX is just a tool to do ray-geometry intersections. What performance or quality get, is completely up to how the developer implements the rendering algorithm. As TowerPower mentioned: We've already implemented a real-time capable path tracing algorithm - RTX won't change that much in the way an image is rendered with Enscape. But it will allow users with RTX hardware to benefit from a significant speed-up of indirect light computations. The result beeing that you'll have better frames per second in a scene with the same geometric complexity, or get similar performance you currently have, but in much larger or more detailed scenes.

So it's unlikely that the feature set of Enscape will differ much (if at all) for users with RTX to non-RTX users - you'll definitely still be able to render the same image quality with very competetive speed using Enscape without RTX hardware in the future.

Hi PaulM and welcome to our forums!

Those shadowing issues (the diagonal lines on the first screenshot are also false shadows) are unfortunately a known issue of our initial Enscape 2.4 release. We've in the meantime improved sun shadow calculation to reduce artifacts like that. Could you please to download the latest version of Enscape from our download page and see if the issue persists? There's a link the Enscape About window ("Visit download area") that will lead you there.

You might also get improvements of the visual quality if you increase the field of view to higher values if that is possible for you. Looking at your screenshots you're using an almost orthographic perspective.

Hope that helps!

RTX support is currently in active, but still early development. Which we means we can't announce a specific release date yet, but RTX raytracing support will come this year. So if you're considering buying new hardware to use with Enscape it always makes sense to go with the latest generation to get the best performance.

Looking great! Especially good work on the materials & lighting!

Pieter wrote:

However, I must admit I'm confused here. In post #4 in this thread Thomas acknowledged there was a bug with specular 0 and it would be fixed.

That's a post from April this year. This has been fixed long ago

Pieter wrote:

I can send you the files when I get back at the office in January.

Thx, appreciate your help!

Maybe it'd help if you post a screenshot of your material setup and the result in Enscape. I'm quite confident that you can achieve a similar result with the right settings in combination with a bump/normalmap for the gaps.

Gadget wrote:

This does work, but unfortunately doing it this way you have no control over the repeat of the mask texture or where it starts/stops. (And 99% of the time the mask comes in at a tiny scale)

You can gain a little bit of control by using a texture fill*: both the Albedo and Mask should line up if you create the mask from the Albedo, then change it from the mask tab in the properties. If you add the mask first, the origin of the Albedo needs to be central to the surface (I think).

It also screws up positioning and scale of the textures/masks within Enscape if you scale/stretch the underlying geometry.

This is a Sketchup specific issue, as Sketchup doesn't provide us with the right UV coordinates/scale if there's no texture defined in the underlying Sketchup material.

We're in the Revit subsection of the forums here!

Hi jradle & welcome to our forums!

An effect like this can be achieved by using a gradient texture in the transparency slot. Set a white base color and a transparency amount somewhere around 50%.

Hope that helps!

joeykeys wrote:

That looks like self-shadowing issue. Might be related to scene scale?

Correct observation. Self-shadowing (or "shadow-acne") artifacts appear sometimes depending on the angle between the sun and the surface orientation of your geometry. Often these issues are more visible in especially large projects. We're aware of these issues and are currently working on some improvements.

Enscape certainly does work with jpg textures. This looks like a texture scaling issue on the first screenshot, shouldn't be related to the file format. If you can reproduce the issue please provide our support with a project file so we can have a look at it. Thanks!

Solo wrote:

I figured out that when two transparent materials overlap they cause problems, is there a fix?

We've seen similar artifacts with some Nvidia drivers, but to our knowledge these issues have been resolved with the 2.4 release. Could you please send feedback with your log files? You could also try to installer another driver version in the meantime and see if that helps.

Patty - Ridley wrote:

Hi All,

I am needed to do a Chrome (Silver) tinted glass facade, so I need it to be Silver reflective but also semi transparent.

Has anyone been able to successfully get it looking ok in Enscape.

An an example, this is what I need to do. I have tried the Chrome metal material but from what I can see there is no way to make it transparent when rendered in Enscape.

Any help would be great

Thanks

Justin.

Display More

Have you tried starting with a Revit glass material and dialing up the reflectivity to maximum?

DanielCarpio wrote:

We have the HTC Vive Pro and the Vive Wireless adaptor.

We have the same issue with the image in the headset getting blurry/pixelated for a moment then it fixes itself. This happens constantly as you look around. Something has definitely changed in the last few versions of Enscape as even with the latest graphics drivers and the latest version of Enscape, the VR performance is much lower than we are use to seeing.

Thanks for your report! We actually didn't change much of the VR implementation between Enscape 2.3 and 2.4. Though performance could be slightly lower with lot's of grass on screen, we're working on improving that.

Apart from that I think we should distinguish between performance issues and your reports of having blurry/pixelated images. As I haven't experienced anything similar with the VivePro yet and you're both using the wireless adaptor, I'm wondering if this might rather be a hardware issue. Did you try if you're having the same issues running the Vive wired?

Hi mikewood

what quality settings is Enscape running on in VR? The Vive Pro's resolution is quite high. Depening on the scene complexity (e.g. lot's of light sources or trees like on your screenshot) it may very well be the case, that you're not able to get fluent performance on quality level High or Ultra. Please try running Enscape on Medium or Draft quality while using the Vive Pro and see if that helps to keep the framerates more stable.

However I'm not sure what you're referring to here:

mikewood wrote:

graphics glitch and drop to a lower resolution for a frame or so

In VR the resolution should be constant in Enscape. There's no automatic resolution reduction enabled in VR.

Hope that helps!

Hi beardface00

thanks for your report! In fact this is a known issue which we haved fixed in the meantime. Please download and install the latest version of Enscape (v2.4.1) and try again. The missing texture should then no longer be a problem.

Please let us know if you need any further assistance!

Hi Ryley-G & welcome to our forums!

What you're showing here is more of a lighting problem and has nothing to do with the material beeing two-sided or not. Unfortunately correct shading of a semi-transparent material like this turns out to be quite difficult to do well in real-time. That's why Enscape uses several optimizations, including a rough estimation of the atmosphere occlusion of semi-transparent objects. In this case the occlusion calculation results in the inwards facing side of the window beeing mainly occluded from the atmosphere and is therefore rendered darker, which makes it appear more transparent.

You might want to try to use a solid glass material instead if this matches your purpose, as the shading will be more consistent.

Thanks for your report. This does look quite off indeed and not like "regular" shadow mapping leaks due to so called 'Peter Panning' issue. Could you please send our support a mail with the project if possible? Thanks in advance!

Hi tonyisenhoff

thanks a lot for your report! In fact we've had a small number of other users report the same issue and are currently working on a solution. We plan to include it in an upcoming hotfix for Enscape v2.4.

Hi dakeret

that's an interesting challenge! Looking at your screenshot and the reference, the first thing that I noticed was that you're actually comparing two very different lighting scenarios. Most importantly on the reference all the shades are closed and the sun doesn't shine through the windows. It also appears to be dusk? Or at least a more overcast atmosphere lighting.

So what does that affect your rendering? Well the more light (direct & indirect light from the sun and the atmosphere) is received the more your auto exposure will tune down the exposure in order to avoid overexposed regions in your image. Direct sun light is always oders of magnitude brighter than any artificial light source - that's why the impact of an artificial light source is visually lost when the exposure adopts to the brightness of the sunlight in your image.

Things you could try to reproduce the lighting atmosphere of your reference:

- Change to time of day to something like dusk/dawn, when there's no direct sun light coming through the windows

- Model the shades to occlude atmosphere & sun light

Btw On which quality setting are you rendering? You might want to try Ultra if your hardware can handle it, as it allows more bounces of indirect light to be calculated!

Hope that helps

Hi nwergin & welcome to our forums!

The lighting calculation of the Web Standalone is simplified a lot (equaling the regular "Draft" quality) in order to be able to run in web browsers at reasonable speed. You can see that already on your screenshot: The Web Standalone does currently not render with correct indirect lighting, which gives the screenshot of the Exe Standalone that warm color (bounce light from the floor and walls). Instead it assumes a uniform distribution of indirect light, coming mainly from the atmosphere, hence the blueish tint during daytime. Atmosphere light during daytime is however usually much brighter than any indirect light coming from light fixtures in an otherwise closed room, which is why in relation to the surrounding the emissive surfaces appear much darker in the Web Standalone. If you'd select a fixed exposure the emissive surfaces would be equally bright, however the rest of the image would be way too bright in case of the Web Standalone (or too dark in case of the Exe Standalone).

To conclude: I'd suggest to simply make the emissive surfaces brighter in that case before exporting the Web Standalone to improve visibility during daytime.

Hope that helps