> >> 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

James Coons wrote:
> 
> 8. It would be nice to incorporate INI options directly into the source
> code, like MegaPov does.

Last time i checked MegaPOV did not have such a feature (and it will 
most likely not get it either).

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

Sure, and if you have a look at the list of patches in MegaPOV:

http://megapov.inetart.net/patches.html

you will see that there are quite some patches listed which were 
included after POV-Ray 3.5.

Christoph

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

Post a reply to this message

In article <4164b784@news.povray.org>,
 "James Coons" <jac### [at] ameritechnet> wrote:

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

As Warp said, this just won't be done. It has been considered, and 
decided to be a bad idea. Convert to JPEG in an external program, where 
you can adjust the settings to get the best results.


> 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.

There are many problems with this idea. First, the whole image needs to 
be re-rendered. Changes to an object can affect any portion of the 
image, so updating the image just won't work right.

Selecting an object to render could be useful during the development 
process, but would require that the entire scene be held in memory, and 
other big changes. Just use the existing partial rendering feature.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <4164b784@news.povray.org> , "James Coons" 
<jac### [at] ameritechnet> wrote:

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

This is the wrong group for this question.  This group is for discussion of
the POV-Ray source code.  POV-Ray feature suggestions should be posted in
povray.general, but in the past it has turned out that suggested features
already exist and a user simply did not know about them.  So if unsure,
asking in povray.newusers first might be possible.  Platform-specific
suggestions - that includes everything GUI related or requests for GUI
additions - should be posted in the group for the appropriate platform.

    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <cjameshuff-9D71D0.15304507102004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

>> 10. Output directly to JPG format, specifying the image quality in-line.
>
> As Warp said, this just won't be done. It has been considered, and
> decided to be a bad idea. Convert to JPEG in an external program, where
> you can adjust the settings to get the best results.

Actually, JPEG output is even implemented and does work, but it is
intentionally disabled.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message