Robert Dawson <rda### [at] csstmarysca> wrote:
> (2) Currently there are cameras with parallel rays and cameras with diverging
> pencils of rays. How about a keyword that would allow a camera to "shoot in
> form infinity" along a converging pencil of rays? The result, if mapped onto a
> sphere,  would be something like a "Termesphere"(tm), or like the images used
> by Poser and similar programs to store faces.

  This is, again, something which should not be a part of the core code,
but easily scriptable. IOW, if there isn't a suitable camera type, you
write one with SDL.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Robert Dawson <rda### [at] csstmarysca> wrote:
> > (2) Currently there are cameras with parallel rays and cameras with diverging
> > pencils of rays. How about a keyword that would allow a camera to "shoot in
> > form infinity" along a converging pencil of rays? The result, if mapped onto a
> > sphere,  would be something like a "Termesphere"(tm), or like the images used
> > by Poser and similar programs to store faces.
>
>   This is, again, something which should not be a part of the core code,
> but easily scriptable. IOW, if there isn't a suitable camera type, you
> write one with SDL.
>
> --
>                                                           - Warp

Two things I'd be interested in:

1) System variables to return the resolution of an input image.  This appears to
be already available in the source code, just not passed on to the SDL.

2) separate ior for fresnel reflection (in finish block) to allow for better
texture mapping.  I use fresnel quite often, however if I want to map something
like chrome text on a glass block, I would have to model them separately as they
both don't use the same ior.

Just suggestions, however they would be adding to the key word pool.  I've been
wanting to write a patch to do this myself regardless, just don't have the time
to look into how to compile it...

-tgq

Post a reply to this message

"Robert Dawson" <rda### [at] csstmarysca> wrote:
> (1) Currently, if I understand correctly, if multiple cameras are included in a
> scene file only one will be used. It would be useful to be able to include
> multiple cameras and have each used in turn (like the familiar scene at a
> tourist site when everybody hands their camera to the tour guide to take the
> same shot of the group!) This would however need some way to disambiguate the
> image name, perhaps an extra "camera_name" field in the camera definition.
>    -Robert Dawson

This can be done right via #declaring a variable and using #if stuff. like

#declare FirstPerson = yes;
#ifndef(FirstPerson)
#end
// Overview camera
#if (FirstPerson=no)
#end

C:\pv3.6\scenes\animations\splinefollow\splinefollow.pov

If the tour guide can automatically frame the entire model (minus the infinite
planes) that would be good.

Just to add on, I think reparsing each frame for an animation render is too
wasteful.


tq tq 8)

Post a reply to this message

What I would like to see is :

1) something like LightSys and CIE incorporated seemlessly into PovRay.
2) A planetary include file that has something similar to a procedural 
version of Celestia - the universe with planets and galaxies and earth-like 
planets with built in "SunPos" Systems and aTerraPov system.
3)Fixed up Glows.
4)Realtime preview.


-- 
-Nekar Xenos-

Post a reply to this message

"Nekar Xenos" <nek### [at] gmailcom> wrote:
> What I would like to see is :
>
> 1) something like LightSys and CIE incorporated seemlessly into PovRay.

This would be good.

> 2) A planetary include file that has something similar to a procedural
> version of Celestia - the universe with planets and galaxies and earth-like
> planets with built in "SunPos" Systems and aTerraPov system.

This is probably best kept as an include file, but could be included in the
standard distribution.

> 3)Fixed up Glows.

How?  You can do some great glows with what's already there.

> 4)Realtime preview.

As long as POV lacks a GUI editor, this one remains problematic.  OTOH, a button
next to the "Render" button that launches a Q5 render, or something like that,
could be useful.

In fact, along with such a button, the ability to query the current quality
level (+Q from the command line) would be useful for scenes.  I already do all
kinds of LOD anyway; linking it to the current +Q option would make this
feature much more useful for me.

....Chambers

Post a reply to this message

>> 4)Realtime preview.
> 
> As long as POV lacks a GUI editor, this one remains problematic.  OTOH, a button
> next to the "Render" button that launches a Q5 render, or something like that,
> could be useful.
> 
> In fact, along with such a button, the ability to query the current quality
> level (+Q from the command line) would be useful for scenes.  I already do all
> kinds of LOD anyway; linking it to the current +Q option would make this
> feature much more useful for me.
> 

+Q0 is still slow for many scenes, and you can't do things like rotating 
the camera around the scene with a good framerate.

My ideal POV-Ray GUI is: a text editor and a live GPU-rendered preview. 
Probably with the ability to move the camera with mouse and/or keyboard. 
But I definitely don't need to click on objects.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> +Q0 is still slow for many scenes, and you can't do things like rotating 
> the camera around the scene with a good framerate.

  How is POV-Ray supposed to generate the preview if the objects are so
heavy to trace that even +Q0 is too slow?

-- 
                                                          - Warp

Post a reply to this message

Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> +Q0 is still slow for many scenes, and you can't do things like rotating 
>> the camera around the scene with a good framerate.
> 
>   How is POV-Ray supposed to generate the preview if the objects are so
> heavy to trace that even +Q0 is too slow?
> 

GPU-rendered: Generate mesh once, rotate camera around it at 60fps.

Raytraced at +Q0: just as slow (maybe many seconds) for each frame.

Post a reply to this message

Nicolas Alvarez wrote:
> Warp escribió:
>> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>>> +Q0 is still slow for many scenes, and you can't do things like 
>>> rotating the camera around the scene with a good framerate.
>>
>>   How is POV-Ray supposed to generate the preview if the objects are so
>> heavy to trace that even +Q0 is too slow?
>>
> 
> GPU-rendered: Generate mesh once, rotate camera around it at 60fps.
> 
> Raytraced at +Q0: just as slow (maybe many seconds) for each frame.

So that'd be basically a parse&convert by POV-Ray (to DirectX, Open GL 
whatever), and then hand it over to a OS-specific side-app and/or 
plug-in in which you could navigate a movable camera?  I imagine that 
side-app could easily display some basic camera position information. 
That sounds useful for checking overall geometry & positioning.  I'm 
sure though that somebody will point out the difficulties related to 
infinite surfaces and various precision-level choices, not to mention 
just the undertaking of building in a converter generally.
Charles

Post a reply to this message

Charles C escribió:
> not to mention just the undertaking of building in a converter
> generally.

Well, we can use this as a base:
http://www.daylongraphics.com/other/povray/patches/

(Hasn't been updated in 4 years)

And/or maybe this:
http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html

(it's all Haskell, so probably we can only borrow ideas and not directly 
code)

Post a reply to this message