[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Some Lua & SWIG questions
- From: Moritz Moeller <realritz@...>
- Date: Mon, 16 Jul 2007 16:41:38 +0100
Miles Bader wrote:
Moritz Moeller <email@example.com> writes:
I'm writing a binding that allows Lua to be used for describing 3d
scenes intended for rendering with a high-end 3d renderer like Pixar's
PhotoRealistic RenderMan or DNASoft's 3Delight. The target audience for
this is foremost the visual effects industry.
Do you have a description of your lua interface available?
yes I do. It is modelled after the RenderMan interface but removes some
of that API's biggest constraints from a contemporary feature film VFX
My industry has settled on Python as the glue language. So I started
with a Python binding and dropped it soon because it just parses too
slow. We often have scene descriptions in the GB range. We can't have
parsing time be a considerable part of the overall render time. That's
how I got to look at Lua. :)
Besides, because I had similar problems with va_args in the binding
generator on the Python side, I had to write the Python binding by hand
as well. That wasn't fun at all.
Lua's API on the other hand has been an utmost pleasure to work with.
Very well designed and straightforward.
My API uses stacks to "send" attributes, shaders & parameters to
primitives. It maintains a transformation, attribute and a parameter stack.
It also maintains a complete hierarchical graphics state. Although in
the VFX industry we rarely make use of the hierarchical capabilities of
the RenderMan interface, I consider it a required feature in general.
"Hello world" looks like this:
translate( 0, 0, 2 )
A minimal scene with motion blur that demonstrates some features looks
something like this:
parameter( "surface", "plastic" )
motion( -1, 2 )
parameter( "radius", 1 )
parameter( "radius", 4 )
sphere( -.6, 1.7 )
The first lines are essentially the camera transformation. After world()
we are at the origin and the transformation on the the stack is identity.
We define the surface aspect of a look. A look is several components
defining how a primitive is rendered. We then instance a look which will
query the parameter stack, see if there's any parameters applying to the
look context and if so use them to do its job. This is enclosed into a
pus/pop param block, so the "surface" parameter doesn't pollute the
parameter stack once we're done with the look. This is completely
optional in this example.
Next comes a motion block defining how many calls (time samples) of the
same type are to be expected at which times.
The parameter calls itself push a "radius" parameter on the stack.
Parameters can be time-varying. Here, "radius" is defined at time -1 to
be 1 and at time 2 to be 4.
Then it renders a sphere which will pick up this "radius" [since it's a
reserved parameter name understood by sphere(), just like "surface" is
for look()] and will render it motion-blurred over the shutter (which
ranges from 0 to 1, by default) but interpolating it explicitly at times
-0.6 and 1.7 before sending it off to the renderer.
The whole thing could be slightly simplified like this:
look( "surface", "plastic" )
motion( -1, 2 )
sphere( "radius", 1 )
sphere( "radius", 4 )
In this case the sphere won't interpolate the values at -.6, 1.7 before
sending them to the renderer though.
Lua seems like a very nice language for this purpose[*], and it would be
cool if there were some sort of common ground for people using lua for
This is gonna be open source a and I intend to get as much people on the
bandwagon as possible. The current standard in my industry is the
RenderMan RIB format which is an ASCII binding for the RenderMan C API.
It is still great, after almost 20 years. But is shows its age too and
the additions to it to keep it up to date with the pace of the VFX
industry many see not as ingenious and visionary as the API itself once
was in 1989... :)
So if you're interested in helping out with this or adopting it... be my
I'm probably still a good two month away from having anything complete
enough to give it out or expect so. to be willing to take a look at all. :>
I'm reluctant to give out a draft yet. The reason being that it remains
in constant flow for the time being as the group of people testing it,
around the globe, fill my inbox with feedback. :)
[I've written a lua scene-description interface to my renderer but it's
quite bare-bones and more or less just exports internal interfaces
(using swig) with a bit of sugar on topl.]
[*] I really love "dynamic" scene description languages (e.g. povray's),
as opposed to the rather static input formats that seem more common
Yeah. Although Povray is not a prime example of a well-designed scene
description API. You can tell that it was made by people who wanted to
render chrome spheres on infinite checker boards, originally.
But I agree as far as "dynamic" goes. Although that is also a fairly
philosophical debate as when one can run a program to create a part of
the scene, there not much you can't do.
It's more a matter of ease & elegance[tm] then, imho. Which, I agree,
many formats lack.