>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

Ron Parker wrote:
> 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.

If it's perspective, it does! For example, can you remember of a scene with
a "normal" camera were an object's straight edge turned curved <he he> in
the image? (I know this is no proof, but I know perspective is line-> line).

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

I'll dig in my school notes and find some math about perspective, such as
main properties of transformation, transform matrix (wich is 4x4 with
homogenous coordinates). I'll post that sometime next week...

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


I think it turns a cone into an _other_ cone. Line-> line.



Povingly


Philippe

Post a reply to this message

On Thu, 9 Dec 1999 11:07:49 +0100, Philippe Debar wrote:
>> 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?
>
>I think it turns a cone into an _other_ cone. Line-> line.

But you can find a cylinder that also maps to that other cone.  (proof: there
is a plane where the scale factor perpendicular to the axis is 1. The 
intersection of the cone with this plane is a circle.  Since the intersection 
of the cylinder with the plane is also a circle, and since the scale factor is 
1, the desired cylinder has the same radius.)  If a cone truly does map to a 
different cone, the transform isn't invertible and thus POV can't use it.  
But, as I'll show, it doesn't actually map a cone to another cone so this 
argument is from false assumptions.

As proof that it doesn't map a cone to a cone, try the following script.  
There are three commented lines in the code.  The first one is the equation 
for a cylinder, so that you can verify that the given transform maps a 
cylinder to a cone.  The line after it is the equation for a cone (the one 
it maps the cylinder to, in fact.) As written, the code generates a cone.

The second commented line is an identity transform.  If you uncomment it 
and comment the line after it, you may verify that the code does produce a 
cone.  As written, it transforms each point using a scale factor equal to 
the distance along the Y axis from the origin, except it doesn't change the 
Y coordinate.  You'll see that this transform maps a cone to the SOR of a 
parabola, so it doesn't map all lines to lines.

The third commented line is a different interpretation of the idea "scale 
by an amount equal to the distance along an axis from the origin."  You'll 
see that while it does map a cone to a cone (the same cone, in fact), it 
maps a cylinder to a paraboloid, so it doesn't map lines to lines either.

------------ cut here --------->8========
camera { location <0,1,-5> look_at y }
light_source {-5*z rgb 1}
#declare H = 0;
#while ( H < 2 )
  #declare T = 0;

  //#declare X = 1;   // a cylinder
  #declare X = H;   // a cone
  
  #while ( T < 360 ) 
    #declare Loc = vrotate( <X,H,0>, T*y );
    
    // #declare NewLoc = Loc; // identity transform
    #declare NewLoc = <Loc.x*H,Loc.y,Loc.z*H>; // NL trans 1
    //#declare NewLoc = <Loc.x*H,Loc.y*H,Loc.z*H>; // NL trans 2
    
    sphere { NewLoc, .05 pigment {color red 1}}
    #declare T=T+2;
  #end
  #declare H = H + .05;
#end                
------------ cut here --------->8========

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