 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've read that Povray 4.0 code, if I am not wrong, will be a porting of old
3.6 features into 3.7 architecture.
So, why not to introduce some new features? I think to features we find in
Yafray, Blender, etc. But also features introduced in MegaPov or not yet
introduced (patches not yet merged).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Antonio Ferrari" <nomail@nomail> wrote:
> I've read that Povray 4.0 code, if I am not wrong, will be a porting of old
> 3.6 features into 3.7 architecture.
>
> So, why not to introduce some new features? I think to features we find in
> Yafray, Blender, etc. But also features introduced in MegaPov or not yet
> introduced (patches not yet merged).
No, 3.7 is the porting of 3.6 features into 3.7 architecture.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> No, 3.7 is the porting of 3.6 features into 3.7 architecture.
And in 4.0 there will be new features or will be simply a revision of 3.7?
What's new in 4.0?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Antonio Ferrari escribió:
>> No, 3.7 is the porting of 3.6 features into 3.7 architecture.
>
> And in 4.0 there will be new features or will be simply a revision of 3.7?
> What's new in 4.0?
>
There are no plans for new features yet, but it will be mostly
rewritten, so lots of possibilities...
See this post:
http://news.povray.org/povray.general/message/%3C46e091ef$1@news.povray.org%3E
(or search Message-ID <46e091ef$1@news.povray.org> if you use a proper
newsreader)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Antonio Ferrari a écrit :
> I've read that Povray 4.0 code, if I am not wrong, will be a porting of old
> 3.6 features into 3.7 architecture.
>
> So, why not to introduce some new features? I think to features we find in
> Yafray, Blender, etc. But also features introduced in MegaPov or not yet
> introduced (patches not yet merged).
Let's build a "new features" list, properly researched (get as much
information as possible about that feature, theory, papers, code
samples, visual samples) and properly sorted (by category : core
rendering, objects, textures,...).
For example :
- "bokeh"
- sub-category of supersapling / focal blur
- general reference : http://en.wikipedia.org/wiki/Bokeh
- CG images samples : http://www.flarg.com/bokeh.html
- used in these renderers : brazil, vray,...
- theory/papers : http://portal.acm.org/citation.cfm?id=1242155
- implemented in MLPOV (should ask permission to author)
- ...
It would then be easier for developers who are seeking for
something to add to quickly evaluate the feasibility of a
feature.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoes skynetbe> wrote:
> Antonio Ferrari a écrit :
> > I've read that Povray 4.0 code, if I am not wrong, will be a porting of old
> > 3.6 features into 3.7 architecture.
> >
> > So, why not to introduce some new features? I think to features we find in
> > Yafray, Blender, etc. But also features introduced in MegaPov or not yet
> > introduced (patches not yet merged).
>
> Let's build a "new features" list, properly researched (get as much
> information as possible about that feature, theory, papers, code
> samples, visual samples) and properly sorted (by category : core
> rendering, objects, textures,...).
>
> For example :
> - "bokeh"
> - sub-category of supersapling / focal blur
> - general reference : http://en.wikipedia.org/wiki/Bokeh
> - CG images samples : http://www.flarg.com/bokeh.html
> - used in these renderers : brazil, vray,...
> - theory/papers : http://portal.acm.org/citation.cfm?id=1242155
> - implemented in MLPOV (should ask permission to author)
> - ...
>
> It would then be easier for developers who are seeking for
> something to add to quickly evaluate the feasibility of a
> feature.
>
> Fabien.
You have perfectly understood what I intended. So, let's write a list!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien escribió:
> Antonio Ferrari a écrit :
>> I've read that Povray 4.0 code, if I am not wrong, will be a porting
>> of old
>> 3.6 features into 3.7 architecture.
>>
>> So, why not to introduce some new features? I think to features we
>> find in
>> Yafray, Blender, etc. But also features introduced in MegaPov or not yet
>> introduced (patches not yet merged).
>
> Let's build a "new features" list, properly researched (get as much
> information as possible about that feature, theory, papers, code
> samples, visual samples) and properly sorted (by category : core
> rendering, objects, textures,...).
>
> For example :
> - "bokeh"
> - sub-category of supersapling / focal blur
> - general reference : http://en.wikipedia.org/wiki/Bokeh
> - CG images samples : http://www.flarg.com/bokeh.html
> - used in these renderers : brazil, vray,...
> - theory/papers : http://portal.acm.org/citation.cfm?id=1242155
> - implemented in MLPOV (should ask permission to author)
> - ...
>
> It would then be easier for developers who are seeking for
> something to add to quickly evaluate the feasibility of a
> feature.
>
> Fabien.
Seems like the best place for such a thing is the wiki. I wonder if Jim
finished setting it up.
(see povray.general/<47126c2d$1@news.povray.org>)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 27 Oct 2007 17:05:05 -0300, Nicolas Alvarez wrote:
> Seems like the best place for such a thing is the wiki. I wonder if Jim
> finished setting it up.
There are some software dependencies for the mathy stuff that need to be
installed by Chris; there's also the authentication system that needs to
be setup as well, and that piece is not yet ready.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mine isn't too difficult or anything really new, but here it is.
The addition of F-Stops into the camera focal blur. Instead of having
non-related aperture numbers, have them in two forms. 1) The numbers already
in pov. 2) F-Stop functions.
aperture = 24
or
aperture = f6.8
Just a simple little addition.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Antonio Ferrari" <nomail@nomail> wrote:
> I've read that Povray 4.0 code, if I am not wrong, will be a porting of old
> 3.6 features into 3.7 architecture.
>
> So, why not to introduce some new features?
A couple ideas about cameras, both[I think] fairly trivial.
(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.
(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.
-Robert Dawson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers escribió:
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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:
> Chambers escribió:
> >> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers escribió:
> 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
|
|
| |
| |
|
|
|
|
| |
