Path Tracing = built-in ray tracer!

[andyz]

Just want to say that the non-realtime Path tracing is a fantastic start towards a built-in V-Ray for Unity!!
It falls short in some areas - images are rather soft and metals…? (also glass seems tricky) But the reflection and GI is fantastic and matches a high-end ray tracer.

I hope this will become a high-end ray trace solution for architecture/interior design etc.

[Yanus3D]

…is going there! to be one of the best Architecture visualization solution.

[fuzzy3d]

I fully agree, path-tracing can also be extremely effective for technical visualizations and industrial design. I hope a real-time denoiser will be added in the final version.

[Yanus3D]

some extreme closeups from my test scene. Renders done on Ampere 3090 (10-20 fps)

[fuzzy3d]

Hi, does anyone know how to use a script to reset the accumulation of path-tracing to 0 after changing the material of an object?

[chap-unity]

AFAIK, there’s no API to do that currently because the functions are internal to HDRP.
However, I think it makes sense to add it because the path tracer does not reset accumulation exactly when you would want it to sometimes.

[fuzzy3d]

I am very satisfied with the quality of the path-tracing. Together with materials from Adobe Substance, we could create a nice product for the customer.
Today, however, I encountered limitations when trying to create a high-resolution snapshot using ScreenCapture.CaptureScreenshot with a superSize parameter greater than 1. But I understand that such use is not entirely common … and Ansel is not working on DirectX 12.

[chap-unity]

@fuzzy3d , I managed to repro your issue with the CaptureScreenshot function, Path Tracer does not uses accumulation if you have a superSize parameter > 1 (like having only one sample per pixel)
Won’t guarantee that it will be a super huge priority and if it will get fixed at all, but I logged (give it a few hours) it in case it’s very simple to support this superSize option with the pathtracer.

[fuzzy3d]

Thanks for the comment, I have the impression that using SuperSize will probably not be possible due to path-tracing naturel.

[chap-unity]

Your impression was right, when capturing an image with the supersize argument > 1, the camera is changed right before capture, then restored. Therefore, it is normal that the path tracer would reset the accumulation, as it does not and should not reuse previous information if any camera attribute has changed.

Since, there’s a simple workaround for this, (just switch the desired resolution in the game view and capture with a superSize of 1), no special case will be made to support this in the path tracer !

[fuzzy3d]

It seems that in 2021.1.0b4 the .obj file import (from ICEM Surf) stopped working - when path-tracing is enabled, the imported objects are black regardless of what material / shader I assign to them. I have to test …

Edit: Yes, latest beta and alpha stopped supporting .obj import from ICEM Surf with path-tracing enabled. Objects are completely black in any material. So that means the end …

[chap-unity]

Are you able to share one of those obj file to see if we can do something about it ?

[chap-unity]

Hey, so I took a quick look between versions and I confirm it works properly in 2019.4, 2020.1 but starts to “break” (object is black) after that with the pathtracer.
The reason why, is before that pathtracer used to ignore completely the imported geometric normal and only used shading normal (calculated per vertex and interpolated). But this caused some issues and after a while, the geometric normal has been re-integrated (after 2020.1) and is taken into account now.

In your example, your geometric object normal seems to be flipped. So before 2020.2, result was fine. But now, imported normals are flipped compared to shading normal and this causes the issue.
To avoid getting a black object you have multiple options :

• Set the imported normal (geometric) in your mesh importer to “calculate” to avoid using the “incorrect” geometric normal

• Set your material to double sided in “Flip” or “Mirror” mode

• Flip the normal in your 3D modeling software before exporting your file

[fuzzy3d]

@chap-unity

To avoid getting a black object you have multiple options :

Thank you so much for analysis of the problem and suggested solutions! I will perform tests…

Edit: Since this is a runtime import, “on the fly”, I tried to use the function Unity - Scripting API: Mesh.RecalculateNormals (unity3d.com) and it works great! Thanks for the information and advice!

[Yanus3D]

fuzzy3d I wanted to answer how to deal with those black surface but I was very busy lately.
For me this is standard error in Unity (not common) when I get black surface. This is due import procedures in Unity.
I use Lightwave Importer plugin and sometimes it happen when I get black surface. Of course in Lightwave everything is ok…but I noticed that Unity is horrible “sensitive” for all kinds of mismatch between polygons.
The best solution for me is to cut in half this polygon or triangulate. Remember I use LW Importer - it means I operate mostly on quads.
I have one tool in LW: “Unify Polygons” which flips all wrong polygon vertexes to one vertex direction (for example outside) also I have another plugin LWCAD which has too for fixing error.
With those above no chance to get errors in Unity!

[fuzzy3d]

Thanks Janusz, the problem we have is a bit specific - we want to create a viewer of specific data for a specific (and small) group of people who do not have such experience as standard 3D artist - it must be automatic and without additional modifications from user side to the data they are working on (flipped normals, unoptimized mesh). Simple tool with huge graphic impact.
But thanks to the information from chap-unity, I now know what to focus on and how to edit the data imported “on the fly”.