>...and virtual light sources, global ilumination maps

??? Explain how triangles make this possible.

Post a reply to this message

First, I want to state that I have not yet used twister, so I don't know
exactly which features your are referring to.

Claude Mench <c.m### [at] adilinstrumentscom> wrote...
>
>         - Will it exist an API allowing to use POVRay
>           in a programmatically mode, for instance, POV
>           could exist as a python module (like lightflow).
>           It could be proprietary but it will be good to
>           overcome some parts of the parser when used in
>           conjunction with diverses pov front-end object
>           generators or modelers.


Not in version 3.5.  Whether this is done in future versions is unknown.
However, the wording of POV-Ray's license currently does not allow this (to
avoid the exploitation of POV-Ray).

>         - Can we expect an preview mode using OpenGL (I'm
>           aware that the tessalation of all objects existing
>           in pov will be difficult, and infinity ojects also...)

If tesselation of all primatives is done, then this would definately be a
possibility.  However, POV-Ray is primarily a ray-tracing engine, so this
would likely not be a priority.  As was mentioned, using a preview mode
(with quickcolor, no refraction or reflection, minimal lighting, etc.) can
render many scenes quite quickly.

>         - Will the photon map be improved to perform optimised
>           global illumination and shadows optimisation ?

I do plan to extend photon mapping to work with global illumination.  There
are a variety of misunderstandings with how photons work with the current
global illumination model (instead of replacing it).  Anyway, yes, I am
working on that.

I will likely no use photons for shadow optimizaiton.  More recent papers by
Jensen downplay the actual worth of this technique.  To quote from Jensen's
SigGraph '99 course notes: "Using a derivative of the photon map method we
can compute shadows more effciently using shadow photons [Jensen95c]. We do,
however, not normally use this approach since it can lead to artifacts in
the shadows (that are very noticeable to the eye)."

>         - Is there an official binary format of scene file
>           planned ?

Not for version 3.5.  The past policy has been not to have a binary format
for platform-specific reasons.  However, it is my opinion that a
platform-independent binary would be possible and would make sense.

>         - Extended particle system for simulating fur or grass?

The POV scripting language can support much of this.  Some features are
being added (such as the trace() function) which help.  If this could be
done much more efficiently with a built-in object, then it is possible that
it might be added in the future.

>     I was looking in Softimage Twister specifications and several
> reviews from it, I finded this very innovative, I was so entousiastic
> about it, that I dreamed to see a free rendering package going in the
> same direction...
>
>     I hope that a free package could be as ambitious as twister
> (layer rendering, interactive renderer with object hierachy, etc).

Some of these features (such as layered rendering) probably wouldn't be
built directly into the rendering engine.  However, support for them could
be incorporated into the engine (such as z-buffer output) so that external
interactive programs could offer these features.

Remember when comparing POV to other products that POV is only the rendering
engine.  Twister, for example, is a combination of Softimage's Mental Ray
rendering engine with their modeling environment.  To compare apples to
apples, POV should be compared to Mental Ray (in which case, MR still has
featuers that have not yet been implemented in POV).

-Nathan

Post a reply to this message

>Remember when comparing POV to other products that POV is only the
rendering
>engine.  Twister, for example, is a combination of Softimage's Mental Ray
>rendering engine with their modeling environment.  To compare apples to
>apples, POV should be compared to Mental Ray (in which case, MR still has
>featuers that have not yet been implemented in POV).


    Twister is not the modelling part of sumatra if I understand weel
all my readings. twister is only the rendering user interface, this
interface is there to allows an interactive rendering. It is a modeller
in the sense that you can move, rotate, scale objects, but not really
model individual complex objects. When you place your objects rendering
the global scene is quite helpfull. It is really at this moment you need
rendering. I think that this is the natural way that a successfull
renderer should go nowadays.

    Thank's for your answer, I read your papers about the photon mapping
in UVPov and also Jensens original one. I have one question, You are use
your own sampling method for light ray with your spiral sampling and said
that Jensens methods gives noisy results. But the images i've seen from
Jensen are not noisy. Does your sampling method give an performance hurt
compared to Jensen's ?

    I'm really interested to learn or be aware of the techniques that
could make a production renderer more and more realistic. For now production
renderers where everytime scanline. Twister goes further and introduce
global illumination and generalized ray tracing in a production
renderer. It uses photon maps and a very good progressive raytracing
rendering. My interrest for photon map is that they seem to be the
solution for an acceptable global illumination technique in term of
performance hurt.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: If ANSI-standard C was the only rule by which things got
: added, there would be no preview display, or Mac GUI, or Windows
: GUI, or DOS help screens, or x-povray, or...  you get the idea.  

  I know, but I think that that extra stuff doesn't need very much
modifications to the povray core code.
  However, I think that an OpenGL preview mode would require a lot of changes
in the povray core.

: OpenGL seems fairly widespread, so I would say that if an OGL 
: preview deserves to be shot down it deserves to be shot down on its 
: own merits as a feature rather than because OGL isn't available on 
: the DOS or Amiga platforms.  That's just my opinion, though; I may
: be in the minority.

  OpenGL is not available in this SparcStation 5 either...

