Re: Some Lua & SWIG questions

[Moritz Moeller <realritz@...>]

Miles Bader wrote:
> Moritz Moeller <realritz@virtualritz.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 
pipeline's perspective.
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 )
  world();
   sphere()

A minimal scene with motion blur that demonstrates some features looks 
something like this:

  translate(1,2,3)
  world()
    pushparameters()
    parameter( "surface", "plastic" )
    look();
    popparameters()
    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:

  translate(1,2,3)
  world()
    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
> rendering.

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 
guest.
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
> these days.

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.


Cheers,

Moritz