Is there something like a wish-list for the next version of POV-Ray?

Here are my suggestions:

1. In animations only things that change between frames should be
reparsed, i.e. the first parsing should recognize which changes will
occur later on (maybe by looking at the "count" variable). This would
save much parsing time in scenes with lots of non-moving objects (e.g.
trees with loads of branches, twigs and leafs).

2. Better radiosity with multiple interreflections. At
http://www.lightscape.com are nice samples how it should look. (This is
no critics. I know that radiosity is only experimental in POV 3.0)

3. Native support for L-Systems to create trees etc.

4. A fast preview, so that even animations could be previewed in
real-time on fast machines. Maybe polygon-based like game rendering
engines.

The suggestions above are in no way meant critical. I appreciate the
work of all POV-Ray programmers and supporters. I also appreciate that
POV-Ray is free and therefore I don't want to demand anything.
So if a POV-Ray "official" reads these lines, just take them as
suggestions. Maybe it isn't too difficult to realize one or two (or all
:-) of them.

Roy.

-- 

email: roy### [at] rcsurztu-dresdende
www:   http://rcswww.urz.tu-dresden.de/~roy/

Post a reply to this message

Roy Schulz <roy### [at] rcsurztu-dresdende> writes:

> 1. In animations only things that change between frames should be
> reparsed, i.e. the first parsing should recognize which changes will
> occur later on (maybe by looking at the "count" variable).

  Could be. I think it would just need to add a boolean field in the
data structure. But I do not know whether it would or not significantly
reduce the parsing time, nor whether it would increase significantly
the paring time for still images.

> 2. Better radiosity with multiple interreflections. At
> http://www.lightscape.com are nice samples how it should look. (This is
> no critics. I know that radiosity is only experimental in POV 3.0)

  You said it, it is experimental.

> 3. Native support for L-Systems to create trees etc.

  I do not know about these.

> 4. A fast preview, so that even animations could be previewed in
> real-time on fast machines. Maybe polygon-based like game rendering
> engines.

  Ah hah. Not possible. POV-Ray is a ray tracer, and as such has no idea
of what a polygon is. For the preview, have you tried the -q option?

  Happy ray-tracing though,

Roland.
-- 

bob### [at] casimirrezelenstfr -- Linux, POV-Ray, LaTeX

Post a reply to this message

in POV 3.0)
>
>3. Native support for L-Systems to create trees etc.
>


Well, with the new file in/out commands, and an if-then structure, it's
completely possible to create an L-System style .INC file.

In fact, it's possible now. You just edit the .INC file to load the settings
list. =)

I don't have the time to create it tho, but maybe someday....

Twyst=====================================
pov-ray news, reviews and tutorials
http://twysted.net
e-mail: twy### [at] twystednet
==========================================

Post a reply to this message

On 17 Jun 1998 01:25:26 +0200, bob### [at] casimirrezelenstfr (Roland Mas)
wrote:

>Roy Schulz <roy### [at] rcsurztu-dresdende> writes:
>
>> 1. In animations only things that change between frames should be
>> reparsed, i.e. the first parsing should recognize which changes will
>> occur later on (maybe by looking at the "count" variable).
>
>  Could be. I think it would just need to add a boolean field in the
>data structure. But I do not know whether it would or not significantly
>reduce the parsing time, nor whether it would increase significantly
>the paring time for still images.

You'd also have to save the location in the file where parsing begins,
and you'd have to keep a call graph of what include files were
included when.  Variables would have to be marked as clock-dependent
as well, which means you'd need to know every location where they can
be defined and under what conditions... It wouldn't be very easy.

>> 2. Better radiosity with multiple interreflections. At
>> http://www.lightscape.com are nice samples how it should look. (This is
>> no critics. I know that radiosity is only experimental in POV 3.0)

Stephen Horn claims to be working on a better radiosity model.  Until
then, I would like to see the bug that causes it to turn off radiosity
for all future renders when you cancel a render in POVWin fixed.

>> 3. Native support for L-Systems to create trees etc.

I think someone already has an .inc file that can do a pretty good job
of this, among other things.  I want to say it's one of Chris
Colefax's .inc files, but I'm not sure.

