Help needed debugging black image after API update

paulmelis commented 4 years ago

ospTutorialBoxes works for me and it uses the pathtracer renderer, so I assume that's working correctly for basic scenes in the current checkout of the repo I'm using (9527f27984f6ba7daeb3d64df7c0d4615866ddab). I'm building it with the superbuild.

However, after updating my code to match the API changes of the past two weeks or so I end up with a rendering that shows only black (the framebuffer is transparent outside of the cube, but that's not visible in the way the image is displayed here). Rendering the exact same scene with the scivis renderer shows the correct image. So I'm figuring the issue is with either materials or lights, or maybe some pathtracer-specific parameters.

buggy

Geometry, instances and transforms appear to be set correctly, judging by the object silhouette being where it should be. I was already using the new scene hierarchy for some time and did not make changes there recently.

Updates due to the recent API changes I did:

Lights are now set on the OSP_WORLD object, instead of on the renderer
Using ospSetObject instead of ospSetData. Mostly using ospSetParam, but also still some of the earlier forms like ospSetVec3f.
Use the four-argument form of ospNewData (0 flag) to keep the old behaviour and not have to think about managing lifetimes of data arrays yet
Using new parameter names where needed.

Other checks I did:

I see no obvious warnings/errors with --osp:debug ( log.gz )
ospCommits are done where needed as far as I can tell
Materials are created based on the actual renderer type
I use an OSP_FB_RGBA32F framebuffer, where the examples use OSP_FB_SRGBA. But temporarily using OSP_FB_SRGBA and saving to a PNG file shows no difference, still black.

I have a small faker library that I LD_PRELOAD that dumps the API calls and their arguments. This has helped me track down issues earlier, like missing ospCommits, lost references, etc. Again, I don't see much that I'm doing differently than the boxes example. I have tried different scenes, with different materials, different lights, etc. They all show the same behaviour: black surfaces.

Unfortunately I can't use git bisect in this case. Any tips on how to get further in debugging this issue?

paulmelis commented 4 years ago

Well, one step further. Using a scene based on ospTestingNewGeometry("boxes", ...) gets me this with the path tracer:

boxes

So perhaps I'm doing something wrong setting up my own geometry w.r.t. materials.

paulmelis commented 4 years ago

Not sure this is related, but I frequently see a segfault somewhere deep in the path sampling when using the pathtracer. So far I think I've only seen this happing for triangle geometry, which is also where I have the above issues.

Partial stack trace:

Thread 6 "ospTutorial-pt" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffea70b700 (LWP 5476)]
0x00007ffff722b6d6 in samplePath___REFs_5B__c_vyPathContext_5D_REFs_5B_vyPathState_5D_REFs_5B_vyRay_5D_REFs_5B_vyScreenSample_5D_avx2 (pathContext=..., pathState=..., ray=..., sample=...) at PathSampler.ispc:195
195       pathVertex.albedo = pathVertex.bsdf->albedo;
(gdb) bt
#0  0x00007ffff722b6d6 in samplePath___REFs_5B__c_vyPathContext_5D_REFs_5B_vyPathState_5D_REFs_5B_vyRay_5D_REFs_5B_vyScreenSample_5D_avx2 (pathContext=..., pathState=..., ray=..., sample=...) at PathSampler.ispc:195
#1  0x00007ffff71fe506 in PathTraceIntegrator_Li___un_3C_s_5B__c_unPathTracer_5D__3E_un_3C_s_5B__c_unWorld_5D__3E_un_3C_s_5B_unFrameBuffer_5D__3E_CvyuCvyuREFs_5B__c_vyvec2f_5D_REFs_5B_vyRay_5D_un_3C_s_5B_vyLDSampler_5D__3E_un_3C_s_5B_vyRandomSampler_5D__3E_avx2 (self=<optimized out>, world=<optimized out>, fb=<optimized out>, ix=..., iy=..., pixel=..., ray=..., ldSampler=0x7fffea6dcbc0, randomSampler=0x7fffea6dc7c0) at PathTracer.ispc:86
#2  0x00007ffff72004d3 in PathTracer_renderPixel___un_3C_s_5B_unPathTracer_5D__3E_un_3C_s_5B_unFrameBuffer_5D__3E_un_3C_s_5B_unCamera_5D__3E_un_3C_s_5B_unWorld_5D__3E_CvyuCvyuCvyuavx2 (self=<optimized out>, 
    fb=<optimized out>, camera=<optimized out>, world=<optimized out>, ix=..., iy=..., accumID=...) at PathTracer.ispc:135
