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

Claude Mench <c.m### [at] adilinstrumentscom> wrote ...
>     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 have been able to get OK results with pure random shooting, but I always
had to shoot a very large number of photons.  Using my jittered spiral
technique, I am able to get very good results with few photons.  If
anything, it should offer better performance than a totally random method
(or even a weighted monte-carlo method).

I still don't know exactly how Jensen got the good results that he got with
his monte-carlo photon tracing.

-Nathan

Post a reply to this message

Sorry, I can't spent much time thinking about this here at work... :(
I'll "work" on this this week-end.
On first read, I didn't quite follow the math, but I think it will become
much clearer tomorrow (I have quite important work things on my mind right
now)

Please hold <Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...



Philippe

Post a reply to this message

<Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...
</Vivaldi's Dmin concerto>
Sorry, I had very little time this week-end (and I still had no time to try
other newsreaders either)
:-(

And I have no time now... :-( :-( :-(

<Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...

Philippe

Post a reply to this message

On Mon, 6 Dec 1999 15:42:52 +0100, "Claude Mench"
<c.m### [at] adilinstrumentscom> wrote:

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

Well, a .zip compressed archive with filenames taken with a bit of
care (8+3 lowercase names) seems (at least for me) pretty standard
between platforms. ;-)

Post a reply to this message

In article <sbvf5sgo1utia3vic03fgnad8ohe86gb8g@4ax.com>, Joaquin Hierro 
Diaz <jhi### [at] cticsices> wrote:

> Well, a .zip compressed archive with filenames taken with a bit of
> care (8+3 lowercase names) seems (at least for me) pretty standard
> between platforms. ;-)

Hmn, would it be useful or feasible to allow POV to read .zip files 
directly? Are there any license restrictions on .zip compression, or any 
other reason this wouldn't be done?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

> Hmn, would it be useful or feasible to allow POV to read .zip files
> directly? Are there any license restrictions on .zip compression, or any
> other reason this wouldn't be done?

I don't know if there are any license restrictions on the zip format
(which, I believe, was invented by PKWare in their PKZip product).
However, if PKZip (and the zip file format) uses LZW compression,
there is indeed a huge legal stink going on. Unisys is claiming that
anyone who uses, creates, downloads, or otherwise even thinks about
any software that reads, writes, translates, or otherwise processes
practically anything that even touches LZW needs a written license
from them. Their Web site includes in this blanket statement such things
as the PDF file format used by Adobe Acrobat, Postscript-2, the
V.42bis modem technology, and others. If one were to add the ability
to read LZW-compressed material into POV-Ray, the way the Unisys site
reads, the authors of the code, the users of the resultant program,
and anyone who downloaded an image created with the code would be
liable for patent infringement litigation.

Read all about it at http://www.unisys.com/unisys/lzw

(BTW, according to the GNU Web site, this whole stink is why GNU
zip was created, to get around legal entanglements with the
compress program, which uses LZW. This is also why their site
boasts of using no GIF files, as GIF files use LZW compression.)

Post a reply to this message

Steve Martin wrote:
> 
> > Hmn, would it be useful or feasible to allow POV to read .zip files
> > directly? Are there any license restrictions on .zip compression, or any
> > other reason this wouldn't be done?
> 
> I don't know if there are any license restrictions on the zip format
> (which, I believe, was invented by PKWare in their PKZip product).
> However, if PKZip (and the zip file format) uses LZW compression,
> there is indeed a huge legal stink going on. Unisys is claiming that
> anyone who uses, creates, downloads, or otherwise even thinks about
> any software that reads, writes, translates, or otherwise processes
> practically anything that even touches LZW needs a written license
> from them. Their Web site includes in this blanket statement such things
> as the PDF file format used by Adobe Acrobat, Postscript-2, the
> V.42bis modem technology, and others. If one were to add the ability
> to read LZW-compressed material into POV-Ray, the way the Unisys site
> reads, the authors of the code, the users of the resultant program,
> and anyone who downloaded an image created with the code would be
> liable for patent infringement litigation.
> 
> Read all about it at http://www.unisys.com/unisys/lzw
> 
> (BTW, according to the GNU Web site, this whole stink is why GNU
> zip was created, to get around legal entanglements with the
> compress program, which uses LZW. This is also why their site
> boasts of using no GIF files, as GIF files use LZW compression.)

POV-Ray already uses LZW (support for GIF's as heightfields).  I'm not
sure we have a written agreement with Unisys, since that feature
predates my joining the team.  I'll ask.  If it becomes a serious
problem, we also support PNG heightfields.

POV-Ray also uses (as part of PNG support) zlib, which includes
functions that provide support for GNU zipped files.  The gzip manual
page says that gzip and PKZip both use Lempel-Ziv rather than LZW, so
that should be completely clear of problems.

That handles feasibility.  So, how useful do people think such a thing
would be?

-Mark Gordon

Post a reply to this message

Mark Gordon wrote:

> POV-Ray also uses (as part of PNG support) zlib, which includes
> functions that provide support for GNU zipped files.  The gzip manual
> page says that gzip and PKZip both use Lempel-Ziv rather than LZW, so
> that should be completely clear of problems.
> 
> That handles feasibility.  So, how useful do people think such a thing
> would be?
> 
> -Mark Gordon

I know one suggestion comes up from time to time and that is the ability
to zip image files on the fly for animation work. This is especialy true
for file types like .tga and .bmp which do not offer built in compression
methods. I have heard a couple of people mention that this can already
be done with shell commands but it would be nice if it was done internaly
to reduce cycle times during high frame count animations.

-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message