In article <3fe4d404$1@news.povray.org>, "Greg M. Johnson" <gregj;-
)565### [at] aolcom> says...
> 
> "Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote in message
> news:3fe42e50$1@news.povray.org...
> >
> > In short: POV-Ray doesn't "talk" natively to other products.
> > 1) Your modelers, animators, texturers won't be able to have
> >  their fine work correctly and fluently translated in POV-Ray.
> >
> 
> I suppose I was suffering from a myopia that if I have done some modelling
> in povray blobs, everyone ought to be able to do it professionally. and a
> blind optimism that one day someone will make a boning sytem for bicubic
> patches that can be easily handled in povray.
> 
> > These are just examples: there are many other issues to consider
> > such as rendering speed, availability of POV-savvy graphic artists,
> > tech support etc.
> >
> 
> So where's 4.0 headed?  Will the future development process for povray
> simply involve introduction of new MegaPov features, or will it ever get to
> a much faster rendering engine?  (Hey, I'm not disparaging its rendering
> speed or demanding a feature request: I don't even know enough about the
> engine to know whether a manyear of volunteer effort could make "povray" a
> faster renderer.)
> 
> 
Someone is currently in the process of converting a patch to C (so it can 
be used in the current versions) that seems to have to potential to make 
*major*, lets repeat that, *major* speed increases with scenes that have 
large amounts of CSG. This would probably produce minimal speed ups for 
most scenes that only have a few dozen objects and minimal CSG, but for a 
large scale project it will make a lot of difference. One example is a 
project called POV-City. While I haven't heard much about it for a while, 
it would have used lots of user created SDLs to generate the layout of a 
city when viewed from various places. This would have been 100% certain 
to exceed the small number of CSG used in the average scene. Same with 
anything else that someone wanted to do which required any significant 
scale and number of objects.

There are bound to be additional speed improvements and things get 
cleaned up or better methods are found. A lot of fine tuning will still 
probably be done 'after' the first V4.0 design though, but it will almost 
certainly end up being faster right from the beginning.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message