RM: Standards, Options, wish-list ...?

RM: Standards, Options, wish-list ...?

Post by Tal Lewis Lancast » Thu, 20 Jul 1995 04:00:00



While trying to maintain the RMR (http://pete.cs.caltech.edu/RMR/) and
playing around with my own and other's RIB files, I have noticed some
things that would make life under RenderMan more productive.

NOTE: Before, I go further, realize that this is my own myopic view of things
as I have never read the RenderMan spec and my version of prman (the default
one supplied with NeXTSTEP) didn't really come with much in terms of
documentation and so I don't even know what command-line options are available.

First: Standards

I would like to know what other platforms people are running RenderMan
under?  And what picture formats do their renders support?

        For me I do most everything under NeXTSTEP, using BMRT and prman.  Which
        both produce TIFF files.  Under NeXTSTEP, everything is known by its
        suffix.  Which means that even if a file foo.pic is really a TIFF image
        the image programs won't know that they can display it until it is renamed
        to foo.tiff.

Second: Speed and Development Options

        Ok, most of us know to speed up the rendering time during
        the development of a scene, we make smaller images and if we're using
        prman we can mess with the shading sample rate.

   But the problem, is the one has to keep going in and editing the RIB to
   fine tune it to what one is doing at the moment.  And this is doublly
   (okay that may not really be a word) annoying if your switching
   back and forth between prman and BMRT (Namely, if your dealing with
   texture files).

   Yes, there is support for a control file .rendribrc but the contents
   is ignored if the RIB already contains those references (ie. Format, etc.)

It is my opinion,  that the options (Format, Display, Aspect, etc.) in
the RIB file should be what the creator feels to be the proper settings for the
finished work.  However, these settings should be allowed to be overridden
through either command-lines or configuration files.

For example say there was the following RIB, called foo.rib

Format 640 480 1
ShadingRate 1.0
PixelSamples 3 3
Display "foo.pic" "file" "rgba"
. . .

But say you wanted the following while mucking around with other parts of the
RIB:

Format 100 100 -1
ShadingRate 20
PixelSamples 1 1
Display "foo.tiff" "file" "rgb"

In my dream renderer, one could say something like:

ribDream -f quick1 foo.rib

Where the option file quick1 would contain the desired options for that
were desired the current rendering.

Conclusion:

   I think something like this would have two benefits:

   1. Make it easier to share RIBS across platforms and implementations of
   RenderMan.

   2. Make the development cycle of a RIB less cumbersome.

I would like to hear what other's thoughts are on this subject.

Tal Lancaster
--
###########################################################################
Tal Lancaster
HTML:  http://www.compbio.caltech.edu/~tal/tal.html
###########################################################################

 
 
 

RM: Standards, Options, wish-list ...?

Post by Larry Gri » Fri, 21 Jul 1995 04:00:00




Quote:

>In my dream renderer, one could say something like:

>ribDream -f quick1 foo.rib

>Where the option file quick1 would contain the desired options for that
>were desired the current rendering.

Tal, you can already do this with either prman or rendrib.  Make your
main RIB file contain everything *but* options, then split your
options into different opt files.

For example, suppose test.opt contains:

        Format 320 240 1
        ShadingRate 4
        PixelSamples 2 2

And final.opt contains:

        Format 1280 960 1
        ShadingRate 0.25
        PixelSamples 4 4

And foo.rib has your actual frame (but doesn't contain Format, ShadingRate,
or PixelSamples statements).  Then you can just type:

        prman test.opt foo.rib

*or*
        prman final.opt foo.rib

or, obviously, the same thing for rendrib.  They all just read the RIB
files sequentially anyway.

        -- lg

--
Larry Gritz                                     Pixar Animation Studios


 
 
 

RM: Standards, Options, wish-list ...?

Post by Paul Roteri » Fri, 21 Jul 1995 04:00:00




Quote:>While trying to maintain the RMR(http://pete.cs.caltech.edu/RMR/)

First off, my sincere thanks for maintaining a fine resource.

Quote:>NOTE: Before, I go further, realize that this is my own myopic view of things

Noted.

Quote:>I would like to know what other platforms people are running RenderMan
>under?  And what picture formats do their renders support?

I run BMRT under linux.  I *used* to run it under SunOS, but when I started
writing my own shaders, I needed a platform for which slc worked.

As you know, BMRT supports tiff files.

Quote:>    Ok, most of us know to speed up the rendering time during
>    the development of a scene, we make smaller images and if we're using
>    prman we can mess with the shading sample rate.

BMRT supports numerous methods of lowering rendering time.  In fact, Larry
outlines the most useful methods in "BMRT: User Guide".  You *have* read
that, haven't you? :-)

Quote:>   Yes, there is support for a control file .rendribrc but the contents
>   is ignored if the RIB already contains those references (ie. Format, etc.)
[...]
>However, these settings should be allowed to be overridden
>through either command-lines or configuration files.

Okay, I guess you *didn't* read it (or "RenderMan for Poets"...).
It's pretty spartan (as compared to RC), but worth the time.

-Paul Rotering

--
-Paul Rotering
 http://www.nmt.edu/~proterin/

 
 
 

1. The POV Wish List

There's been a POV4 wish list thread (actually, a couple of them), which
was inspired by an idea I had for an on-line publication.

There were several criteria I had for what should be higher on the wish
list (ie, where we would most appreciate the POV teams' efforts).  These
are:

1.  General demand.  If only two people want something, then the POV-team
would be wasting their time.  If everyone wants it, then that's a different
story.

2.  Difficulty of the work-around:  If a ten-line .inc file can do the job,
then there's no need for the POV team to spend a few weeks hacking code.
On the other hand, mapping an image_map onto a Bezier curve (which could be
done in an .inc file, but with lots and lots of work), is a better
candidate.

3.  Ease of implementation:  Sweeping a fourth-dimensional curve along a
cubic spline would involve either lots of triangles or lots of root
crunching; neither are plesasnt.  If you don't have the faintest idea how
a feature would be implemented, then that's a good sign that it's too
complicated.

Anyway, the following are in the running:

* a function that returns the size (in POV units) of a given ttf object
(high demand; work-around is by extensive trial and error; should be
trivial to implement)

* a function that delivers the elevation of a given point in a height
field (moderate demand; work-around involves extensive trial and error;
should be easy to implement)

* smoothly connecting spheres (moderate demand; work-around involves
good analytical geometry skills or the CTDS utility; should be easy to
implement)

* spherical and cylindrical height fields.  (High demand; work-around
involves utility software; should be no more difficult than the planar
height_field)

* NURBS (moderate demand; work-around requires third-party utility to
devolve NURB into triangle mesh; moderate to high implementation
difficulty)

--
"The existential root of Libertarianism is the experience of being very
bad at taking orders from morons."--Leopold Leider.


2. when did Andy fear the twig without the full onion

3. 3-D widget wish list?

4. fs

5. Hello Deneba: Canvas 7 wish list !!!!!

6. Building SuperPalettes

7. Send Me Clip Art Wish Lists

8. Help with filters

9. StrataStudio Pro wish-list - your comments wanted

10. The New Internet Graphic Format - A WISH LIST =)

11. Wish List for new computer hardware? (Windows)

12. summary for wish list for low-level image processor