I've also sent you my SKP in a PM, maybe a nice test case for the upcoming version
Appreciate it! We use a similar setup using our Release 3.2 model which has an outdoor "amphitheater".
[Blocked Image: https://aecmag.com/wp-content/uploads/2021/12/Night_Pavilion-750x422.jpg]
Hello! This issue seems to stem from our Global Illumination solution which is at odds with the sun (kidding). We have several advancements for version 3.5 which will 99% solve this problem.
Hello everyone. I am happy to share that this issue has been fixed internally, so it should be out in one of our next versions!
Hello everyone. There is a high possibility for the fix to be included in the next preview version. Keep in mind, though, that the preview might have other problems introduced due to new features.
Hello everyone! I have looked at the project and I confirm that there is a problem on our side. Inspecting the height texture, Windows Explorer properties say that the bit depth is 16 and we have a problem detecting that for monochrome images. I have created a ticket for it internally.
I believe that If you can change a setting in Substance to export the height maps in 8 bit depth, it will work around the problem for now.
I'm curious, do you mean the overall vertex count of the model or do you mean the vertex count of the objects being reflected?
Both can work towards the same end goal. One could have a normal-poly count bed but if they have some very high poly wall decoration or chairs, it could mean that the bed is not included because the others got in our ray tracing structures first, leaving no room for it.
In 3.4 we added a way to provide higher priority to objects that are visible (both on screen and in mirrors) to improve this situation (not available for video renderings yet). We also increased our geometry limit because we found ways to process the geometry faster.
Hello again,
If you increase your VRAM, this will lower your chances of getting crashes when you use very big models. This means that going to a 10GB VRAM system will surely increase the chances for better reflections but going from a 10GB to 12GB or 24GB will not for now.
When RTX (hardware ray tracing) is not enabled, we have another method for ray tracing but it is very limited and doesn't provide the same quality as GPUs with hardware ray tracing supported (both NVIDIA and AMD).
What I want to stress again is to inspect your models and try to lower the vertex count as much as possible. Enscape is designed with real-time performance in mind, so we provide the best results if the assets are as lightweight as possible.
Hello there and don't mind me chiming in on this.
Everything that is only visible through a reflection (and not directly on screen) is handled with ray-tracing. For objects that are already on the screen, we have other techniques to include them in reflections. For every object that is processed with ray-tracing, we have a geometry budget that we try to fit it into; if the budget is filled, then the objects that will be seen in the reflections will not be everything that is expected. That's why its important to simplify your models in terms of vertices as much as possible.
Since you show an outdoor scene, I assume that there is a lot of geometry in the surrounding area and in the buildings. A workaround for your case would be to remove any geometry that isn't in the viewport and shouldn't be visible in the reflections. Only keep the objects that you know will be visible.
We are discussing ways of providing the option to users who have very large VRAM to increase that geometry budget. But there is no guarantee of when (or if) that will be implemented yet.
