I have an application that I would like to explore whether it can use cycles as a backend. The front-end is for scientific visualization, and as such, can generate a huge amount of rendering primitives (inputs to the front-end can be terabyte to petabyte in size). I have a few questions about cycles capabilities to see if I can extend it to fit our needs.
What is the level of instancing support in Cycles? Can different instances have different shaders/attributes? Can instances be motion blurred? Can lights be instances (if you had a 1000 bunnies in a scene that you would want to illuminate that scene, would you make them lights, or have emissive materials)?
From what I can see poking the code, cycles does not have native support for quadrics (Spheres, Cylinders, …). What would be the best way to support them? Especially if you wanted partial quadrics (e.g., a sphere clipped at the poles)?
Any plans on making cycles a Hydra client?
A large portion of the front ends output is meshes which fits nicely with cycles. But for certain types of visualizations we use items 1 & 2 heavily,
There are no lights of type mesh in Cycles, just meshes with emissive shaders that have an option for importance sampling. Those can be instanced, but for importance sampling memory usage will be poor, as if there was no instancing.
The easiest would be to tessellate them. If you want native support you’ll have to implement that as a new primitive. This is not something we’re likely to support in Cycles any time soon as we’re more aimed at animation / VFX use cases.
We do support rendering pointclouds as sphere, and hair as smooth curves. But that’s not the same as clipped spheres or cylinders.
Developers at NVIDIA are working on this, updating an earlier implementation from Tangent Animation.
Thanks for the information. It appears that Cycles would fit our needs.
It may be easiest to just tesselate Quadrics. A partial sphere would be fairly easy to tesselate into a UV sphere. I would have to go native if we have more varying types than instances and start blowing out memory. I don’t think that’s likely, given our previous outputs, but I won’t know until I try.
As an FYI, I work on a visualization software (VTK-m) that like Cycles, started out supporting a wide variety of devices, CUDA, Intel TBB, pthreads, … With the announcement that two of the exascale platforms that are starting to come on line will be based on HIP and SYCL, we changed our backend to be based off of Kokkos. We’re still performance tuning, but have found that our Kokkos device is generally within a few percentage points of the native implementations (some better, some much worse, but overall good).