In K-3D we use the term "render model" to describe the components that must work-together to produce a rendered image. Current render models normally include:

Note that, unlike other 3D applications, K-3D is designed to be "render model agnostic" - it supports multiple models and does not "prefer" any one model over the others. This differs from applications such as Blender or Maya that have built-in render models and use "export" operations for everything else. Currently, K-3D supports three main render models:

An important characteristic of render models is the strong coupling amongst their components - virtually all current render models require strong coordination among lights, materials, and the render engine to produce an output image. The capabilities of these components vary widely from model-to-model, which is why K-3D provides "matched sets" of components for each render model. For example:

A key observation is that there is very little commonality between components from the different render models - provides a different set of options than . is completely programmable through shaders while provides a limited pipeline for combining preset shading functions. is similarly programmable via shaders while Yafray provides multiple light types, including global illumination capabilities not found in RenderMan.

It is because these render models are so different that K-3D makes no attempt to provide "generic" render model components. There is no such thing as a "generic light" in K-3D - there are RenderMan lights, and there are Yafray lights, but the two do not interact. If you create a scene intended for rendering via Yafray, you will need to populate your scene with Yafray lights and materials. Similarly, a scene intended for RenderMan will need to contain RenderMan lights and materials.

Of-course, you are free to create a scene that contains multiple render engines of different types, but a Yafray light won’t show up in images rendered using and a won’t show up in images rendered with .

Similarly, your scene will need to contain materials appropriate for the render model in-use. Because you can only assign one material to a geometric primitives at-a-time, a special material node - - acts as a "container" of materials so you can add multiple render-model-specific materials to your scene.

Note that the OpenGL render model is special, because it serves the needs of <b>editing</b>, where trying to maximize realism is actually counterproductive - you don’t want to have to squint while selecting geometry just because you happen to be setting-up a low-key scene. As alluded to above, there are no OpenGL light source, and all normal OpenGL lighting is via a "headlight" - a distant light source that always shines in the direction the is pointing - so you can always see what you’re looking at.

You have the option of allowing other light sources to contribute to the OpenGL scene, but this is necessarily a low-fidelity simulation, as the OpenGL shading model is the simplest of any that we support. There simply isn’t any realistic way to "translate" a RenderMan light shader or a Yafray Hemilight (for example) into something that fits the OpenGL model.