woolstar@nntp-server.caltech.edu (John D. Woolverton) (05/14/91)
Well after several interesting conversations and responses
to my initial criticisms of RenderMan, I would like to bring up
some new thoughts and clarify myself a bit.
[I wrote]
>> I would love to have a standard interface to work with
>> (from both sides: modeling and rendering).
>> However my investigation of RenderMan has been _very_ dissapointing.
It has been over two years since I actually looked at the
RenderMan spec. What I have been investigating lately are implementations
of RenderMan by various animation packages on the PC and Mac. It was
pointed out to me that there is a _big_ difference between the two.
>> But for work in RayTracing and beyond, there are too many things missing.
What I found, was that it would be very awkward to try and extract
the information I wanted for ray tracing from the 3rd party implementations
of the RIB file. Perhapse my style of thinking is outdated, in that I have
been used to having access to scene information for setting up my
rendering (ray tracing).
[Mark Vanderwettering wrote]
> RenderMan (regardless of what some people believe) is not a modeler.
> It is not even a modelling language. It is a language which describes
> how scenes are to be rendered ... RenderMan tries to be accomadating
> to modellers, but by no means is there enough information in a .rib file
> to feed an adequate modeller. RIB is perhaps a "write only format",
> similar to PostScript again.
Again, my warped style of doing things includes having access to all
the modeling info in the scene for setup.
> (One doesn't expect to reconstruct a LaTeX file from PostScript either).
Maybe this is what I'm looking for: SceneTeX.
What I use now is a split description:
Static objects exist in separate files: floor.aob, wall.aob, truck.aob
Scene organization is described in reference to the objects:
Camera
position info [across time]
Light
brightness and position info [across time]
static attributes
Actor 1
position and attachment [time]
use object floor.aob
Actor 2
position and attachment [time]
use object wall.aob
Actor 3
position and attachment [time]
use
truck.aob from t1 to t2
truck_detail.aob from t2 to t3
NULL from t3 to t4
Actor 4
position and attachment [time]
use mix
plant_1.aob with [mix track]
plant_2.aob with [mix track]
plant_3.aob with [mix track]
World organization
box { Actor 1, Actor 2 }
box Actor 3
box Actor 4
[I wrote]
>> Extentions to both for geometry organization (bounding boxes...).
[Mark Vanderwettering wrote]
> The third is interesting, but forces a particular rendering style onto
> the user (why is your geometry organization better than mine?).
> Perhaps my automatic bounding volume generator is much better than
> you can do in practice.
I have picked a particular system for ray tracing, and have
spend a couple of years refining it. What I've noticed, is that I
haven't found any general way to automatically decide which objects
to group together.
If you remove the scene and object information, presenting me
with a list of polygons, the problem is that much harder, with no
good grip on how to interact with the artist anymore. (ie I can't
ask the artist "Should I put polygon #871 with #324?").
> I mean, you may not know details about how rays are cast, and the
> relative costs. The renderer definately knows, and perhaps can do
> a better job than a "third party" could.
While the artist using my system doesn't know much about the
ray costs and rendering style. He does have a good idea about how
the scene is organized, and can make decisions as to what is grouped
together. I would like to provide an expert system that will let
the artist try out different configurations, and provide feedback
as to how efficient they are.
Another item lost in the representation is camera information.
I would much rather have a look from and look at point, with
a field of view, than be presented with a perspective
transformation matrix, and have to extract the information from it.
If it is possible at all, I don't know how at this point.
[I wrote]
>> RenderMan is also grossly inefficient for representing polygons
I stand corrected [a hundred times]. "RiPointsPolygons"
I wasn't going by the spec, I was generalizing from the inspection
of the modeler outputs that I looked at. Zero out of four used
the "RPP" model. Very dissapointing, and surprising, considering that
at least two used a 'point--face' model for their objects internally.
As far as the organization of a scene description,
[Tony Apodaca wrote]
> What do we mean by simple animation? We all know the type...
> flying logos, camera moves over static scenes, robot arms and spaceships.
> Basically, simple rigid motions over repetitive objects. Our own animation
> has shown us that people are bored of this, and want to move to complex
> animation: soft, squishy surfaces which deform as they move, faces and
> bodies, scenes with zillions of objects. Everyone wants to see and do this
> type of animation, but what does it do to the image description? Well,
> for one thing, almost NOTHING is constant from one frame to the next.
> Oh, the occasional desk or wall, but the size of the data in the description
> of the wall is microscopic in comparison to size of the data in the description
> of the baby's crying face. It makes a lot of sense to optimize for the big,
> changing data, rather than the small, static data.
I'm not sure I agree completely, and even so, Pixar seems a bit
ahead of its time. I'm not sure how many PC and Mac based allow easy
molding and deformation of polygonal models, but even if there were some,
very few people have the time and patience of John Lassiter (sp?) to go
in and mold each frame of an animation. Alot of smooth blobby animation
is being done right now with in-betweening, and morphing. Even some of
the work in artificial faces, uses a set of pre-defined expressions, and
uses interpolation for generating the facial animation.
The second point is data, 16 Megs of object database times 30 seconds
of animation generates about 14 Gigabytes of data. This is a little
bigger than most peoples hard drives right now. You might argue that
computer storage is getting bigger, but so is the models that people are
building for animations.
> So, what have we learned? Modeling languages are hard.
I agree to that. And so we all keep working on it.
> This is not to say impossible, and I look forward to the day when a smart
> person solves this problem. But Pixar didn't (and doesn't) know the answer.
I wish someone did. I have some ideas as to what I want, and I keep
listening and learning what other people want. RenderMan starts to address
part of the problem, and may be a good step towards bringing rendering packages
together, but I'd like to see things evolve further.
John D. Woolverton, Engineer -- Video Bits
woolstar@cobalt.caltech.edu
CPU-use figures probably won't rise much until hardware stops speeding
up, or somebody makes a hell of a breakthrough in software technology,
or we invent a drug that makes people more intelligent, or we stop
reading news and spend more time coding, or computers learn to
program themselves, or...