>> 4. A fast preview, so that even animations could be previewed in
>> real-time on fast machines. Maybe polygon-based like game rendering
>> engines.
>
>  Ah hah. Not possible. POV-Ray is a ray tracer, and as such has no idea
>of what a polygon is. For the preview, have you tried the -q option?

Precisely.  While most of the primitives could be translated to meshes
fairly well, some just can't.  Anything infinite or potentially
infinite (planes, polys, etc.) fits in this category.  To top that
off, you'll still have to parse the scene for each frame. Even a
simple scene like skyvase takes a second to parse on a PII-233.

Post a reply to this message

> >> 4. A fast preview, so that even animations could be previewed in
> >> real-time on fast machines. Maybe polygon-based like game rendering
> >> engines.
> >
> >  Ah hah. Not possible. POV-Ray is a ray tracer, and as such has no idea
> >of what a polygon is. For the preview, have you tried the -q option?
> 
> Precisely.  While most of the primitives could be translated to meshes
> fairly well, some just can't.  Anything infinite or potentially
> infinite (planes, polys, etc.) fits in this category.  To top that
> off, you'll still have to parse the scene for each frame. Even a
> simple scene like skyvase takes a second to parse on a PII-233.

No, no, you're all wrong. Firstly, everything except infinite objects
can be approximated with triangle meshes using implicit surface
approxiamtion techniques (This is most commonly used to convert blobs
into triangle meshes), and infinite objects can be partially converted
based on which part of them the camera catches. The fact that Povray is
a raytracer doesn't mean that it *can't* generate polygon-based
renderings. This could be an alternative rendering mode just for
previews. This doesn't mean that this idea is any good though;
Converting all of the objects into triangle meshes will probably take
more time than it will save. Then again, maybe not, what do I know.

Guy

Post a reply to this message

Guy Rauscher wrote in message <359### [at] netvisionnetil>...
>> >> 4. A fast preview, so that even animations could be previewed in
>> >> real-time on fast machines. Maybe polygon-based like game rendering
>> >> engines.
<sniped>
>
>No, no, you're all wrong. Firstly, everything except infinite objects
>can be approximated with triangle meshes using implicit surface
>approxiamtion techniques (This is most commonly used to convert blobs
>into triangle meshes), and infinite objects can be partially converted
>based on which part of them the camera catches. The fact that Povray is
>a raytracer doesn't mean that it *can't* generate polygon-based
>renderings. This could be an alternative rendering mode just for
>previews. This doesn't mean that this idea is any good though;
>Converting all of the objects into triangle meshes will probably take
>more time than it will save. Then again, maybe not, what do I know.
>
>Guy


Thou having a polygon of an object created that could then be rotated in
realtime for object creation would be very useful. Even if for example, it
takes twice as long to render to the meshes as just to render the picture.
For checking an object to then be able to rotate it, zoom in etc would be
helpful and a huge time saver.


Anyway Just my thoughts.

Fran.

Post a reply to this message

>On 17 Jun 1998 01:25:26 +0200, bob### [at] casimirrezelenstfr (Roland Mas)
>wrote:
>
>>Roy Schulz <roy### [at] rcsurztu-dresdende> writes:
>>> 2. Better radiosity with multiple interreflections. At
>>> http://www.lightscape.com are nice samples how it should look. (This is
>>> no critics. I know that radiosity is only experimental in POV 3.0)
>
>Stephen Horn claims to be working on a better radiosity model.  Until
>then, I would like to see the bug that causes it to turn off radiosity
>for all future renders when you cancel a render in POVWin fixed.
>

Many are already out there!   Search for "A Ray Tracing Solution for Diffuse
Interreflection"  by  Gregory J. Ward,  Francis Rubenstein,  and Robert D.
Clear.   This is work and discussion from Siggraph '88   This is the best
argument I've seen for telling _which pixels_ should have a radiosity
calculation performed on them.   

