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

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.

in graphics you have the concept of mipmaps 
(http://en.wikipedia.org/wiki/Mipmap) where you provide a texture at 
several resolutions and have the renderer decide which one is the 
optimal. I can only assume that POV4 will have the same concept for 
objects, so you can define a tree at maximum resolution and when the 
tree gets too far away it may substitute something simpler, like a 
predefined mesh with texture or even a bitmap with transparency.
If apart from the raytracing camera you can also have a scanline camera 
for that same scene, I think it can be totally intuitive for the scene 
composer. Note: depending on the implementation that may require 
rendertime changes in the scene.

Post a reply to this message

"Nekar Xenos" <nek### [at] gmailcom> wrote in message 
news:47459eaf@news.povray.org...
> 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.
>
>
Oh yes and
5) some kind of plant generator including trees and grass


-- 
-Nekar Xenos-

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

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

That's why querying the Q level would be good.

I already do things like

#declare LOD_TREES = 3;

for many different items in my scenes, and then use different objects / textures
depending on the setting.

Being able to do something like

#if (SCENE_QUALITY = 3)

would simplify my scenes quite a bit.

....Chambers

Post a reply to this message

> Being able to do something like
> 
> #if (SCENE_QUALITY = 3)
> 
> would simplify my scenes quite a bit.
> 

You can use Declare=SCENE_QUALITY=3 as a command line option or in an 
.ini file.

Post a reply to this message

Nekar Xenos wrote:
> What I would like to see is :
> 4)Realtime preview.

Real time preview is a function of the modeler, not the renderer.

Regards,
John

Post a reply to this message

>> What I would like to see is :
>> 4)Realtime preview.
>
> Real time preview is a function of the modeler, not the renderer.

A lot (most?) people use POV as a modeler though, not just a renderer.  IMO 
a real-time preview of your SDL code would be hugely valuable.

Post a reply to this message

"Nekar Xenos" <nek### [at] gmailcom> wrote in message 
news:474bb388@news.povray.org...
>
> "Nekar Xenos" <nek### [at] gmailcom> wrote in message 
> news:47459eaf@news.povray.org...
>> 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.
> Oh yes and
> 5) some kind of plant generator including trees and grass
>
And...
6) a vortex_warp almost like black hole warp, but with rotation instead of 
scaling


-- 
-Nekar Xenos-

Post a reply to this message

Hello,
  One thing I'd like to see is the ability to use standalone spline objects when
defining objects that use splines, such as sor, lathe, prism, and sphere_sweep.
For example:

#declare MySpline = spline { ... }

#declare MyLathe =
  lathe {
    spline { MySpline }
    texture { ... }
  }

I think this would serve to generalize spline use much more, and make them more
useful.

Post a reply to this message