>Has anyone tried to model any of the Toy Story
>characters with POV Ray? (I'm not sure if
>Pixar would get upset by this.)
>I'd be very interested in a Buzz Lightyear
>model and may give it a shot myself after I
>finish my way overblown first project.
Yeeek. We're talking *way* complex here -- tho I'd love to see it
myself if it could be done.
E. Lynn Flanagan -- Shard @ ColoniesMUCK -- WonderMom!
(This is a shared account. If you MUST flame or respond via E-mail,
please put ATT: Lynn in the subject line. Thanks!)
I'd be very interested in a Buzz Lightyear
model and may give it a shot myself after I
finish my way overblown first project.
--
Craig W. Daymon
Nope. Modelling was done in Alias and with mdl, our in-house modeling
language. Rendering was with Renderman, of course.
Jim
(will...@pixar.com)
No. Pixar PRman Renderman-compliant scanline renderer. If you had
the models you could probably run them through BMRT.
Cordially,
Sumner
Please don't CC: postings to me, my mailbox is already full enough.
I thought 'Toy Story' was done in lightwave?
Later,
Erik Z.
i thought it was made on a whole network of regular pcs, all the processing
power hooked together.. and modeled using silicon graphics workstations...
hmm...
--
Ądelusion!
(delu...@inetworld.net)
: I thought 'Toy Story' was done in lightwave?
You're trying to be funny, right?
j
--
: i thought it was made on a whole network of regular pcs, all the processing
: power hooked together.. and modeled using silicon graphics workstations...
No. The rendering was done on tons and tons of Sun Sparcs.
j
--
I believe it was made on Suns _and_ SGIs.
--
Yup, modeled on SGI, rendered on SUN (according to the film's
credits). And, of course, rendered with RenderMan. I think it was
modeled with a combination of Alias and proprietary modeling tools. Not
that I know this: but I would suspect that a number of NextStations were
also present (and for that matter Macs, and maybe even a PC or two -
afterall, there's a tool for every job).
Mark Lasersohn
Cow House Productions
la...@cowhouse.com
http://www.cowhouse.com
330-569-7492
Animation was done on SGI workstations. The renderfarm was a whole
mess o' Suns.
>E. Kevin Hall wrote:
>>
>> Jason Bright wrote:
>> >
>> > delusion (delu...@inetworld.net) wrote:
>> > : Z <eaz...@genius.dungeon.com> wrote in article
>> > : <328A26...@genius.dungeon.com>...
>> > : > Lynn Flanagan wrote:
>> > : >
>> > : > I thought 'Toy Story' was done in lightwave?
>> >
>> > : i thought it was made on a whole network of regular pcs, all the processing
>> > : power hooked together.. and modeled using silicon graphics workstations...
>> >
>> > No. The rendering was done on tons and tons of Sun Sparcs.
>> >
>> > j
>> > --
>>
>> I believe it was made on Suns _and_ SGIs.
>--
> Yup, modeled on SGI, rendered on SUN (according to the film's
>credits). And, of course, rendered with RenderMan. I think it was
>modeled with a combination of Alias and proprietary modeling tools. Not
>that I know this: but I would suspect that a number of NextStations were
>also present (and for that matter Macs, and maybe even a PC or two -
>afterall, there's a tool for every job).
Last year, Wired magazine had an OK article on the making of Toy
Story. The hightlight of the article was the pic of "one of the rooms
of Sparcs" Maybe 500 of 'em. Not a steenky PC to be seen.
bucko
Last I heard (text file from somewhere, with lots of Toy Story stats. _How_
many leaves?) it was done using SGIs for the modelling and animation
GENERATING software, and this data was then shipped out to a rendering farm
of (110?) Sun stations.
Oh boy. What I would do for that setup...
Kelloggs
--
| Paul Kelleher, reachable at: | You know you're in trouble when you have |
| 1: sm6...@csc.liv.ac.uk | to pipe your compiler errors through |
| 2: pa...@unix.liv.ac.uk | more. Via grep... |
| And possibly elsewhere, too. | |
--
Did they show the room where the book-keepers kept the
spreadsheets up to date?
Yup! In jurassic park, they used amigas for color correction
(what ever the hell that is)
Brian Meidell AKA coo...@image.dk
-A4060 MKII-90MB-4.5G-17"SONY-V34-
>Last I heard (text file from somewhere, with lots of Toy Story stats. _How_
>many leaves?) it was done using SGIs for the modelling and animation
>GENERATING software, and this data was then shipped out to a rendering farm
>of (110?) Sun stations.
It was definitely made on Silicon Graphics. I saw a "behind
the cameras" type tv program, where lassiter was sitting
around saying things like ".. and then i can just press this
and render this realtime" as a casual kind of remark while
he was showing some of the wireframe-like previews.
>Oh boy. What I would do for that setup...
All you have to do is work your fingers to the bone untill
you have about 60 million dollars, or so. :)
I'd happily kill the president of some small country for a
setup like that. :)
By the way, Pixar is not capitalized.
--
------------------------------------------------------------------------
E. Kevin Hall home: bjh...@neptune.ultranet.com
Silicon Graphics www.ultranet.com/~bjhall
1 Cabot Road work: (508) 562 - 4800
Hudson, MA 01749 ha...@boston.sgi.com
> The rendering was done by PIXAR on SGI's running Renderman(not
> lightwave)
A couple of messages ago, I believe that an article was referenced,
the location of which I don't remember, which stated that, though
some SGI challenge servers were on the backbone, the number crunching
was done by some suns.
By the way, you did see the email address of the person you were
"correcting", right?
:-0
--
Mike Norton
----------------------------------------------------------------------------
--------------------------------------
Mike Norton Ministries http://www.tcnet.net/manorton
SBC InterNet Church Directory http://www.tcnet.net/manorton/sbc
Baptist Ministers Resume Service http://www.tcnet.net/manorton/bmrs
Mike Norton's Ray Tracing Page
http://www.geocities.com/Heartland/Plains/1975
Proverbs 27:17 "As iron sharpens iron, so one man sharpens another." (NIV)
E. Kevin Hall <bjh...@neptune.ultranet.com> wrote in article
<3298F397...@neptune.ultranet.com>...
> Matthew R. Taylor wrote:
> >
> > James W. Williams wrote:
> > >
> > > In article <328E6465...@neptune.ultranet.com>,
> > > E. Kevin Hall <bjh...@neptune.ultranet.com> wrote:
> > > >Jason Bright wrote:
> > > >>
> > > >> delusion (delu...@inetworld.net) wrote:
> > > >> : Z <eaz...@genius.dungeon.com> wrote in article
> > > >> : <328A26...@genius.dungeon.com>...
> > > >> : > Lynn Flanagan wrote:
> > > >> : >
> > > >> : > I thought 'Toy Story' was done in lightwave?
> > > >>
> > > >I believe it was made on Suns _and_ SGIs.
> > >
> > > Animation was done on SGI workstations. The renderfarm was a whole
> > > mess o' Suns.
> > >
> > > Jim
> > > will...@pixar.com
>
> > The rendering was done by PIXAR on SGI's running Renderman(not
> > lightwave)
>
> By the way, Pixar is not capitalized.
>
Stop it, please! You're making me drool. :)
Can you imagine the effort of trying to do all that work on a single
Pentium? x(
Paul "Voss" Hinds
It's a GREAT picture and I own a copy on laserdisc, but a great deal of
what makes it
so good is the quality of the writing in the story. Much better than a lot
of the
gimmicky crap Hollywood is tossing out lately. It also has the PERFECT
tie-in for
merchandising. (Gee, how fortunate!)
Now, the animation is another story. That's something that I believe would
be
really taxing for Lightwave and virtually impossible for POV Ray. But pick
a single
scene and I think that can be done quite well in either package. (For the
most
part, the motion blurring and some other effects that I'm not aware of when
watching
it might prove difficult.)
Mike Norton <mano...@tcnet.net> wrote in article
<01bbda81$8d34ba60$d35f9bce@mikenort>...
> > > > Animation was done on SGI workstations. The renderfarm was a whole
> > > > mess o' Suns.
> > > >
> > > > Jim
> > > > will...@pixar.com
> >
OK, we are waiting your version of Buzz, Woody, Rex and maybe some
external scenes. Let us know if you used Lightwave or POV and how many
millions of polygons you used for having the same surface quality and
what kind of CPU. Maybe a single 486 or Pentium ? Please try to be in
the 10 years range for a single frame.
Happy modelling :-)
Guido Quaroni
www.gestel.it
>> Animation was done on SGI workstations. The renderfarm was a whole
>> mess o' Suns.
>Can you imagine the effort of trying to do all that work on a single
>Pentium? x(
...and there was me wanting to do it on a 486/66 ;-)
Maybe I'll have to go buy that SGI Onyx after all... just have to get the
money to build the air-conditioned room, etc.
Ica
So I'm guessing that a 200MHz Pentium system with say 32 to 64MB of RAM
could
render an equivalent scene at 1024x768 in under a day. POV Ray supports
plenty
of lighting modifiers for enhancing the scene. If you're not doing
collision
detection or any animation, you greatly simplify what is involved.
I'm interested to know what you see in the movie that makes you think one
of the
scenes (without actively looking for the most difficult) would be so hard
to duplicate in a reasonable amount of time. (Someone with good modelling
experience -- maybe someone connected with Moray -- say in about 2 weeks?)
I'm guessing you have a copy. Watch it again and freeze frame a couple of
shots. I'm not trying to give you a hard time, I just don't see it as that
hard given TODAY's tool set. Now, using POV Ray 3.5 years ago, when they
probably started Toy Story, and it might have been different.
Guido Quaroni <gu...@gestel.it> wrote in article
<329E6F...@gestel.it>...
There are a number of things that would make doing even a moderate frame
from Toy Story difficult. The characters in the movie are very well done, and
would take quite an effort to duplicate them, to get them to look "right".
Also they "rendered" the scenes, not "ray traced". Not going into the details
of what each is too much. Rendering typically produces better lighting
effects, and ray-tracing produces better surface effects (reflection,
refraction). Also rendering is typically much faster than raytracing,
especially as the number of light sources, and the complexity of the light
source, increases (Side Note: If you have ever noticed, all light sources in
POV-Ray are point source, that project a spherical light distribution, even
if you create a "florescent" lamp with a "looks_like" operator, rendering lets
you (easily) have different shaped light sources).
BTW: I know I spelled various words different ways in different places, I am
hoping I got them right in at least one place :)
--
David Cross
ACS Consultant
Rensselaer Polytechnic Institute
You're just not getting through, I think.
I have an idea why, tho.
You might quote some pixel resolutions as well as file sizes.
Also, the system resource heap on a home PC might not handle 1,000+
recursive calls through a render subsystem (whew!), mandated by the
images you rendered.
I am using a "toy renderer" on a P150+ system with 48 megs of ram.
That's about half the system that you mentioned - people think it is
easy. Technology is so available now.
If you had -one- Dxf file that you could post on a web page, you could
shut down this thread.
Seeya,
Anonymouse
> Craig W. Daymon wrote:
> >
> > I think you exaggerate the quality of the scenes in Toy Story. Yes, it is
> > a WONDERFUL
> > picture and yes, the graphics are very good. But I believe that almost any
> > of the scenes
> > could be duplicated in Lightwave or POV Ray or a number of other products.
>
> OK, we are waiting your version of Buzz, Woody, Rex and maybe some
> external scenes. Let us know if you used Lightwave or POV and how many
> millions of polygons you used for having the same surface quality and
> what kind of CPU. Maybe a single 486 or Pentium ? Please try to be in
> the 10 years range for a single frame.
Looks like somebody doesn't quite understand how POVRay works. I'd have
thought that if you had the dimensions to work from, you could do, for
example, Woody's face with perhaps a dozen bezier patches. That's a somewhat
better way of doing things than using multitudes of polygons. Although I
suppose a heightfield could be made to work too...
Dunno about Lightwave, but a Woody or Buzz ought to be quite doable under
POV. Right?
--
Simon Smith
Caffeine *is too* a substitute for sleep.
Au contraire, please allow me to differ in opinion.
For starters, most of the characters in Toy Story were modeled using
trimmed NURBS, rational bicubic patch meshes, etc. Don't know about
LW, but POV-Ray doesn't do NURBS at all. It also doesn't do
programmable texturing (other than the small number of built-in
shaders), which is used *everywhere* in Toy Story, and we honestly
believe that the movie couldn't possibly have looked good without it.
I guess it hinges on what you mean by "duplicate." Could you construct
a single still frame with characters that looked superficially like the
characters in Toy Story? Sure, but that misses several important points:
(1) Toy Story is an animation, not a still (and not just a whole bunch
of stills); (2) It's not at some PC video res -- it's splashed up there
on a 60 foot movie screen. Making something stand up well on film is
not simply rendering at higher resolution. (3) The scope of handling
1400 or so shots is much larger than you might think -- again, while
other programs may, with lots of effort, be able to render a single
image that looks like Toy Story, I don't think there are any other
renderers that can handle the kind of scale we're talking about for
75 minutes of rendered imagery.
> I think I remember reading that Pixar even intentionally down played
> the quality of the graphics to make sure people understood that this
> was intended to be a full-length animation that was ALSO 3D.
While we believe that the story is central, and we specifically did not
want to emphasize the CGI nature of the film, don't kid youself into
thinking that we "held anything back". Nobody ever said, that I can
remember, "hey, that scene looks too good, maybe you can make it look
a little worse?" No, we slaved pretty hard on it, and if there are parts
that look like they could be better (and there are), it's worth asking
yourself if maybe there's something there that's a lot harder than one
might think.
> ...Lightwave and virtually impossible for POV Ray. But pick a
> single scene and I think that can be done quite well in either
> package. (For the most part, the motion blurring and some other
> effects that I'm not aware of when watching it might prove
> difficult.)
You've hit the nail on the head -- with your second sentence, anyway.
As they say, the devil is in the details. Making a film-res
animation, artifact-free, with motion blur, depth of field, incredibly
complex texturing, and huge geometric databases, is a really hard
thing. It's largely the subtleties that you *aren't* aware of that
are the hard part, and the parts that very few renderers can pull off.
You don't notice when something antialiases well -- only when it
aliases badly. You don't notice good motion blur -- only bad blur, or
lack of blur. And so on. I really believe that there is only one
renderer that can currently operate on the scale, and at the quality
level, that Toy Story represents.
Look at those neighborhood shots carefully -- how many trimmed NURB
leaves do you think are on all those trees?
-- lg
--
Larry Gritz Pixar Animation Studios
l...@pixar.com Richmond, CA
Alert! Alert! Second-hand marketing information!
>So I'm guessing that a 200MHz Pentium system with say 32 to 64MB of RAM
>could
>render an equivalent scene at 1024x768 in under a day.
Alas, while some frames did take 1-3 hours (though many took an awful
lot longer), very few could have fit in 64Mb memory.
Yes, a 200 MHz Pentium Pro, with at least 128M RAM, running PRMan (and
a *real* operating system) could render most of the frames from Toy
Story. But, duh, that's no surprise, considering that P6 with huge
RAM is about as powerful as the machines we used. But it would need a
lot of memory and disk, and a pretty sophisticated renderer. (And I
don't throw terms like that around lightly.)
>I'm interested to know what you see in the movie that makes you think one
>of the
>scenes (without actively looking for the most difficult) would be so hard
>to duplicate in a reasonable amount of time.
As I said in an earlier message, take a good hard look at (just to
pick a random example) the neighborhood scenes. The RIB files that
described the scenes to the renderer were routinely more than 100
Mbytes *per* *frame*.
The amount of geometric complexity, not to mention the incredible
volume of painted textures, and programmed shaders on absolutely
everything, is mind-boggling. It can't be done with a small machine,
and it can't be done with a toy renderer.
> Now, using POV Ray 3.5 years ago, when they
>probably started Toy Story, and it might have been different.
Sigh.
>I think you exaggerate the quality of the scenes in Toy Story. Yes, it
>is a WONDERFUL picture and yes, the graphics are very good. But I
>believe that almost any of the scenes could be duplicated in Lightwave
>or POV Ray or a number of other products.
>Now, the animation is another story. That's something that I believe
>would be really taxing for Lightwave and virtually impossible for POV
>Ray. But pick a single scene and I think that can be done quite well
>in either package.
Hmmm.
The simple, short answer is that Pixar employed SGIs as animation and
modeling workstations, and a mess of Sun workstations as our RenderFarm.
Software for modeling included Alias, animation was largely proprietary,
rendering by RenderMan. Various sundry jobs were done by either commercial
packages or homegrown tools as expediency and necessity provided.
I can pretty safely say we didn't use Lightwave, and no Amigas were harmed
during production.
>(For the most part, the motion blurring and some
>other effects that I'm not aware of when watching it might prove
>difficult.)
"Having solved the one dimensional case, the 23rd dimensional case
is left as an extension for the motivated reader."
Features such as motion blur, anti-aliasing, and procedural shading are
properly described (IMHO, NTBCWPO**) as enabling technology for film
making. Other film studios appear to agree, although we do have
serious competition out there. I guess all I can say is that we
rendered a lot of very complex frames for Toy Story, and believe me, if
we thought there was a renderer better suited to our purposes, we'd be
buying it. :)
Mark
** In My Humble Opinion, Not To Be Confused With Pixar's Opinion
--
Mark T. VandeWettering Telescope Information (and more)
Email: <ma...@pixar.com> http://webspace.com/markv/
<ma...@webspace.com> Clear Skies!
>Also they "rendered" the scenes, not "ray traced". Not going into the details
>of what each is too much. Rendering typically produces better lighting
>effects, and ray-tracing produces better surface effects (reflection,
>refraction).
Actually, we refer to any program which sucks up geometry and shading
information and produces pixels as a renderer. Pixar's prman product
uses a modified version of the Reyes rendering architecture described
in the proceedings of SIGGRAPH '87. BMRT is another RenderMan compliant
renderer which uses raytracing, and also supports radiosity. Any broad
generalizations about which scheme is "better" are likely to be incorrect.
BMRT can (in somewhat longer time) produce identical lighting to prman,
and being a raytracer, can actually trace refracted, reflected and
shadow rays within the shading language. Pixar's prman cannot do reflection
and refraction "correctly", but often can use convincing reflection maps
in a way that most people find indistinguishable from raytracing.
Mark
>OK, so my 3D modelling experience is very limited, but I've seen plenty
>of fine work from people in this news group that rivals (and even
>surpasses) the scenes in Toy Story.
Please forward their resumes to Pixar Human Resources. We'd be interested
in talking to these people.
>According to Sun, (following the link
>from the Pixar page) each scene was rendered in from 1 to 3 hours of SPARC
>processor time (which I assume to mean the time to render with a single
>processor SPARCStation). Now, they were using dual and quad processor
>100MHz SPARCStation 20's to speed things along, but they rendered 110,000
>scenes for the movie. They didn't give a resolution, but I'm guessing it's
>much higher than 1024x768, which is about as high as I would attempt.
These facts and figures are to my knowledge, roughly correct.
>So I'm guessing that a 200MHz Pentium system with say 32 to 64MB of RAM
>could render an equivalent scene at 1024x768 in under a day.
You are just guessing here. Some of the unknown variables here are:
a) size of typical toy story scenes
b) complexity of shading and lighting in typical scenes
c) antialiasing sampling rate
d) memory per processor on the RenderFarm.
It is not surprising that you don't know these numbers, as we are not
generally at liberty to discuss them. This does make your attempted
analysis more difficult though. I can tell you that if you offered to
replace one of our RenderFarm machines with a machine that had 32M of
memory, you wouldn't make many friends here. :)
>POV Ray supports plenty of lighting modifiers for enhancing the scene.
>If you're not doing collision detection or any animation, you greatly
>simplify what is involved.
We have people to enhance our scenes. And not nearly enough of them. :)
>I'm interested to know what you see in the movie that makes you think
>one of the scenes (without actively looking for the most difficult)
>would be so hard to duplicate in a reasonable amount of time. (Someone
>with good modelling experience -- maybe someone connected with Moray --
>say in about 2 weeks?) I'm guessing you have a copy. Watch it again
>and freeze frame a couple of shots. I'm not trying to give you a hard
>time, I just don't see it as that hard given TODAY's tool set. Now,
>using POV Ray 3.5 years ago, when they probably started Toy Story, and
>it might have been different.
Ummm. Nope. I can't think of a single thing to say about this.
Well, yes and no. Even the area light is composed of multiple
instances of point lights. However, spotlights and area spotlights
project *conically* (although from a single point).
> BTW: I know I spelled various words different ways in different places, I am
> hoping I got them right in at least one place :)
Looks fine from this view <g>.
-- Alan
--------------------------------------------------------------------
"The Wolfman been everywhere and he seen everything....and
here I sit sucking popsicles..." - radio station manager (played
by the late Wolfman Jack, in American Graffiti (1973))
I am talking about a SIMPLE scene, possibly one in the bedroom. As good as
Buzz is for the picture, I don't see him as an amazingly complex character
to model. A VERY complex animation, YES. I do think Woody would be harder
to model. Just look at the hands of each character.
I'm not talking about animating and generating 110,000 frames. I am
talking
about a rendering at about 1024x768, although once modeled, a higher
resolution
is really a matter of time and resources. I know that some of the key
detailing
to the film is the dirt and scuff marks applied to so many different
objects
in the film, including Woody and Buzz in the later half of the film.
I still stand by my belief that a majority of the scenes can be done using
POV Ray
or Lightwave. There may be specific reasons certain techniques are used by
Pixar
that ARE beyond the capabilities of these other programs, but I believe
there is
a sufficient number of tools available in these other programs to come up
with
an alternate way to achieve similar quality results. For example, there is
a scene
on top of the dresser, I think it's sunset, where all the characters are
cast
in a dim, near dark light. Looking at this scene, it appears that this was
done
by changing the color of a primary light source to purple. It's very
effective
in the picture and very possible that Pixar used some more complex lighting
to achieve this effect, but a simple purple light would have resulted in
the
same rendering.
I do appreciate all the responses from Pixar. I know you're not apt to
give away
all your techniques, but I appreciate the additional insight you have
added. I
also didn't mean to indicate that choosing a less realistic rendering of
the scenes
implied that it was any easier to do. I would think that an Impressionist
painting
that took on a more photo-like appearance would not be considered a very
good
Impressionist painting or a very good realistic painting. (Sorry, I forget
the
term for that ultra-realistic painting form that takes on a photo-like
appearance.)
Actually, considering the mix of creative influences to manage, I'm
surprised at
the even level in the result.
One criticism...I believe that the human characters in the picture moved
with a much
more puppet-like motion than most of the toys. I know this is an area of
great
difficulty that has very recently gained some significant advancement, so I
expect
the next attempt will surely surpass those in Toy Story. Though, in
particular, I
see Woody's animation as much more "natural" and "human-like" than those of
the
human characters. That applies to walking and to facial expression.
Personal
opinion, but one that many of my friends agree with.
Now, I'm not certain I know what NURBS are, but aren't they related to
modeling
and not rendering? So if one uses a modeller with NURBS to model something
for the scene, isn't it possible that it can be saved off into a format
convertible to POV?
> > ...Lightwave and virtually impossible for POV Ray. But pick a
> > single scene and I think that can be done quite well in either
> > package. (For the most part, the motion blurring and some other
> > effects that I'm not aware of when watching it might prove
> > difficult.)
>
> You've hit the nail on the head -- with your second sentence, anyway.
> As they say, the devil is in the details. Making a film-res
> animation, artifact-free, with motion blur, depth of field, incredibly
> complex texturing, and huge geometric databases, is a really hard
> thing. It's largely the subtleties that you *aren't* aware of that
> are the hard part, and the parts that very few renderers can pull off.
> You don't notice when something antialiases well -- only when it
> aliases badly. You don't notice good motion blur -- only bad blur, or
> lack of blur. And so on. I really believe that there is only one
> renderer that can currently operate on the scale, and at the quality
> level, that Toy Story represents.
>
> Look at those neighborhood shots carefully -- how many trimmed NURB
> leaves do you think are on all those trees?
>
Now, could POV produce one of the simpler frames thats in Toy Story...
possibly, although it would take many many times longer (there is a
reason that
Alias costs so much money, its the best patch modeller money can buy).
Similarly
when it comes to rendering, Prman is one of the most flexible renders
out there producing the same imagery in POV would take quite a bit
longer both
in time taken to set it up and render time. However, the thing that
Prman
excels over most ray tracers is its ability to cope with huge scenes.
You
are going to need a rediculous amount of memory to render a mildly
complex scene
using POV.
However, prman definately has its problems, and the lack of ray tracing
is one of them, and the lack of an IPR like interface is another. Any
interactive
lighting tool is worth its weight in gold. I think i would even go as
far as saying
that I would prefer a much slower ray tracer with IPR than renderman
with out.
This is especially true when it comes to rendering a movie. Yes the
frame
times can easily add up. But the personel cost of not having people
waiting
around for renders to finish are quite significant, especially when
(with
the cost of the P6's) rendering is becoming so cheap. This also applys
to
the cost of creating a picture. With a ray tracer, reflections, shadows
and refraction come for (almost) free. With Prman, you have to manually
add each in
and tweak them until they "look" right. There is no question that for
quite
a few shots in Toy Story, prman was probably the only way to go
(especally
the outside shots). I think that in the long term, Ray tracers and
Radiosity
combinations (BMRT is a start) are the future. It might be possible to
produce
realistic looking pictures only with prman, but only at the expense of
the people
time to create the picture. The best example of things that prman cannot
do are
correct soft shadows and diffuse reflections (which very few ray tracers
can to either).
Its a mistake to say that these are not important.
As has been said many times before, Toy Story is great because of the
story, and
the talented people that worked on the modelling, animation and
lighting.
I am sure that given a different set of (professional) tools they could
have still created a great movie, but it might have taken longer, and
consequently
might have not been made, and we would be the poorer for it.
Sam.
--
-------------------------------------------------------------
Sam Richards Blue Sky Studios Inc.
Managing Technical Director 2 Macy Road.
914 381 8400 Harrison NY
s...@blueskystudios.com
--
Evan Ruff - CEO Digital Genie
http://www.geniestudio.com
Craig W. Daymon <cwda...@wwa.com> wrote in article
<01bbdfaa$56f2aec0$4e45...@CraigW.Daymon>...
Sigh. "Render" just means "make a picture." There are many rendering
techniques. Ray tracing is one particular rendering technique, though it
happens to be one we did not use for Toy Story.
> I've read about all the leaves on the trees and YES, you did a very nice
> job.
> I know something like that would bring MY system to a crawl.
Hey, it brought our systems to a crawl. I'd be surprised if they could
be
done at all on a lesser machine, or with lesser software.
> I am talking about a SIMPLE scene, possibly one in the bedroom. As good as
> Buzz is for the picture, I don't see him as an amazingly complex character
> to model. A VERY complex animation, YES. I do think Woody would be harder
> to model. Just look at the hands of each character.
This information was published in Computer Graphics World:
Buzz is a computer model amounting to over 34,000 lines of model code.
He has 700 animation controls, and 10 built in lights. He has 189
(yes, 189) texture maps when he is _not_ dirty, and another 450 when
he is scuffed up. Are you beginning to understand the complexity?
You are correct, Woody is even more complicated.
> I'm not talking about animating and generating 110,000 frames. I am
> talking
> about a rendering at about 1024x768, although once modeled, a higher
> resolution
> is really a matter of time and resources. I know that some of the key
> detailing
> to the film is the dirt and scuff marks applied to so many different
> objects
> in the film, including Woody and Buzz in the later half of the film.
There is no gimmick to making believable characters. It starts with
story,
goes through modeling and shading, through animation, lighting and
finally
rendering. Rendering is in many ways the least important of these
steps.
> I still stand by my belief that a majority of the scenes can be done using
> POV Ray
> or Lightwave.
*Sigh*
> There may be specific reasons certain techniques are used by
> Pixar
> that ARE beyond the capabilities of these other programs, but I believe
> there is
> a sufficient number of tools available in these other programs to come up
> with
> an alternate way to achieve similar quality results.
*Sigh*
> For example, there is
> a scene
> on top of the dresser, I think it's sunset, where all the characters are
> cast
> in a dim, near dark light. Looking at this scene, it appears that this was
> done
> by changing the color of a primary light source to purple. It's very
> effective
> in the picture and very possible that Pixar used some more complex lighting
> to achieve this effect, but a simple purple light would have resulted in
> the
> same rendering.
*Sigh*
> Now, I'm not certain I know what NURBS are, but aren't they related to
> modeling
> and not rendering? So if one uses a modeller with NURBS to model something
> for the scene, isn't it possible that it can be saved off into a format
> convertible to POV?
*Sigh*
What you seem to be saying is that:
a) You don't know much about rendering. If you did, you would
at least know what NURBs are, and why they are useful/good
things to support.
b) You haven't worked on generating any scenes which approach the
level of Toy Story (indeed, there is no indication that you have
generated any scenes at all).
c) You somehow still "know" that using free tools that you (someone?
anyone?) can reproduce something as good as Toy Story.
I hesitate to say anything about this, for fear that my remarks might be
construed as self-serving or immodest. Let me merely say that working
alongside
the people at Pixar has given me an appreciation for just how difficult
film
making is.
Toy Story is the result of four years of effort by the exceedingly
talented
and knowledgeable people at Pixar, who I am constantly honored to be
numbered
among. While my own part in Toy Story was relatively small, I do take
great
pride in the work and effort that my coworkers put forth in making what
I view
as a very fine film. In retrospect, I am constantly amazed that the
film
ever got finished at all. Time will tell whether it is viewed as a
pivotal
film, but we know it has been for us. Everyone at Pixar looks forward
to
working on new, exciting projects that bring more of this extraordinary
medium to the public.
Mark
Graphics R&D
So what movie(s) do y'all have in the works?
--
Ewan Grantham 74123...@compuserve.con
12/01/96 22:58
---------
Using: OUI PRO 1.5.0.2 from http://www.dvorak.com
10 years ago, when I was a defense contractor, I remember playing an EGA
graphics
game at lunch with some coworkers. (One of the Sierra On-Line
games...King's Quest
I think.) Another coworker came by and commented on what GREAT graphics
the game
had. Well, even 10 years ago the graphics were NOT great in King's Quest.
Around the same time, I was looking into buying a new computer and was
considering
1 (one) meg of memory. My father, in charge of the flight simulations
department
at the Navy's centrifuge installation, told me he had talked to the
computer
brains he worked with and said I would NEVER need more than 640K.
I don't know how many computer business people I have said to in the last
10 years
that the graphics and sound capabilities of a home system need to match, if
not
exceed those of business systems. Now, finally, the industry seems to be
seeing
this as something that makes sense. After all, it's at home that
educational
programs need to keep a child's interest and good sound is certainly more
of
an annoyance than a benefit in a crowded office.
And certainly there are industries where sound and graphics must surpass
those
(probably lead) of home systems. I'm guessing, but I can't think of any
need
to plug sound cards into the rendering farm at Pixar.
I just refuse to hold to the defeatist attitude when it comes to what can
be done
with a computer. I've read enough of the messages here to know that the
people following this and working with POV (and Lightwave) know what it
takes
to create complex scenes with these tools. There's even a fair number
using
POV on SPARCStations. I haven't been talking about doing what Pixar did
today,
I'm talking about doing 1/110,000 of what they did 4 years ago.
Finally, I think Pixar is a GREAT company. I think they lead in this area.
I
think Toy Story is one of the very BEST pictures I have seen in quite a few
years. I like the idea that the story has appeal to both children as well
as adults. I LOVE the animation, the characters and even the closing Pixar
logo when Lexo Jr. comes out and stomps on the "i" in Pixar.
I'm sure whatever follows from Pixar will be something I'll run to see as
soon
as it is out and I'm sure it will once again push the envelope of what can
be done with computer graphics and animation.
Sorry if I hurt anyone's feelings. I hope all the negatives thrown out
here
won't stop anyone from giving it a shot.
Sam Richards <s...@blueskyprod.com> wrote in article
<32A1D48E...@blueskystudios.com>...
> As I said in an earlier message, take a good hard look at (just to
> pick a random example) the neighborhood scenes. The RIB files that
> described the scenes to the renderer were routinely more than 100
> Mbytes *per* *frame*.
I can believe it. That scene looked absolutely REAL.
_____________________________________________________________________
Steve Sloan E-mail: sl...@geosim.msfc.nasa.gov
Senior in Computer Science at the University of Alabama in Huntsville
Check out Kithrup.JPG on MY NEW WEB SITE (I'm so excited):
http://www.cs.uah.edu/cs/students/ssloan/
> c) You somehow still "know" that using free tools that you (someone?
> anyone?) can reproduce something as good as Toy Story.
--
I hesitate to jump into this debate considering the
participation of two of Pixar's notables (Mark and Larry (Hi Larry)),
but I would like to note that I suspect that the real difference
between Toy Story and many lesser attempts is probably in the
experience and devotion of the Pixar staff than in the rendering tools
used.
Prman is a good rendering tool. But there are a number of
"free tools" that can match it for quality and / or speed and / or
capacity. (Please note that I am also defending prman against
Mr. Boucher's (sp?) (from Digital Domain) attacks in the Lightwave
group). If any "free" tool is not going to compare it would be the
modeling tools.
I agree that the challenge to "reproduce" any one frame of
Toy Story (even at lower rez) is probably not do-able. Though I suspect
that its difficulty arises not from the capabilities of the tools
so much as the capabilities of the artists that wrote, modeled, and
rendered the originals.
But, as to Mark's qualification of all such tools as "toys" -
I suspect that that statement does not recognize nor respect the
tremendous effort, skill, and craft that has gone into some of the
"free" tool sets. I have pumped 100+ Meg scenes through Rayshade
(only slightly modified) on a number of occasions, run it across render
farms, and banged on it unmercifully - and it served faithfully. There
are POV'ers that will testify similarly. There is a scan-line
procedural renderer called "sipp" that seems to be able to keep going
under any level of complexity or scene size - right up to the
capacity of the box it is on - and it does so quickly (no raytrace).
I have great respect for prman (and BMRT for that matter), but
lets not confuse the tools for the craftsman. And at the same time, I
want to give the toolmakers, who toil away for little more than their
own satisfaction, the credit they deserve.
Mark Lasersohn
Cow House Productions
la...@cowhouse.com
http://www.cowhouse.com
330-569-7492
Jon
>
> Look at those neighborhood shots carefully -- how many trimmed NURB
> leaves do you think are on all those trees?
>
BTW: Are you guys looking for any modellers with MAX experience?:)
Jon
Sam Richards <s...@blueskyprod.com> wrote in article
<32A1D48E...@blueskystudios.com>...
There are certainly many excellent free tools (and commercial tools)
available for rendering. I think that you misread Mark if you thought he
was putting down free renderers (particularly given that he wrote one of
the first (the first?) ray tracers freely available on the net.) Prman is
an excellent renderer that, in many ways, produces extremely high quality
imagery of hihgly complex scenes in a reasonable amount of time and
memory. Highly complex means tens of millions of primitives.
I'd suggest that you thoroughly understand how anti-aliasing works in the
REYES algorithm before weighing in about how the quality of other renderers
compared to prman. In particular:
o How textures are anti-aliased in REYES
o How geometry shading and pixel sampling are decoupled, and
the ramifications of this, in terms of how cheaply many samples
can be taken in a pixel.
I'd love to hear about a free tool that does either as well as prman.
-matt
--
Matt Pharr | m...@lux.stanford.edu | <URL:http://www-graphics.stanford.edu/~mmp>
--
Matt,
Your response was an interesting mix of intelligence and
condescension. I am a long time user of both a multitude of free
and "pro" renderers (including prman - for a number of years now).
I have been in the "biz" for almost twelve years, and I am quite
aware of the capabilities and inabilities of both prman and the
REYES algorithm.
Take note, now - as you did not earlier, that I was
very careful in how I worded my response, allowing that the quality
is often a trade off for speed, as the capacity may well be a trade
off for quality (basic physics).
You can, of course, pull certain abilities (such as high speed,
high capacity antialiasing) from one renderer and point it out as
a short coming in another. I may well point to Radiance and ask how
difficult it may well be to present a mathematically accurate portrayal
of light in any other method.
Quality, is (and will remain) a matter of taste. Mr. Boucher
from Digital Domain, recently complained about the similarities
(blandness) of rendering produced by prman in several notable films
of late. In his taste, they are poor quality. One could say the same
for any of the algorithms out there.
Please, before you make more "suggestions" consider that this
is hardly rocket science. The basis for all of these methods have
been in the works for a couple of decades now, and each has its
advantages and disadvantages. I merely intended to point out that
it is often (if not always) the artist at the wheel that makes the
difference, and rarely (if not never) the tools used.
As to your mistatement that I had misread Mark's statements,
I was merely reacting to the fact that he had (probably in some anger)
called "free" renderers "toys". You will note that I also agreed with
Mark that reproducing even a single frame of Toy Story using anything
other than Pixar (the people and the tools) was foolhardy at best.
Again, insulting at best, your statement that "complex means
tens of millions of primitives" - please, give me a break. I know
what complex means. As I stated, I have pushed scenes well into
the 100s of Megs.
On a much lighter note, I am looking forward to seeing
"toro." Will there be a public release?
Absolutely true. But we couldn't have done as good a job without
the technology. The renderer didn't write the story, but it did
make it possible to create the imagery.
> Prman is a good rendering tool. But there are a number of
>"free tools" that can match it for quality and / or speed and / or
>capacity.
>...
> But, as to Mark's qualification of all such tools as "toys" -
>I suspect that that statement does not recognize nor respect the
>tremendous effort, skill, and craft that has gone into some of the
>"free" tool sets. I have pumped 100+ Meg scenes through Rayshade
>(only slightly modified) on a number of occasions, run it across render
>farms, and banged on it unmercifully -
What can I say? One person's unmerciful banging is another person's
simple test scene.
Here's an experiment you can all do at home, with your favorite
free renderer, or even your favorite commercial renderer.
1. Make a scene with a single plastic sphere. How long does it take
to render? Now put a texture map on the sphere and render it.
How long? (I think it should take less than twice the time it took
to render without the texture map.)
2. Make a scene with 100 plastic spheres and render. How much longer
than the one sphere case? It should be sublinear, so maybe it'll take
2, 5, or 10 times longer than the one-sphere case?
3. Now put a *different* 2k x 2k texture map on each of the 100
spheres. How long does it take to render? How did it scale -- in
other words, is the ratio of this time to the 1 texmap sphere time
comparable to the 100 plastic to 1 plastic ratio? Was your
renderer able to finish at all, when you used 100 different 2k x 2k
texture maps?
It's the response to situations like this that distinguish toys from
robust systems. One hundred spheres is a childlishly simple geometric
database, and one hundred 2k textures is not out of line for a feature
film frame. The difference between toys and systems are how they deal
with data management tasks, and how they scale with complexity.
Since you mentioned RayShade, which is a fine program -- Craig?
Are you out there? Wish to add your $0.02?
I think that Mark and I are, if anything, biased quite a bit in favor
of free tools. We've both made fairly big contributions in this area.
But hey, we're realistic, too. We have no particular axes to grid,
except that we're rather hung up on people getting the facts right.
There's a lot of speculation out there by people who've never even
tried to push a renderer to the extent that we're talking about.
Again w.r.t. NURBS, why DID you model the leaves with NURBS? It would not
appear
that as much work went into the car. Maybe it was just an exercise in
technology
that would prove beneficial in the future, but the benefits in the scene
driving
down the neighborhood are lost to me.
Have things really improved so little in 4 years (which I consider pretty
much
near the end of a lifetime for a personal computer -- or at least severe
middle age)
that we are not capable of producing one of the scenes? I'll tell you the
'57
Chevy and the T-bird on Keith Rule's page beat any of the cars in Toy
Story.
(They wouldn't look right in the film, but I'm certainly more impressed
with
the effort.) If you think about it, the semi at the gas station jumps out
with
MUCH more detail than the family car. The Pizza Planet truck has good
detail
on the inside, but I'm not comparing insides right now.
During the years I worked defense contracting, my father replaced the
display
system in the centrifuge. (I think it was about 7 years old then.) The
system
he replaced it with outperformed the previous system in every way. The
original
system cost over $1,000,000. The new system cost closer to $100,000.
I'd like to see someone try and make a Buzz Lightyear model for POV. I
think it
can be done. Some blob work for the face. The fingers to me look like
cylinders
with sphere tips. (That's not to say they are, but who care what they
really are
if they appear to everyone that views them to be equivalent to something
simpler.)
OK, we'll call him something else and maybe make him a different color.
How about
Suds DarkBeer? Make him brown, give the helmet a gold glint like the real
astronauts.
Might be a good logo for a microbrew? I'd buy a six.
Now the wonderful expression work in the animation of Buzz, I don't want to
even
attempt to try that. Again, it is a WONDERFUL picture with a TON of great
work
and creativity put into it. We're not talking about starting from scratch
with
this, we have your TREMENDOUS efforts to guide us. This was never intended
to
in any way diminish the grandeur of your accomplishment in making this
film.
(Why do I keep seeing that picture of Slink talking to Woody and Mr. Potato
Head
in the background.) I am sincere in this though and I hope you will
consider
any effort made a tribute. I certainly would mean it to be.
Personally, I get a great deal of artistic satisfaction from working on
these
3D scenes. I particularly like the combined creativity necessary to
visualize
a complex scene as a composite of primitives and then to describe it in a
text
format. I consider it a logic puzzle to be able to write the text that
will
render correctly the first time. If I'm expecting the scene to produce the
results I'm looking for, I'll keep the machine up for a week to finish
rendering it.
My current scene, and yes basically my first REAL scene, is a tribute to
Jimmy Stewart. The scene is viewed from within "Harvey's Hot Eats" and
across the street is Stewart's Hardware, who's front window I will fill
with memorabilia of Jimmy Stewart. (His father owned a hardware store
in Indiana, Pennsylvania.) I'm thinking of making Harvey's patrons
large white rabbits. This all started with making a glass water pitcher
to learn about CSG operations. Aside from the text on the windows,
which I used Micrografx's PhotoMagic to create the GIFs, everything
is VERY basic POV code.
A side project is to figure out the mathematics of a 3 strand braid
in order to model a piece of primitive sculpture I did about a year back
that includes some braided steel wire. I'm hoping that once resolved
it will be easily expanded into multiple strands and I'll give the
code to Michael D Johnson for his POV utilities page.
Sorry for the long message. I hope there are some folks out there
with thoughts to take on what now seems a pretty grand challenge.
Who knows, maybe they'll be making job offers if someone can do
a good job using these stone knives we have here?
Larry Gritz <l...@pixar.com> wrote in article <5859r8$i...@miwok.nbn.com>...
--
Larry,
How are you? Strange argument in the raytracing group. I have
not seen your response to my response yet, except as quoted by the
original poster (Craig W. Daymon). It seems odd to me that I posted
a conciliatory statement wherein I was attempting to demonstrate
why it would be impossible for Mr. Daymon (an admitted beginner) to
duplicate even a single frame of Toy Story, and I've been lectured
to by grad students (Matt Pharr - works with Craig Kolb, by the way)
and praised by POV'ers for standing up for them. My main argument
is that it would be impossible, not because of the tools used - after
all there are alternatives of many sorts with many advantages and
disadvantages (that we can debate forever), but rather because of the
skill and experience built into Pixar (the people and the software).
It is the combination of the two that really makes the difference.
I still contend that should we be able to find enough people
with the same experience level (20+ years, E&S, Stellar, Stardent,
SGI, Alias, Pixar, Cornell, Princeton, Berkeley, MIT, etc...), put
them together for 5 years with enough money and horsepower to sustain
them - give them just about any software with the proviso that they
can alter it as needed, they would produce a real nice movie. It, of
course wouldn't be Toy Story, but it might well be as good.
The fact is that Pixar *DID* that, with splendid results. The
facts are that Craig Daymon cannot do that (unless he is the soon
to be acknowleged son of Bill Gates, and even then money without
talent won't pull it off.)
[Sorry Craig D. - I don't mean to say that you are untalented,
but rather that you don't have a team of extremely talented people
to support your efforts]
As to your response about rendering spheres. My "favorite"
rendering package is IrisPerformer, and most of the work I do is
interactive (so the point is almost moot), where we are very sensitive
to capacities. I have, on the other hand, put together "rendered"
images well into to Toy Story complexity level for product
illustrations (I work out in the industrial heartland) of process
plants (100s of Megs).
In the industrial simulation business there is substantial
awareness of complexity level because, after all - these thing actually
have to be built. But, I suspect that my definition of complexity
is not very different from yours. I measure scenes into the 100s of
Megs often (and unhappily) just like any one else.
But, because the original argument was stated by Craig as
a single frame at low rez in any amount of time - the capacity and
speed of prman are not really relevant to the argument. If a "toy"
renderer can complete the task at all, it has met the original
criteria. Truly, it really becomes a hardware and OS issue. Lets say
Craig is supplied with prman and one of the original scene descriptions,
with original shaders, etc... He still could not render it - because
he does not have the physical capacity at his facility. Nor would he
were he using any of the other alternatives. Sipp, might pull it off,
because it is merely an API and can be customized (therefore) to
work with a data stream (it is also very REYES-like), rather than using
chunks of coherent (too large to fit in a PC) data. But even that is
somewhat doubtful.
So performance scaling may seperate the "toys" from the "boys"
but it is not the issue. The real issue, as I see it, is: "Can Craig
Daymon produce a single (reasonably complex) frame from Toy Story?"
We are all in agreement (except for Craig) that he cannot. If we
elaborate, and ask why he cannot - I would answer, because he is not
Pixar and cannot afford to hire Pixar. Could Pixar produce a reasonably
complex frame from Toy Story using something other than prman?
Of course, it would take time effort and money, but yes Pixar could
do that. If prman was the singular linch-pin of Toy Story's success,
there would be hundred of Toy Stories, maybe thousands - there
are not.
> My current scene, and yes basically my first REAL scene,
> is a tribute to Jimmy Stewart. The scene is viewed from
> within "Harvey's Hot Eats" and across the street is Stewart's
> Hardware, who's front window I will fill with memorabilia of
> Jimmy Stewart. (His father owned a hardware store in Indiana,
> Pennsylvania.) I'm thinking of making Harvey's patrons large
> white rabbits.
How do you model rabbits with CSG and primitives? It sounds nearly
impossible.
Steve Sloan <sl...@mapsrus.msfc.nasa.gov> wrote in article
<32A6FE...@mapsrus.msfc.nasa.gov>...
A number of years ago there was a laserdisc based video
game called DungeonQuest (I really can't remember the title).
It was a collection of canned animations that the game hardware
selected from in response to player moves. It was a novelty
that lost its appeal because of the limited combinations of
strung-together story elements.
Is there hardware (and software) available (or in development)
that would allow a revisit to that style of graphic product?
Any way this could apply to a theater setting?
des
--
email address spoofed in order to be cruel to UCE spammers
Yup--good point, and sorry for being awfully rude and condescending
before. Many of the postings to this thread have been trying to compare
renderers without even trying to have any basis in facts, which is sort of
frustrating to watch. Sorry for venting that at you, Mark.
Other than Radiance (it's another nice example of making a set of decisions
about what's most important up front--in this case, simulation of complex
illumination), I still don't think any freely available renderers come
close to matching RenderMan's quality. Reyes makes an interesting set of
trade-offs that lead to some really neat things falling out (like great
anti-aliasing), other renderers make other trade-offs to good effect. The
fact that a lot of this thread hasn't had much substantial discussion of
these trade-offs and has mostly been "PoV is just as good and if you
disagree, you're being disrespectful to the folks who have worked hard on
PoV for years" is too bad.
Something is wrong here. POV does not take NURBS as input at all. So
if you can indeed follow the path of Rhino->3DS->POV as you describe,
it must get converted somewhere along the way to a geometric primitive
type that POV can handle. Most likely *lots* of polygons, since there
is no obvious other alternative to NURBS.
>Again w.r.t. NURBS, why DID you model the leaves with NURBS?
Why not? Somebody else asked why we modeled the leaves with something
so expensive.
NURBS are *NOT* expensive in PRMan. That's the whole point of this
thread. PRMan was designed with different goals, and as a result it
has very different performance characteristics than most other
renderers. NURBS are incredibly cheap in PRMan, and since a trimmed
NURB is a convenient description for a leaf, that's what we used.
>Have things really improved so little in 4 years
You have many times brought up the "Toy Story was made 4 years ago, so
surely everybody else has caught up." First mistake: Toy Story
rendering is much more recent than that. Four years ago, TS was in
story development. I think it's fair to say that by far the majority
of final frames for TS were rendered in the last 6-9 months of
production (i.e. less than 2 years ago), and we were continually
improving it as production progressed. The current commercial release
of PRMan is the one we were using for Toy Story. (So internally,
we're even much farther ahead of that now.)
And yes, I really am saying that in spite of steady improvements in
other renderers, they still have very different characteristics from the
renderers we use, in ways that would make replication of Toy Story
very diffucult.
A brand new Cessna still has different performance characteristics
than an old 747. The Cessna is a fine plane, and I'm sure lots of fun
to fly, but it simply will not transport 200 people from continent to
continent, and never will with its current design.
Oops, perhaps you thought I was talking about you, here:
>> Since you mentioned RayShade, which is a fine program -- Craig?
>> Are you out there? Wish to add your $0.02?
Sorry, I meant Craig Kolb, author of RayShade.
One question I have about things like Toy Story and other animated
scenes is, since it is a movie, two consecutive frames will often be
"similar". What is the current state-of-the-art on taking advantage on
that (theoretical/practical). Is it possible and worthwile to reuse
data, or does every frame have to be calculated from scratch?
Abigail
Ric Wilson rwi...@boi.hp.com
--------------------------------------------------------------------
Computing & Technical Services - Boise /_/\ __ / /\
Hewlett Packard \ \ \/ /\ / / \
11311 Chinden Blvd. \ \ \/ \ / / /\ \
Boise, ID 83714 \ \ /\ \\ \ \/ /
\ \ \_\/ \ \ \/
\ \ \ \ \ \
\_\/ \ \ \
\_\/
Fascinating thread. It's nice to see Pixar people getting involved.
Larry, you said RIB files of over 100mb. Amazing. What file size are we
talking about for a complex rendered frame, and at what resolution were they
rendered at? (Forgive me for coming in on this late; I imagine this has been
discussed before.)
BTW, I agree with you fully. Nothing comes close to PRMan for rendering,
although that BMRT "marking pens" image has great image quality/realism. If I
wasn't too lazy to learn Linux, I'd get into BMRT.
Cheers,
David Braun brau...@hooked.net
David Braun Photography
Specializing in groups of all sizes--Conferences/Special Events,
Corporate/Industrial, Editorial, P. R. (415) 738-9100
<many many posts deleted>
I have been following this thread since it began. It has proved to be
very interesting. If you will however, please explain something to me
that is probably something basic. I am a relative newbie, so bear with me.
There has been much discussion on how POVRay could be used to render
images of like quality to those found in Toy Story. Larry Gritz
responded with an authoritative NO. He then went on to say that POVRay
could not handle the tasks necessary to generate such images. This is
the part that puzzles me. If someone could provide me with a more
detailed explanation of WHY prman can handle this process and why POVRay
or other Raytracer cannot, I would really appreciate it. Is it because
prman has been coded to handle all sorts of incredible effects,
something that other products lack? Is it because the structure of a POV
file simply cannot handle something so complex? Is a significantly
different rendering engine used? What?
I am trying to understand why some rendering systems are better than
others, and what makes an obviously excellent rendering system like prman
so excellent. Any explanations would really be helpful. Thanks in advance.
Peter
I think the discussion has been a little misleading.
POV _can_ generate images of the quality like that found in Toy Story.
The problem lies in one major missing feature (motion blur) and with
resource usage.
POV is actually very efficient when it comes to rendering finite
primitives. If all the objects in your world are defined using CSG
ops on spheres, boxes, blobs, etc., then your scene will not take
up much memory.
But when you are talking about an animation on the scale of Toy Story,
with millions of objects per scene, POV chokes. The POV designers
simply didn't design their program to scale well when rendering very
large scenes, something that prman was built from the start to handle
[I assume]. With ~100MB of input data in a scene, that could easily
translate into 400MB or 600MB of memory used by POV. While high
powered rendering stations usually have this kind of memory, most
POV rendering stations are far less capable.
That's just resource usage. If we assume for a second that POV could
handle the large geometric databases used in Toy Story, then yes, POV
could generate images of that quality requires. Some textures may need
to be mapped externally, sure. POV can do it, and make it look nice.
I could not have made this claim about POV v2.2, but the new v3.0 adds a
lot of powerful features.
Jeff
--
Jeff Garzik Spinne, Inc.
jeff....@spinne.com http://www.spinne.com/
State-of-the-art efficient systems for Unix and the Internet.
One possibility for a future version of POV, for handling
way huge scene files:
Swap the roles of object and ray. Treat each ray as a list of
intersection-points, and create a list of "empty" primary rays.
Now iterate over the objects in the scene, loading each one into
memory, testing it against all the rays and saving intersections,
spawning secondary rays, etc. After the object is tested against
all currently existing rays, deallocate it and load another one.
Continue until all objects have been tested against all primary
and secondary rays...
Sure, it'd be slower, since you'd have to load each object many
times for yet-another-pass of secondary ray tests; but in theory
it could handle -any- scene complexity, so long as no one object
was too big to fit into memory, and so long as the hard disk did
not full up with temporary ray-intersection files.
Other benefits:
- works better for distributed traces; just assign each host
a few scene objects, then pass the host rays and have it
pass back intersections and new secondary rays. This should
use much less bandwidth than passing scene objects around.
- you could add objects in mid-trace; just append them to the
end of the list of objects, and they'll get traced later.
- you could remove objects in mid-trace: go through the list
of rays, and remove all intersections with the object plus
any rays spawned from those intersections.
- if you kept the completed ray-tree around, you could edit
textures and colors interactively after you get the geometry
modelled and traced.
Comments, criticism?
.----------------------------.
| lpurple at netcom dot com |
'----------------------------'
>That and the experience of the people at Pixar was regarded as one of
>the main reasons why someone else using POV or any other renderer
>could not do the same thing.
Hmmmm... that's kinda blunt. Is that entirely true? Sure it would be
extremely difficult and probably impracticle to trace a movie like
toy-story in POV (and without motion blur it wouldn't turn out as
good). But "any other renderer"????? That's a bit biased, don't you
think. Is prman really THAT good? And are the people at Pixar that
much better than other 3D graphic artists? (What about those guys at
ILM?) Generalization of this magnitude has the potential to generate
extremely nasty flames. ;)
>And because of its technical superiority: antialiasing, motion blur,
>trimmed NURBS, procedural shading, effective memory usage, speeeeeed.
These are definatly features missing from POV. I can't argue with
that. Hopefully in the future.... ;)
>Try this in POV: take a map in polar coordinates as a texture and map
>it to a hemisphere or any type of (quasi-rectangular) patch. This is
>extremely simple in renderman (and it does antialiasing on the texture
>by default), look at my example:
>http://www.math.uni-hamburg.de/home/hars/rman/kalotte.html
The first part is child's play in POV-Ray. Just create a hemisphere
(CSG of sphere-cube) and map the image to it using planar mapping.
(Bilinear interpolation is available , as is Normalized
interpolation.) Unfortunately, that's where POV-Ray stops. Image
maps in POV cannot follow the contour of patches (bezier or triangle
meshes). Once again, this is on my wish list for POV 4.0.
Until then, I've got to get myself a copy of Linux and BMRT.
-Nathan Kopp
nk...@grfn.org
http://www.grfn.org/~nkopp/
You misunderstand. "Scanline vs. raytracing" refers to the method
of scan conversion, or hidden surface removal.
Rather than having a simplistic lighting model, PRMan (and in fact
any RenderMan-compliant renderer) has a *completely programmable*
local illumination model. And believe me, we program some absurdly
complex surface and light properties which just can't be done in
most other renderers.
>If you were to use pov in toystory it
>would in fact look better (I'd gather) because it has more realistic
>lighting. But I could be completely
>wrong here.
Yep, indeed, completely wrong.
>Just as a guide take a close look at the shadows cast in ToyStory,
>they're all
>very definite and are almost always cast in one direction only.
Huh? I don't even know where to being here. Try looking again --
there are practically no sharp shadows in Toy Story; we tried very
hard to have everything relatively soft.
>Well pov can definately handle scenes as complex as those in ToyStory.
>POV
>has no limits on data sizes that I know of.
The obvious limit is the size of memory! The question is, how big a
scene swamps your memory, and how how well does the renderer handle
the situation when that happens? In the case of PRMan, it takes a
*huge* scene to bring it to its knees, in fact much much larger than
it would take to kill most other renderers, including, I'm willing to
bet, POV.
>modeled using some fantastic modeler and rendered using prman. They
>could have
>just as easily used POV or Rayshade or anything else they wanted.
I assure you this is simply not true.
>> I am trying to understand why some rendering systems are better than
>> others, and what makes an obviously excellent rendering system like prman
>> so excellent. Any explanations would really be helpful. Thanks in advance.
>
>I think the thing that makes one renderer stand out over another is it's
>popularity? maybe ?
No, though this is a big reason why POV is so highly regarded (and
also because it's free). I'm not knocking POV -- it's good at what it
tries to do. But there are very real reasons why other renderers are
better suited to production, and there are specific features which
POV, and to be fair, most renderers in the world, lack.
Here is an assortment of things which we consider very important:
* Robust antialiasing, including motion blur. Even without motion
blur, most renderers' antialiasing is prone to various subtle artifacts.
* Support of useful primitives -- most high end modeling (say, from
Alias) is done with trimmed NURBS and bicubic patch meshes. POV
supports neither NURBS nor rational bicubic patches *at all*. PRMan
not only supports these, but they're damn *cheap* to use. NURBS
are not expensive!
* Texture filtering and cacheing. What happens when your renderer
gets a scene which needs 200 different textures, each one of which is
4000x4000 pixels? Does it try to read them all into memory, and die?
Does it use a sophisticated tiling and caching scheme so that no
matter how many textures you use, only 10-20 Mbytes will be used to
store them, efficiently paging pieces of texture in and out as they
are needed?
* Programmable shading. Do you choose one of a handful (or even a
bunch) of surface and light types hard-coded into the renderer? Or
can you write arbitrary programs to control surface appearance,
bumpiness, reflection model, energy distribution of light lights, and
volume attenuation? Can you write these programs in a special language
designed specifically to make this easy? We write custom shaders
at the drop of a hat, for basically every object.
* When you animate something using deformations (e.g. faces), you want
to have texture move along with the warping surface, rather than
smearing and moving on the surface (which looks really bad).
RenderMan allows you to attach *arbitrary* data to vertices of a mesh,
which is automatically interpolated and made available to shaders. We
use this feature to attach "reference meshes" which record the
"neutral position" of an object undergoing deformations, so the
shading is performed using the reference positions. This ability to
have reference neutral-pose meshes is critical to high end rendering
for animation, and is lacking entirely in most renderers.
There are many more features like these, which are not obviously
important, *until* you actually are making large scale high quality
animation. There *really* *are* features which some renderers lack,
and other renderers have.
> One possibility for a future version of POV, for handling
> way huge scene files:
> Swap the roles of object and ray. Treat each ray as a list of
> intersection-points, and create a list of "empty" primary rays.
> Now iterate over the objects in the scene, loading each one into
> memory, testing it against all the rays and saving intersections,
> spawning secondary rays, etc. After the object is tested against
> all currently existing rays, deallocate it and load another one.
> Continue until all objects have been tested against all primary
> and secondary rays...
Sir,
This is an interesting idea, but I think that it ignores the need to
order the objects (surfaces) w.r.t. the propagation of the rays. Scene
descriptions cannot efficiently be organized or indexed to reflect these
relationships, which are potentially different for each primary ray,
each reflected / refracted ray and each light source.
It seems to me that ray-tracing requires random access to the scene
description.
Is this naive? Are there tricky ways to make such a scheme work?
Randy Schulz
--
rrsc...@cris.com
... ride eat sleep ... ride eat sleep ... ride eat sleep ...
RenderMan is also great, and the BMRT are free too!
man, what a great world we live in :)
Although RMan has some definate advantages over POV (not the
least of which is speed) it is harder to get away form that
3D-studio-like "plastic" look in RenderMan. Maybe I'm just not
modifying the deafult shaders enough, but look at Toy Story...
I can't help but think how much more "non-CG" it would have liiked if
some of POV's raytracing code had been some-how incorporated into
PRman..
Of cource, it would probally STILL be rendering.... :)
Each piece of software is a great thing to have in anyone's bag
of tricks!
Hey, here's an idea, anyone up for a c.g.r.r reader contributed movie?
we each get say 30 seconds or so in which we display our own animations.
Smoothing them together would be accomplished by some simple information
about the animation (and a simple Primere fade to) ie: "blue background,
object enters middle of screen atg right, leaves scene in upper right
hand corner. object largely black and about 10% of screen area."
That would be enough for me to design somehting, starting with a blue
sky, maybe timelapseing to night, with the sun initially entering
upper-right corner, descending to the horizion, then the stars slowly
falling into a black-hole liek point source gravity just at the edge of
the lower left of the screen, leaving ripples in the water......
I couldn't take on the compostiing of the film, (no Primere, no Wintel
box, even!) but there must be somebody out there with Primere, and 5 or
6 GB free on a fast RAID... :)
--
| As I sat there, the light changed from red, to |
| green, to yellow, to red again. Was life nothing |
| more than a whole bunch of honking and yelling? |
| Sometimes it seemed that way. |
~~~> http://artherd.wco.com <~~~
Wait....I forgot about the money.
I bet if you poured millions of dollars into POV, and charged an arm and a
leg to anyone who wanted to use it legally, and wrote different renderers
to produce faster results, etc., you could produce animations that put Toy
Story to shame. But what would be left for those of us who do this as a
hobby?
Renderman has one HUGE disadvantage for my purposes: I can't afford it.
Where is the freely distributable Renderman package? So I'll stick with
POV which I still enjoy using more than TrueSpace and RayDream Studio
(both of which I own). No one I deal with on a daily basis knows what a
NURB is. They're still impressed by an SOR.
It's becoming clear that Renderman has some definite advantages over POV.
True.
I think I'll throw my old POV in the garbage and jump on the Renderman
bandwagon.
Don't throw your POV away, just add a Renderman-compliant renderer to your
toolbox. They're both useful tools.
Renderman has one HUGE disadvantage for my purposes: I can't afford it.
Where is the freely distributable Renderman package?
It's called BMRT (the Blue Moon Rendering Tools), and it's available for
download at "http://www.seas.gwu.edu/student/gritz/bmrt.html". It's free for
personal use, and dirt cheap for businesses. It only runs under Unix, though,
so if you don't already have it, you'll need to get one of the free Unix
clones (I recommend Linux) also. Using the package "dilinux", DOS/Win users
can install Linux using as little as 20mb of disk space, without reformatting.
I think the Mac also has a Renderman implementation, not free but fairly
reasonably priced. Not sure about that one, though.
No one I deal with on a daily basis knows what a NURB is. They're still
impressed by an SOR.
You need to get a better modeller, then. NURBS are cool. Unfortunately, I
don't know of any free modellers for Unix which do NURBS. Yet. <grin>
--
Chip
> Where is the freely distributable Renderman package?
>
>It's called BMRT (the Blue Moon Rendering Tools), and it's available for
>download at "http://www.seas.gwu.edu/student/gritz/bmrt.html". It's free
> ..........
>clones (I recommend Linux) also. Using the package "dilinux", DOS/Win
users
>can install Linux using as little as 20mb of disk space, without
reformatting.
Well flip me, I'll check that out then!! One question though, is 'dilinux'
also free? If so, do you know where it can be gotted from?
____
Mawhin. / + ~ \
---------ooo---O---ooo----------------------------------------------------
-------------
--------------------------------------------------------------------------
-------------------
Mawhin < ---< Proud user of:- POV3, LEX, YACC, DJGPP C,
@ AWK, PERL, LPARSER, and many others......
aol.com < ---< Proud fluent user of:- Windows Write, Solitaire,
Minesweeper, erm.... that's it.
--------------------------------------------------------------------------
--------------------
--------------------------------------------------------------------------
--------------------
> It's called BMRT (the Blue Moon Rendering Tools), and it's available for
> download at "http://www.seas.gwu.edu/student/gritz/bmrt.html".
I've got Linux, and being a POV user, I'd love to try out BMRT. One
question: Where on earth can I get reference material on the RIB file
format? I've looked at RIBS, and they look not to disimilar from the
POV scene description language.
Don't tell me buy the renderman companion, because I've looked at it,
and it's about programming in C using the renderman API, it's not
actually about how to write RIB files from scratch.
I know there are modellers for linux (such as AC3D) that output RIB, but
I don't use a modeller for my raytracings, and don't want to use one.
Until I can find the information I need to code RIB files, BMRT is
useless to me.
Brian
Unfortunately, we're not playing "what-if" here. Renderman has things
now that POV doesn't have, and it will probably always be that way.
>Renderman has one HUGE disadvantage for my purposes: I can't afford it.
>Where is the freely distributable Renderman package?
It's mentioned in the FAQ under BMRT, but in any case, have a look at:
http://www.seas.gwu.edu/student/gritz/bmrt.html
ftp://ftp.gwu.edu/pub/graphics/BMRT/
You may notice at this point that one of the people from Pixar that
has been rather unilaterally inserting facts in this otherwise fact-
free discussion is the author of BMRT. He not only works for Pixar,
but he has written a Renderman compliant ray-tracer/radiosity renderer
that is free for non-commercial use.
>No one I deal with on a daily basis knows what a
>NURB is. They're still impressed by an SOR.
It's not an issue of knowing what a NURB is, but rather what they look
like, and how easy/efficient it is to manipulate them. That's like saying
"nobody I work with knows what anisotropic scattering is, so we don't
need to have fog in this image to make it look good".
Don't get me wrong, I think POV is great, and I spend a lot of my spare
time working on it, but it just isn't designed for the same things that
PRman is, nor does it have all of the capabilities of the Renderman
language. This isn't to say it won't have some (or all) of these features
in the future, but I'm sure that at that time PRman will have yet more
features again.
Cheers, Andreas.
--
Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and
(403) 220-8792 Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
<http://www-mddsp.enel.ucalgary.ca/People/adilger/> hungry?" -- Dogbert
not to offend, but it seems that Larry here is prancing around saying how
much better PRMan is than most other renderers. I don't really think
that we need him to advertise this, as ToyStory itself does a much better
job.
Larry Gritz (l...@pixar.com) wrote:
: Matthew Aldous <ald...@topaz.cqu.edu.au> wrote:
: Rather than having a simplistic lighting model, PRMan (and in fact
: any RenderMan-compliant renderer) has a *completely programmable*
: local illumination model. And believe me, we program some absurdly
: complex surface and light properties which just can't be done in
: most other renderers.
yup. I'm sure it can. now whether it's aesthetically pleasing...
I find myself turned off by a lot of cg artwork. Stuff like 'Reboot,' while
clever, is very ugly to my eye. I much prefer stuff like Starblazers and
Macross for saturday morning cartoons.
: >If you were to use pov in toystory it
: >would in fact look better (I'd gather) because it has more realistic
: >lighting. But I could be completely
: >wrong here.
: Yep, indeed, completely wrong.
I've seen some people do some really _bad_ lighting jobs in PRMan, so
it's not entirely true. You can have killer models and textures etc, but
if your lighting sucks...
: >> I am trying to understand why some rendering systems are better than
: >> others, and what makes an obviously excellent rendering system like prman
: >> so excellent. Any explanations would really be helpful. Thanks in
: No, though this is a big reason why POV is so highly regarded (and
: also because it's free). I'm not knocking POV -- it's good at what it
: tries to do. But there are very real reasons why other renderers are
: better suited to production, and there are specific features which
: POV, and to be fair, most renderers in the world, lack.
I have to agree with Larry on this one.
not to offend any of the Pov devotees out there, but Pov is _NOT_ a
production renderer. If I had to make money doing animation, I simply
don't have the time to tweak a model for hours or days when it can be
easily accomplished in a higher end commercial package. The big problem
that I have with Pov is the lack of nurbs support. It's also quite clumsy
at handling externally composed meshes.
: Here is an assortment of things which we consider very important:
: * Robust antialiasing, including motion blur. Even without motion
: blur, most renderers' antialiasing is prone to various subtle artifacts.
<big snip>
wow Larry, you should be a salesman. You would have sold me a bunch of
licences already!
-Adrian
--
___//L'Adder Noir\\__________________________________ _ _ _
GothCode 1.1 GoEn+ T9 B12Bk c1(7)f-- P7 M+++ a+ n---
b-:- H6'2" g m+ w++ r++ D-~ h+ s10 k+++ R- Ssw LcaON----
__"I have a cunning plan..." -Baldrick_______________ _ _ _
Actually, it doesn't:
$ ldd /opt/BMRT2.3.4/bin/rendrib
statically linked (ELF)
It will *use* X11 if you ask it to, via the "-d" option, but it doesn't
require it.
That having been said, you have a point--I would in fact recommend a
"standard" installation of Linux, including the X window system, which will
take more like 100mb for enough to run BMRT comfortably. The effort needed to
re-partition is worth it. Better still, just buy a new drive and install on
that. In fact, in last week's InfoWorld, Nicholas Petreley described a
company which sells disk drives with Linux pre-installed on them. You plug
the drive in, and off you go!
If anyone cares to write one, there is a NURBS-library available from
the Manchester University Computer Graphics Unit, using it might save
some time. Ask your favourite search engine.
Thanks for the tip!
--
Chip
I'd love to hear Larry or one of the others from Pixar give an answer to
this. I'm willing to bet that their answer will include, somewhere, the
phrase "not intended to be written directly by humans" but I could be wrong.
I've looked at RIBS, and they look not to disimilar from the POV scene
description language.
Yes, the format seems pretty nice, actually.
Don't tell me buy the renderman companion, because I've looked at it,
and it's about programming in C using the renderman API, it's not
actually about how to write RIB files from scratch.
Ouch. I have a copy of the Companion coming in the mail. I wasn't aware that
it didn't document RIB. Dang. On the other hand, I don't intend to write
very much RIB directly myself. But it still would be nice to have some
documentation of the stuff, anyway.
In the BMRT package, there's a *very* short description of some simple parts
of RIB. Further references seem to include a Pixar publication called "The
Renderman Interface, version 3.1 official specification". Larry's text seems
to indicate that it has more details about RIB. I was unable to find anything
that looked like a spec on Pixar's web or ftp sites. I'll bet you have to
write to Pixar.
I know there are modellers for linux (such as AC3D) that output RIB, but
I don't use a modeller for my raytracings, and don't want to use one.
Until I can find the information I need to code RIB files, BMRT is
useless to me.
AC3D, Amapi, and sced all write RIB. It might help to get a modeller, and
read the RIB it produces, at least until you can get some "official"
description of the language. Otherwise, I guess you could write some simple C
code to do whatever calls you wanted, run it, and see what RIB it produced.
--
Chip
Yes, it is, as far as I know.
If so, do you know where it can be gotted from?
A quick web search turned up the fact that dilinux is listed in the Linux
Software Map (http://www.boutell.com/lsm/) as well as having this entry in the
Linux Distribution How-To (the how-to's are available on any Linux
Documentation Project web site--I use http://www.caldera.com/LDP/linux.html
myself):
2.3 DILINUX
Distributor:
Kent Robotti
FTP: ftp://ftp.sunsite.unc.edu/pub/Linux/distributions/dilinux
Provider's Description:
A (D)rop (I)n linux-elf slip/ppp networking system. It can be dropped
into a subdirectory of any DOS system and booted from DOS without messing
with disk partitions. About 22 mbytes unzipped, 8 1/2 mbytes zipped.
Internet Access:
By anonymous ftp from Sunsite archives (see URL above).
Last Freeze Date:
30 Sep 1996
Entry last modified:
8 Oct 1996
Editor's comments:
As the author says, not a general-purpose release. Probably best suited
to sites that primarily run DOS but want better networking tools for hooking
up to an Internet service provider.
--
Chip
PS: I wouldn't necessarily recommend dilinux--I've never used it myself--but
it is an option for people who want to dip their toes into the water without
diving in yet. And I would not recommend downloading it directly from
Sunsite--use one of the many mirror sites instead. On balance, I'd recommend
buying a new disk drive (the 1gb drives are getting *very* cheap these days),
or at least re-partitioning your existing one, and installing Redhat or
Caldera, from CD if you can afford it, from ftp if not. Linux is very much
worth the trouble, and so is BMRT. Happy rendering!
Check out the comp.graphics.rendering.renderman FAQ. The actual
RenderMan Interface 3.1 specification might be what you're looking
for.
>Until I can find the information I need to code RIB files, BMRT is
>useless to me.
"Until I can code PostScript by hand, a PostScript printer is useless
to me."
> Try the Renderman Companion :-).
>
> Yours, Florian.
Doh! :)
Thanks for the info!
--
Linux: Put a penguin in your processor!
http://www.linux.org
> >Until I can find the information I need to code RIB files, BMRT is
> >useless to me.
>
> "Until I can code PostScript by hand, a PostScript printer is useless
> to me."
>
> -- lg
Yes, exactly! :) All those stupid word processing programs are just to
limiting! They get between me and my output! ;)
It's not exactly the same thing. The modellers I've found that output
RIB don't give me enough control, especially over shaders. I've become
used to coding for POVRAY, and to lose that direct connection to what
I'm doing by having a limited modeller get in between me and my image
would be A Very Bad Thing(TM).
Of course, if you wanted to slip me a copy of renderman, perhaps I could
get over my distaste for graphical interfaces. ;)
There's an entire newsgroup about RenderMan and its implementations,
and the FAQ for that newsgroup has pointers to the various format
spec sources.
: > >Until I can find the information I need to code RIB files, BMRT is
: > >useless to me.
: >
: > "Until I can code PostScript by hand, a PostScript printer is useless
: > to me."
: >
: > -- lg
this is hilarious.
: Yes, exactly! :) All those stupid word processing programs are just to
: limiting! They get between me and my output! ;)
: It's not exactly the same thing. The modellers I've found that output
: RIB don't give me enough control, especially over shaders. I've become
: used to coding for POVRAY, and to lose that direct connection to what
: I'm doing by having a limited modeller get in between me and my image
: would be A Very Bad Thing(TM).
ummm, about 2 years ago, when I was in university and couldn't afford a
high powered modelling/rendering program, I used povray2 for some _simple_
renders. You see, that was all that was possible given the time frame I
had to complete a project. Povray was very tedious. It was not long
afterthat I borrowed some money and got a student version of 3ds, and
*wow* did productivity go up for me. What a good idea being able to see
what I was doing, since I use my eyes before when I did my hand
renderings. Call me a silly artist, but I need a graphical interface to
_see_ what I'm working on. Now I work on pro/e and alias. :)