#3  PathTracer_renderTileJob___un_3C_s_5B_unPathTracer_5D__3E_un_3C_s_5B_unFrameBuffer_5D__3E_un_3C_s_5B_unCamera_5D__3E_un_3C_s_5B_unWorld_5D__3E_REFs_5B_unTile_5D_uniavx2 (self=<optimized out>, fb=<optimized out>, 
    camera=<optimized out>, world=<optimized out>, tile=..., taskIndex=<optimized out>) at PathTracer.ispc:174
#4  0x00007ffff7161e84 in Renderer_renderTile () from /home/paulm/software/ospray-superbuild-git/lib64/libospray_module_ispc.so
#5  0x00007ffff7027000 in ospray::Renderer::renderTile (this=0x5555555871e0, fb=0x55555558b180, camera=0x555555583a30, world=0x5555555863b0, perFrameData=0x0, tile=..., jobID=0)
    at /home/paulm/c/ospray-git/ospray/render/Renderer.cpp:83

The above is based on a simple reproduction using the ospTutorial.c example:

--- ospTutorial.c   2019-10-01 09:13:38.528932292 +0200
+++ ospTutorial-pt.c    2019-10-02 12:09:12.262017853 +0200
@@ -169,7 +169,7 @@

   // create renderer
   OSPRenderer renderer =
-      ospNewRenderer("scivis"); // choose Scientific Visualization renderer
+      ospNewRenderer("pathtracer");

   // complete setup of renderer
   ospSetInt(renderer, "aoSamples", 1);

Twinklebear commented 4 years ago

Hey @paulmelis , are you setting a material on the boxes when you set it up in your code? The segfault you get:

Switching to Thread 0x7fffea70b700 (LWP 5476)]
0x00007ffff722b6d6 in samplePath___REFs_5B__c_vyPathContext_5D_REFs_5B_vyPathState_5D_REFs_5B_vyRay_5D_REFs_5B_vyScreenSample_5D_avx2 (pathContext=..., pathState=..., ray=..., sample=...) at PathSampler.ispc:195
195       pathVertex.albedo = pathVertex.bsdf->albedo;

Is likely due to trying to not having a material on the geometry, since the path tracer right now assumes every object will have a material. (e.g., the testing boxes do make a material https://github.com/ospray/ospray/blob/release-2.0.x/apps/ospray_testing/geometry/Boxes.cpp#L84-L89)

paulmelis commented 4 years ago

the testing boxes do make a material

https://github.com/ospray/ospray/blob/9527f27984f6ba7daeb3d64df7c0d4615866ddab/apps/ospray_testing/geometry/Boxes.cpp#L84-L89

Thanks, I now see my error: I was using ospSetObject to set the material instead of ospSetObjectAsData. But in my defence the readme was showing the wrong example:

https://github.com/ospray/ospray/blob/9527f27984f6ba7daeb3d64df7c0d4615866ddab/README.md#L2570-L2575

(and also having the material array named a singular material was also not helping to do the right thing instinctively. I know, different discussion).

By the way, I find the new APIs to set parameters/data/objects a bit non-intuitive. Especially ospSetObjectAsData is a mind-bender given the way ospSetData was used in v1. Maybe renaming it to ospSetObjectAsDataArray is less confusing, as there is no such thing as setting something as data in the new API. Everything is set as an object, right?

Anyways, thanks for helping me out with the quick reply! I'll close this now.

jeffamstutz commented 4 years ago

We are looking at potentially allowing the path tracer to have some sensible default appearance if a material was not provided (as opposed to a crash).

RenderKit / ospray

Help needed debugging black image after API update #364