Closed shocker-0x15 closed 1 year ago
Thanks for reporting this and chasing down the root cause; sorry for not getting a fix in sooner!
I ended up going with a slightly different approach, getting the world<-->instance transformations and then transforming wo
into the actual instance coordinate system. This has the benefit of not increasing the size of the payload, which should benefit performance, though I haven't benchmarked the two approaches.
The same bug was present with instanced bilinear patches, so I fixed that case as well.
Hello,
I noticed an image difference when rendering quadric surfaces between CPU and GPU. I'll attach the scene and command line options at the end of this message.
Look the following two images:
Here, there is a single cylinder illuminated by a distant light, rendered by CPU (1st) or GPU (2nd)
GPU one looks obviously weird.
The point is that rotation (along cylinder's axis, so essentially no effect) applied to the cylinder (look the scene description below).
If I comment out the rotation, I get the correct image:
![image](https://github.com/mmp/pbrt-v4/assets/4602478/0bd81a0f-ad14-4fa8-a86d-cd3365955681)
I read the code and it looks that OptiX code for quadric surfaces is weird. Specifically, ray direction passed to an intersection routine for a quadric surface is in local coordinate system in CPU code: https://github.com/mmp/pbrt-v4/blob/05ff05e1ded8299b1de0eb8ee6c11f192d0a64dd/src/pbrt/cpu/primitive.cpp#L115 but it looks to be in the world (render) space in GPU code: https://github.com/mmp/pbrt-v4/blob/05ff05e1ded8299b1de0eb8ee6c11f192d0a64dd/src/pbrt/gpu/optix.cu#L305
I could fix this particular issue by using object-space ray direction instead like the following:
but I'm not sure if this is the complete/ideal fix. And possibly other non-triangle codes are also wrong (I didn't check though).
Thanks,
The scene I used
The command line options I used:
[--gpu] --spp 64 test-v4.pbrt