For a fuller and more up-to-date theoretical discussion of the problem search
for the Ph.d dissertation by Eric P. Lafortune, titled "Mathematical Models
and Monte Carlo Algorithms for Physically Based Rendering"   Make sure to have
a nice Post-script file viewer.  (I suggest GhostView and GhostScript for you
WIN95'ers)

My major complaint against Monte Carlo is that it defines second-level points
to contain contributions from only one direction.  Second-level points should
contain an interpolated contribution from ALL first-level points.  There is a
similar problem with first-level points; they contain contribution from only a
piece of the light sources, not a full interpolation of the myriad of the
light sources (be that the case. Consider a scene lit by a green and a red
light source...how does Monte Carlo react?).     Also, Lafotune's
bi-directional algorithm considers a point at a time, not at all considering
the _total amount_ of rays traced for the rendering of the entire scene.
Obviously, the slowness of the radiosity calcs will be apparent to a user from
the total amount of rendering time. 

My solution to the total radiosity calculation time are databases stored as a
BSP trees.  The problem of 'best contributers' still occupies me.  More
later... 

Steve Horn

Post a reply to this message

Hello POV Team:

I have a few suggestions for the next POV-Ray:

1. I often have multiple source files open at one time. I would like a way
to "Add current Source File" to Queue (without writing a macro). I usually
do the following:

   FILE | SAVE AS | copy/paste file name
   QUEUE | ADD | paste file name | OK

2. I would like to be able to re-order the Queue (Click, UP|DOWN, etc).

3. I would like to be able to add an item to the Queue, but disable it. For
instance, I could manually disable the "long" renders to allow the short
renders to run. Then, when the short ones are done, I could enable the long
ones.

4. I would like to see a built-in Spline Editor, Lathe Creator, Polygon,
SOR, etc. Set a "bounding box" (to determine where in the final image the
object would go), then set points, average, flip, etc. The results could go
into the ClipBoard or into a new file. Also, the ability to manually "trace"
an actual photograph to create a spline/polygon/lathe/SOR - THAT WOULD BE
GREAT! Nothing automatic - that would be too complicated.

5. "Pop-Up" Scene Definition Language Syntax Help (a fast alternate to [F1]
or the INSERT Menu. Click on "light_source", press [Shift F1] (or whatever),
the complete syntax would be copied to the Clipboard or pulled into the
editor. I like how Visual Basic does it (HelpText below the cursor during
typing), but that would probably require rewriting the entire editor.

6. The option to edit an include File by right-clicking it is great, but I
would like a button to do that (click on the line, "Edit COLORS.INC" button
appears or enableds).

7. Certain INI Options are set quite often (pretrace, vistas_on, etc) - It
would be nice to have a checkbox or dropdowns that would directly edit the
INI File and make the changes (in addition to anything else that one might
wish to edit there).

8. It would be nice to incorporate INI options directly into the source
code, like MegaPov does.

9. Are MegaPov features considered for incorporation into the "official"
Pov-Ray?

10. Output directly to JPG format, specifying the image quality in-line.

11. I would like a "flag" ("/overwrite", for instance) that would update an
existing image (assuming the same size and type) when selecting a screen
region. For instance, I adjust the reflectivity of a small object, highlight
just that object, re-render it and the rendered results are written "in the
right spot" into the target image, instead of the original image being
deleted.

Just food for thought.

James Coons

Post a reply to this message

James Coons <jac### [at] ameritechnet> wrote:
> 10. Output directly to JPG format, specifying the image quality in-line.

  Certainly not. That will only cause more problems than it's worth (and
in fact, it's worth quite little).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> 11. I would like a "flag" ("/overwrite", for instance) that would
> update an existing image (assuming the same size and type) when
> selecting a screen region. For instance, I adjust the reflectivity of
> a small object, highlight just that object, re-render it and the
> rendered results are written "in the right spot" into the target
> image, instead of the original image being deleted.

Ray-tracing doesn't work like that. POV-Ray doesn't compute the
projection of an object onto the image; instead, it fires rays from the
image and works out which objects they hit. Besides, to do this it would
also have to update all the object's reflections, shadows, etc...

-- 
A most peculiar man    With the windows closed      And Mrs Reardon says
He died last Saturday  So he'd never wake up  He has a brother somewhere
He turned on the gas   To his silent world   Who should be notified soon
And he went to sleep   And his tiny room    .oO( http://sad.istic.org/ )

Post a reply to this message