Continuing my experiments with 3Delight I am starting a test thread on getting the Blender background, in some form or another, to render automatically like the lights do using Matt Ebb’s 3Delight exporter v0.6.
I figure with softshadows working, ambient occlusion, global illumination DOF, motion blur, and reflections with blur. To top that off with a backround that can light your scene would just make 3Delight a really nice external render system.
Currently I am stuck on how to proceed and I wonder how the professionals render their backgrounds out of RenderMan? I can not find any reference to the syntax that defines the world, as we know it in Blender, inside the RSL (Renderman Shader Language).
So I am assuming that it is just a shader applied to a giant sphere around your scene.
I am aware of the background.sdl file. But I do not know what object to apply it to. When I apply it to a mesh the parameters fail to initialize indicating that that shader probably was not designed for that object type.
There is also something called physicalsky.sdl and physicalsun.sdl. I have applied the phsyicalsky to a point light and the exporter does reveal parameters for the shader under the light panel. But presently there is an error in the exporter that prevents the shader from working. It seems that physicalsky.sdl uses a float [3] data type for one of it’s parameters which is not currently supported by Matt’s exporter.
It currently outputs…
"float i_rgb_unit_conversion" [ None ]
But it should be:
"float[3] i_rgb_unit_conversion" [ 0.0 0.0 0.0 ]
Another thing I read about is IBL (Image Based Lighting).
Does anyone know know how this would work in 3Delight from Blender?
Do I apply this to the insde of a skysphere?
for reflections you’d use an environment call in the surface shader.
For the “world” as you see it in the final render you use an imager shader. Don’t know wether it’s there in the world tab in matt ebbs exporter but if not, just go to your .rib file and add it before the world begins.
The syntax is the same as with the surface/displacement/light shaders etc. Just write Imager “shadername” and then the parameters …
I’ve updated it a few weeks ago so it should work. But it’s more or less in the middle of a change of how it’s internally preparing data. Need to fix some things to get away from needing to poll stuff with a model operator/in draw methods and such hacky stuff. The new event handlers and update callbacks should help with that.
Considering the complexity it is more complicated than matt ebbs exporter. He made 3delight work “the blender way”. I was more trying to expose “the renderman way” to blender. Realy serves different purposes i think. Though I’ve tried to include some shortcuts to make it, though being more complicated, still fast to use even on big scenes. Could even go further with that.
I should realy make a video explaining the workflow i imagine …
And about the mosaic project: It is in heavy development since being merged into the aqsis project. All this pipeline stuff sounds complicated but in fact for simple things you wont need to touch that as it’ll ship with ready to use pipelines for comon tasks.
I just mean that if i cobble together my own shader then adding it in matt’s exporter seems to fit my needs better than having to mess with xml for an interface in mosaic…
I may be getting it wrong, but i just don’t get the need… it also just seems that Matt “gets it right” for putting stuff where you expect it to be…
I’m interested in using some of the FOSS renderman renderers too. I’ll enjoy comparing yours with the other two!
You don’t need to wrap the parameters in an attribute block. The Imager shader itself is an attribute. All the parameters that follow are token/value pairs that are part of this attribute.
Renderman is, just like OpenGL (I’ve heard they took this concept from renderman) a state machine. When you set an attribute e.g. a surface shader or a transformation, everything that follows will get this transformation/surface shader unless you change that. Theese Attribute blocks are there to prevent this. So if you set an attribute inside an attribute block, only the things that follow inside this block will get this attribute.
And the imager shader needs to be before the world block begins as it is not part of the world. The world block should only contain things that are part of the scene, that are lights and objects.
Think of the imager shader more as a post processing filter(actually it IS a post processing filter).
I found a imager shader called bluesceen.sl. It allows a texture to be used by the imager. If you leave the texturename blank it acts like background.sl and delivers a solid color.
/*
* bluescreen.sl
* puts a background color behind an image.
*
* PARAMETERS:
* background - the color of the background
*/
imager bluescreen (
color background = color(0.0, 0.0, 1.0);
string texturename = ""
)
{
float resolution[3];
float lenx, leny;
color tex;
if (option("Format", resolution) == 1.0) {
lenx = xcomp(P)/ resolution[0];
leny = ycomp(P)/ resolution[1];
}
if (texturename != "") {
tex = texture(texturename, lenx, leny);
Ci+=(1-alpha)* tex;
}
else
Ci+=(1-alpha)*background;
Oi=1;
}
Does the imager support things like sphereical and angular maps or standard projection techniques?
They should, but i never used them myself so don’t know how. Essential Renderman doesn’t mention Imager Shaders, does it?.
It does talk about projection techniques in surface shaders. They’re quite easy. Just transform P into the coordinate system you like and compute your s and t coordinates from it.
It should work similar to that in the imager shader. Try to pass P as the coordinates to your texture() shadeop and check what happens. Maybe it’s all you need to do.
In this example just replace “lenx, leny” with “P”.
And then try “transform(“world”, P)”
EDIT: Just reading the part about Imager Shaders in the book “The Renderman Shading Language Guide” by Rudy Cortes (great book and imo a must if you want to learn how to write RSL shaders) and he writes:
“Imager shaders are one of those ideas that seemed great on paper, but they never really caught on, especially once strong compositing packages became available to public.”
and
“… most of the things that you can do with an imager shader you can do with a decent compositing system.”
So just comp in blenders compositing and for spherical mappings just use a shadeless sphere with a texture …
I made some progress integrating the Imager shader type into the GUI of the World context.
Now you can specify an imager type shader and the parameters will appear for adjustment and or animation.
Here is an example of the background shader mixing it’s BG color with a supplied image.
I am still trying to figure out how to integrate a preview directly into the panel. Like Matt has done under the material context. Seems his existing preview code does not like being moved to the World context.
