LuxCore
LuxCore copied to clipboard
LuxCoreRender
Behaviour of matte translucent material depends on volume assignment
I've encountered a scene that renders black on GPU with Optix enabled, though LuxCore seems to perform computations. The scene is a series of lenses imaging an object onto a matte-translucent "detector". With just CUDA it works. (v 2.4 works also, as it doesn't feature optix.)
latest BlendLuxCore v2.5 Blender 2.83.3. LTS Windows 10 i5-9600K + RTX2070
Also, toggling viewport-render on and off frequently crashes Blender
I can't test it in standalone because of Lexical Cast issue with export.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
ok right after posting this I noticed another detail, so here's an update.
part of the issue was with my "detector" setup. I was looking at matte-translucent from behind. This just seems to fully fail as a concept with GPU, also in 2.4 (and I remember seeing similar in the past). For CPU, it works as long the matte-translucent has a finite thickness, i.e. a plane also doesn't work for CPU.
Instead, using a matte plane as detector and observing from the front gives identical results.
So maybe the title should rather be "GPU issue with Matte-translucent" instead?
Also there are large performance + output differences between CUDA and OptiX, similar report by someone else on Discord. I'll try to quantify that.
EDIT: Here's a comparison between CPU, CUDA and OPTIX (GPU+CPU, I forgot to deactivate), plus when observing the "detector" with perspective and Ortho cam. CUDA has half the rays/S as CPU and OptiX. Also notice the ring artefacts for Perspective CPU + CUDA, but not OptiX.
Sorry for spamming this (last one really, I will be away from this PC for 2 weeks ;) )
I realised I was still being an idiot, there were two overlapping detectors with one only disabled for Blender preview, but not final render...
Updated comparison (scene attached) shows that the rings are now gone and CUDA matches OptiX closely.
Anyways, I found the updated comparison worthy of a new post rather than an edit to my previous because it shows that OptiX with HW-RTX can behave quite differently with respect to z-fighting.
The issue with matte-translucency remains.
I downloaded your last test scene and I'm getting same output out of CPU and GPU rendering, what is the problem ?
ok sorry that ended up unclear.
The last test scene is how I generated the comparison image (should be the same for the second post)
For the remaining issue use the file form the first post. There is no overlap there, just the matte translucent object as detector, which has a finite thickness.
- CPU seems to work correctly
- CUDA basically ignores the detector
- OptiX is just black
If I use a plane with matte translucent (no thickness), CPU also ignores it.
The scale of the scene looks very strange, the thickness of the detector is 0.001m, the lens are about 2 meters apart while the Suzanne is about 50km (!!!) apart. The ratio between the thickness of the detector and distance of the Suzanne is about 0.00000002 ... you so out of the precision of FP32 numbers that I'm surprised you get any meaningful out of CPU rendering.
I doubt even FP64 can handle this kind of setup.
The distance is chosen because I'm using a real-life lens design that is focused at infinity. So the object needs to be far.
My thought right now: I'm using only path-tracing. So the ray starts at the camera and remains in the near space right until it leaves the fifth lens, very near the coordinate origin. From there the next ray has to find Suzanne by intersection of o + t*d with a (huge) triangle. Now even if the "o +" is capped by FP32, it should make little difference to the result because it will just be a tiny shift of the intersection point on the huge Suzanne.
And as you can see from post 3: with a matte surface instead of matte-translucent it works in all cases.
So: The problematic part appears to me to be the matte-translucent material.
The problem is the thickness of the detector, you are likely to end with many inconsistent cases:
-
the nearest intersection will be the entering point of the detector but the existing point will not detected because it will be too near to the entering point.
-
the nearest intersection will be the exiting point of the detectors. The entering point is not detected at all (it can have ray t greater than the existing point due to numerical precision).
This inconsistent cases will do a huge mess with all volume related computations (i.e. it is mandatory to detect any transition between different volumes).
I have played around with the matte translucent a bit.
What I found is that it only interacts with a ray if the ray comes from the forward side of face (where the face normal points).
So a solid object like a cube with matte translucent material, and illuminated only from one side - e.g. by a laser - behaves exactly the same as if there was only the front face present.
The following image shows this situation:
- Top left: Plane with normal facing the source
- Top right: Plane with normal facing away from source
- Bottom left: Cube with normals pointing out
- Bottom rigth: Cube with notmals pointing inside
P.S.: Rendered with BiDir because no matter what I do, the rescattered volumetric light doesn't show with path/light tracing.
P.S. 2: The blend file attached might only work with v 2.4 because of utf-8 reasons. I tested behavior in 2.4 and 2.5 but saw no difference so far.
What I found is that it only interacts with a ray if the ray comes from the forward side of face (where the face normal points).
This is the correct behavior otherwise you would have the ray diffusely scattered when you enter an object and when you exit too.
Ok, quick comment ahead cause I just noticed a new symptom: From a real world material I would expect it to scatter at entry and exit. I'm thinking like a leight-weight alternative to rough glass.
I just tested something and it seems to be related to volumes. Without any volumes created ina fresh scene, it seems to work as I would expect (two sided). With volumes (even only a world volume added, nothing assigned to anything; but also with volumes assigned to the cube) the behaviour becomes weird, and also different for viewport and final render. I have to leave it for today, maybe I can test again tomorrow as I couldn't get to any systematic description now.
Ok here is it a bit more systematic. Image below, blend-files attached
Basic scene setup: Default Blender Cube scene, switch to Lux, delete all lights, create laser light, set matte-transparent material on cube. Create second rear-view camera opposite the default camera.
Row 1: Render like this (Cube Face Normals point outside) Row 2: Cube normals pointing inward.
Row 3 + 4: Same as above but with a World volume created (only hit "New" button in Scene Tab)
Row 5: Additionally a clear volume defined for the cube, and inside and outside volumes explicitely linked in Cube Material. Normals pointing outside. Row 6: Normals pointing inside. Flipped inside/outside volume assignments on cube to match.
Results:
- Without any volumes it behaves as I would expect.
- With only a world volume present the one-sided behavior starts to show. The direct beam can be seen on both sides
- With the cube having volumes assinged, the laser is scattered on both ends. Note also how the diffuse sides are brighter than in rows 1+2.
