Uniform ray sampling

[Marcus399]

Hello,

I am trying to implement a custom distributed render using OSPRay, but have run into a slight problem. I want to be able to distribute parts of my volume to different compute nodes and then compose the images. However, I am getting artifacts around the subvolume boundaries. Compositing and volume boundaries are correct, so I assume that the problem is due to inconsistent sampling (i.e., the location of the samples are based on the volume bounds). I had a look at the paper about visit's implementation of OSPRay [1] and noticed that they implemented a custom volume type (called visit_shared_structured_volume) to solve this problem, suggesting that there is no option in OSPRay to achieve uniform sampling across volumes. Is this correct?

Regards, Marcus

ps. I know that OSPRay has a distributed mode, but it is not sufficient for my purpose.

[1]. http://sci.utah.edu/~will/papers/visit-ospray-egpgv18.pdf

[wilsonCernWq]

Hi Marcus

The main reason I implemented a new volume type in VisIt was that I wanted to reuse the ospray scivis renderer, and VisIt happens to have its own image compositing tool provided ...

To solve inconsistent sampling problem, you actually need to find a way to adjust the initial sample positions for all the rays in each volume. Since you are implementing a customized renderer already, you will have the freedom to do that in a renderer.

Regards Qi

[Twinklebear]

Hey Marcus,

As Qi mentions for the sampling you'll need to have your own renderer which can ensure the ray offsets used on each process match, so that the ray step size between volume bricks across nodes is consistent.

We do have some improvements to the distributed API and rendering in OSPRay coming soon in 1.8, is this the distributed mode you're referring too? I need to update the examples to show the new API and functionality, but if this is insufficient for your needs I'd be interested to know what's missing.

[Marcus399]

Hey Qi and Twinklebear,

Thank you both for the assistance. I realized I was a bit unclear in my first post - I am creating a distributed renderer, where OSPRay is responsible for all rendering. So I am not implementing my own renderer; rather I am implementing the multi-node functionality + using the OSPRay API.

My current research project is concerning a new technique for in-transit visualization, so the problem is not due to any missing features in OSPRay. I need to run OSPRay independently on all nodes, so I assumed that I would not be able to use the distributed rendering mode to solve my issue.

Basically, what I would like to be able to do is ospSetString(renderer, "sample_mode", "uniform");. Just to make sure I understood you correctly - in order to achieve uniform sampling I need to implement my own renderer?

Regards, Marcus

[wilsonCernWq]

Not sure what do you mean exactly. You said you are running ospray "independently", I guess it means you are using ospray in the "offload" mode where you does the final image compositing work. (Also I am implicitly assuming you are using a sort-last rendering algorithm)

In that case, ospray does know anything about the global bounding box of your volume right? So ospray won't be able to know how to make samples uniformly distributed across all volumes. To achieve your goal, if my assumption is correct, you need to either implement a "distributed" volume type, or implement a distributed renderer, or grab my visit_module where you can use the visit_shared_structured_volume as a standard shared_structured_volume ...

[Marcus399]

I meant that I am not running OSPRay using MPI. And yes, sort-last :)

I will try using the visit_module as per your suggestion. Thank you for the link. It seems to have the exact functionality I was looking for.

[wilsonCernWq]

You are welcome. For that module, I remember there was an issue when trying to enable the gridAccelerator (ospray's shared structured volume has a built-in empty space skipping grid, everytime when you commit the volume, that structure will be rebuilt. This behavior makes sense for some use cases, but in VisIt a renderer does not keep track of if a volume has been changed or not, so I disabled it to avoid the rebuild overhead.)

So if your renderer crashes ... try ospSet1i(volume, "useGridAccelerator", false). I guess I broke it at some point and never figured that out ...

[Twinklebear]

Is the in transit technique based on rendering some additional image data out that goes beyond OSPRay's built in sort-last compositing, or uses some different compositing or rendering technique? If you're able to share some more details, I'd be interested to learn some more about your use case ([email protected]).

The distributed API works different than the offload style rendering, and does actually run your application code independently on each node to setup local geometry and volumes. The only collective operation that OSPRay will run with MPI between the processes is ospRenderFrame, where we then have the processes work together to do a sort-last scivis style rendering, with each process rendering its local data. We used the current distributed API to write an in transit renderer for LAMMPS. For LAMMPS we just have geometry to render, but volumes will also work in the distributed API. So it may meet your needs if you don't need additional modifications to the image data being rendered or how it's composited.

[Marcus399]

Thank you for the head's up Qi! Twinklebear, I will send you an email about the use case.

Thank you both for the help.