POV-Ray : Newsgroups : povray.general : Who is ideal user of 5.0? , 6.0?? --> guidelines for .inc developers : Re: Who is ideal user of 5.0? , 6.0?? --> guidelines for .inc developers Server Time
2 Aug 2024 00:12:42 EDT (-0400)
  Re: Who is ideal user of 5.0? , 6.0?? --> guidelines for .inc developers  
From: Christoph Hormann
Date: 7 Mar 2005 16:25:01
Message: <d0igpr$c0v$1@chho.imagico.de>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.