: FWIW, I think tesselation of primitives would be a fairly useful 
: feature, too, and not just for OGL preview.  I still think the OGL 
: preview wouldn't be much faster than current preview methods, given
: the parse time, but I see lots of other uses for being able to make
: triangles out of primitives.

  You are right of course. If someone can do it easyly, then that's great.
  The only problem I see is that you can't tesselate every primitive in
povray (mainly the infinite ones, like planes and polys).

  Btw: Are there _any_ renderer that can do _real_ non-uniform transformations
to objects?
  Changing the location of triangle vertices is not real non-uniform
transformation.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Tue, 7 Dec 1999 19:10:16 -0500, "TonyB"
<ben### [at] panamaphoenixnet> wrote:

>>...and virtual light sources, global ilumination maps
>
>??? Explain how triangles make this possible.

For a virtual light source approach to rendering caustics, there are
three step:

1. Find the mirror image of each light source in the plane of each
triangle of the object(s) that will generate the caustics. This is
done only once, after parsing is done and before rendering.

2. For each point you want to calculate the caustics for, see how many
of those virtual light sources are visible through their respective
triengles, i.e. if the ray from the point in question to the virtual
source passes through the triangle

3. Sum up and do a weighted average of the results

One of the papers I read about radiosity and using a global
ilumination map described a similar approach. I don't recall specifics
but basically the approach was to build the illumination map of an
object using UV mapping and global ambient lighting was then done
similar to environment mapping.

Another very good use of fully tesselated objects is relatively easy
collision detection.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

On 8 Dec 1999 04:02:34 -0500, Nieminen Juha
<war### [at] punarastascstutfi> wrote:

>  Btw: Are there _any_ renderer that can do _real_ non-uniform transformations
>to objects?
>  Changing the location of triangle vertices is not real non-uniform
>transformation.

According to Von Neumann's theorem, any renderer can :)


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

On 8 Dec 1999 04:02:34 -0500, Nieminen Juha wrote:
>  Btw: Are there _any_ renderer that can do _real_ non-uniform transformations
>to objects?
>  Changing the location of triangle vertices is not real non-uniform
>transformation.

There is a paper out there somewhere - can't remember whether I saw it on the 
web or in an old ACM publication - that talks about methods for tracing curved
rays.  It's still not perfect, because it essentially traces the curves as a
series of line segments, but at least it doesn't require tesselation.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: There is a paper out there somewhere - can't remember whether I saw it on the 
: web or in an old ACM publication - that talks about methods for tracing curved
: rays.  It's still not perfect, because it essentially traces the curves as a
: series of line segments, but at least it doesn't require tesselation.

  Perhaps this kind of non-uniform transformation could be possible with
povray?

  Btw, why is not possible to scale an object so that the scale changes
linearly along an axis? I don't remember the name if this transformation,
but it's the one that can convert a cylinder into a cone.
  I think that it's a linear transformation. I line transformed this way
is still a line after the transformation. Should be perfectly possible
in povray. If this is so, wouldn't it be a good idea to add this kind
of transformation?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 8 Dec 1999 09:22:48 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: There is a paper out there somewhere - can't remember whether I saw it on the 
>: web or in an old ACM publication - that talks about methods for tracing curved
>: rays.  It's still not perfect, because it essentially traces the curves as a
>: series of line segments, but at least it doesn't require tesselation.
>
>  Perhaps this kind of non-uniform transformation could be possible with
>povray?
>
>  Btw, why is not possible to scale an object so that the scale changes
>linearly along an axis? I don't remember the name if this transformation,
>but it's the one that can convert a cylinder into a cone.
>  I think that it's a linear transformation. I line transformed this way
>is still a line after the transformation. Should be perfectly possible
>in povray. If this is so, wouldn't it be a good idea to add this kind
>of transformation?

It's a perspective transformation.  It's not linear, in that 
f(A)+f(B) != f(A+B).  I'm not sure it transforms lines to lines, 
either.  Consider the (2d) perspective transformation f(x,y) = xy.  
If you transform a line parallel to the X axis, such as y=2, then 
you get a line in return (y=2x).  If you transform a line parallel 
to the Y axis, you also get a line in return.  But what happens 
when you transform the line y=x?  By my calculations, you get y=x*x, 
which is not a line.

For another thought experiment, assume that you have a transformation 
that can turn a cylinder into a cone.  What would it do to the 
resulting cone?  If it leaves it a cone, then the transformation 
isn't invertible, because there's some cylinder that maps to the same 
cone.  If it makes it anything else, then what does it do to a line 
that lies in the surface of that cone?

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

We would need some sort of scale_map or something, wouldn't we?

scale {y scale_map {[0 <1,1>][.25 <1,.25>][1 <.25,1>]}}

Where x, y, or z would establish the linear part of the scaling, and the
scale map would modify the other two axices.

Post a reply to this message