Render Elements

[hdarren]

We are working on a prototype for render elements in Krakatoa, and I want to run it past you guys. I figure there are 3 render element categories:
[]Shader Elements - These are the various sub-components of the shaders such as Diffuse, Specular, Transmission, etc.[/][]Data Elements - These are passes that display data about particles like Normals, Velocity, etc.[/][]Renderer Elements - These are passes that visualize parts of the rendering process. This is the most vague, but includes things like Raw Lighting (light reaching a particle before the shader is run), Self Shadow (Extinction due to iteraction with particles before light reaches a particle), and possibly many more[/]

Unlike Scanline or VRay I don’t think I will hard code a specific render element object with a unique class id per possible pass. Krakatoa is too flexible to ever make that worthwhile, since we can have arbitrary data, etc. My current plan is to make 3 objects that will appear in the normal Render Elements list, one for each category I listed above. Each of these objects will have appropriate UI elements to select the specific data to render. For example a Shader Element will have a dropdown to choose the shader components exposed by a specific shader. For Phong shading this would be Diffuse and Specular. The Renderer Elements would simply have a list of elements that are supported by Krakatoa. This is more or less a hard-coded list because it requires code to be written in the core of the renderer to support them. The Data Elements are the most interesting since they can support arbitrary data that Krakatoa doesn’t know about at all. Currently you could render these channels by carefully crafting KCMs to assign Color, Emission etc. and the correct lights. The proposed system will expose the Magma interface via. the render element, drawing whatever the output of the KCM is for a given particle. I’m not sure what sort of compositing modes make sense for this particular type. Currently I am rendering the ouput with full alpha, but I’m sure people want the normal Density based approach as well.

Thoughts?

[hdarren]

The easiest response first:

With Shader Elements, would it be possible to evaluate more than one shader at a time? I mean, could you output Phong Specular and Schlick Scatter in the same render?

I can make this work if all particles render with both shaders. Having some particles render one shader and some render another is a tricky problem. Its pretty straightforward for particles (use an integer index to assign a shader), but really freaking hard in a voxel (It needs a float PER-Shader-PER-voxel to store the relative weighting of each shader). I guess that’s not hard as much as it is prohibitively expensive.

I wonder what Renderer Elements are possible… Could we get say “Spatial Density” output that would show the number of particles per pixel? Same thing with the voxel renderer, output the number of particles in that voxel, or the number of particles sampled by that voxel in the filter?

That’s definitely something that can be done. In fact, I would do that by using additive compositing and just rendering the Density channel. You would have to have all particles with density 1.0 and a global tweak of 1.0 (instead of 5.0e-1 default). You need to be aware of how the filter would affect this too, but I’m sure you know that

Without layers, the Data Elements are going to be just first hit unfiltered, right? Might not be ideal, but the alternative would be to add layers and increase pixel samples, right?

Yeah. This is something that no one can adequately explain to me. What the hell does a Normal pass for a semi-transparent set of objects look like? I personally think its useless, but having that around seems to make some people happy. Multiple layers could be achieved somewhat like the shadows I guess, but Max doesn’t provide any way to do that within the Render Element framework. All we get to do is fill in a Bitmap object, which definitely doesn’t support all the fancy stuff I was doing with OpenEXR images.