Whom does the pov-team see as the ideal or dream user of povray for the next
five to ten years?

On one hand, I've developed things that allow povray to do pretty cool
things entirely within the program, like gaussinblob.pov,  but if I
understand correctly, it actually caused the povteam some embarassment
among chip-speed benchmarkers for being such a horribly coded piece of
software.   I've been thinking abour releasing some more SDL related to
sound composition, but one of my examples too is horribly inefficient--
each frame has to compute the results of all the ones preceding it-- frame
100 has to caculate the events that happened in frames 1-99 before it can
do its thing.   I'm almost wondering if I'd need to improve it just to meet
coding expert snootiness.

My dream use of povray is actually for movie production.  My character
animation system is completely modular.  I could actually hire artists to
each work separately on the povray-modelled characters, the movement files,
and the scenery and lighting.   But as I work by myself for now ;-)  , I
might typically each night make a few tweaks to each of the model, action,
and scenery files and then just let the computer render the whole 1000
frame set over each day.   *This* particular use of povray, especially the
feature of render a huge anim as you sleep, AFAICS,  would be aided by the
minimization of features that invoke separate Java or C computations,  or
require too much user intervention-- render a still frame, write down some
numbers, render again.


The kind of stuff I make would probably earn a "D" from a compsci prof for
inefficiency.  But we are talking about making increasingly fast computers
do the work for us while we sleep.   On the other hand, just to pick on one
particular case,  I think that Christoph's mechsim patch could in fact make
a very good SIGGRAPH paper.   But I found that some of the features in the
way it was designed prevented it from easy application to my kind of
animation schedule.  Especially if there were cases that required running
once, writing down nubmers, and then doing a long render of an anim.   I
can imagine that this would drive me nuts when I'm doing daily rerenderings
of a long anim over the course of a month, and there were at least weekly
changes as to what exactly was interacting with the mechsim bouncy ball.


In any case, I might be near to releasing two different things, and I'm
wondering if we ought to come to some kind of consensus, or perhaps more
interestingly, the pov-team ought to make a decree,  as to what would make
a good quality of a widely-used inc.  In part I believe it has to do with
whom we and the pov-team wish were using 5.0-- and hey my kind of use might
be completely irrelevant to the big pic.

Greg M. Johnson

Post a reply to this message

gregjohn wrote:
> Whom does the pov-team see as the ideal or dream user of povray for the next
> five to ten years?

Ones who don't ask such questions... ;-)

Now seriously, it's still that users choose POV-Ray and not POV-Ray that 
chooses its users although by designing POV-Ray in a certain way we of 
course aim at a certain group of people.

> On one hand, I've developed things that allow povray to do pretty cool
> things entirely within the program, like gaussinblob.pov,  but if I
> understand correctly, it actually caused the povteam some embarassment
> among chip-speed benchmarkers for being such a horribly coded piece of
> software.   I've been thinking abour releasing some more SDL related to
> sound composition, but one of my examples too is horribly inefficient--
> each frame has to compute the results of all the ones preceding it-- frame
> 100 has to caculate the events that happened in frames 1-99 before it can
> do its thing.   I'm almost wondering if I'd need to improve it just to meet
> coding expert snootiness.

The most important aspect - usefulness - is usually met automatically. 
And if an include file is useful that's already quite a lot.

gaussinblob.pov isn't an include file, it just demonstrates a technique. 
  If what it demonstrates was offered by an include file and even if it 
would inevitably be quite inefficient in large scale it would have its 
uses.  I remember there was some kind of 'clutter' include file 
developed some time ago which did something exactly like this.

But making an include file unnecessarily inefficient is of course a bad 
idea - if you need to recalculate all previous steps for a new one you 
should instead save the results to a file for example.

> [...]
> On the other hand, just to pick on one
> particular case,  I think that Christoph's mechsim patch could in fact make
> a very good SIGGRAPH paper. 

Hehe, don't tempt me...

> But I found that some of the features in the
> way it was designed prevented it from easy application to my kind of
> animation schedule.

Mechsim is designed to be very universal in its possibilities of 
application, just like POV-Ray itself.  So it requires the same 
approach: if it seems cumbersome to do something with it write some SDL 
code (or separate program) to simplify it.  Still simulations of course 
require quite some learning.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 27 Feb. 2005 _____./\/^>_*_<^\/\.______

Post a reply to this message