I just finished testing my latest patch, which adds inverse transforms 
to objects, textures, and anything else that can take a transform. The 
syntax is very simple, just add "inverse" in the transform {} block.

#declare Trans =
transform {
    ...
}
#declare InvTrans =
transform {Trans inverse}
Applying "transform Trans" will transform something, applying "transform 
InvTrans" will "undo" those transforms.

I added the patch in the MegaPOV 0.4 code, it only requires modifying 
the function "Parse_Transform" in parse.c.

TRANSFORM *Parse_Transform ()
{
...

   VECTOR Local_Vector;
+   int isInverse = FALSE;

   EXPECT
+     CASE(INVERSE_TOKEN)
+       isInverse = TRUE;
+     END_CASE

...

   Parse_End ();
+   if(isInverse == TRUE)
+   {
+       MInvers(New->matrix, New->matrix);
+       MInvers(New->inverse, New->inverse);
+   }
   return (New);


This brings up the next issue: this requires that the transformation be 
declared before inverse can be used. I think transform {...} blocks 
should be allowed within objects, so you could use:

object {
    transform {
        blah, blah
    }
}
instead of this:

#declare Trans =
transform {
    blah, blah
}
object {
    transform Trans
}

And of course, you should be able to "concatenate" transforms with 
multiple transform {...} blocks. I will be working on this to see how 
hard it will be to implement.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff wrote:
> 
> I just finished testing my latest patch, which adds inverse transforms
> to objects, textures, and anything else that can take a transform. The
> syntax is very simple, just add "inverse" in the transform {} block.

What purpose does an inverse tranformation serve (what does it do and
why do we need it) ?

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <3904E833.C69DE058@pacbell.net>, lin### [at] povrayorg 
wrote:

> Chris Huff wrote:
> > 
> > I just finished testing my latest patch, which adds inverse transforms
> > to objects, textures, and anything else that can take a transform. The
> > syntax is very simple, just add "inverse" in the transform {} block.
> 
> What purpose does an inverse tranformation serve (what does it do and
> why do we need it) ?

Transform Trans changes pointA into another pointB. If the inverse of 
Trans is applied to pointB, you get pointA back. It is just the reverse 
of an ordinary transformation.

BTW, I got my new syntax for transform partially working, you can now 
embed transform {} blocks in objects and in the vtransform() function. 
And the old syntax still works. I haven't made the necessary 
modifications to textures yet, though. I might try to get a cleaner way 
of doing things, there is currently many similar chunks of largely 
duplicated code.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff wrote:

> > What purpose does an inverse tranformation serve (what does it do and
> > why do we need it) ?
> 
> Transform Trans changes pointA into another pointB. If the inverse of
> Trans is applied to pointB, you get pointA back. It is just the reverse
> of an ordinary transformation.

So if I had an object at <-1,0,-1> the inverse tranformation would now
locate the object to <1,0,1> ?

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <3904F3D5.CF178365@pacbell.net>, lin### [at] povrayorg 
wrote:

> So if I had an object at <-1,0,-1> the inverse tranformation would now
> locate the object to <1,0,1> ?

No. The inverse transform moves the point in a way that would undo the 
transform. The inverse transform of "translate <-1, 0,-1>" would be 
"translate < 1, 0, 1>", but the point being transformed doesn't matter.
The inverse of rotate x*45 is rotate -x*45, the inverse of scale 0.5 is 
scale 2, and I don't feel like trying to invert a matrix right now. It 
gets more complex with multiple transforms in a row, I think you have to 
reverse each one and also reverse their order. The inverse transform 
patch makes this juggling of transforms unnecessary.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

I think that this patch is not of very much use if we can't get the
transformations from an object. You seldom define the transformations of
an object separately.
  How about a function to get the transformations applied to an object?
Something like:

#declare Trans = transformations(MyObject)

object
{ MyObject
  transform { Trans inverse }
}

  This would create an instance of MyObject without transformations.

  Of course there's a problem: What if MyObject is a CSG with nested
transformations?

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

In article <390581e3@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I think that this patch is not of very much use if we can't get the
> transformations from an object. You seldom define the transformations of
> an object separately.
>   How about a function to get the transformations applied to an object?
> Something like:
> 
> #declare Trans = transformations(MyObject)
> 
> object
> { MyObject
>   transform { Trans inverse }
> }
> 
>   This would create an instance of MyObject without transformations.
> 
>   Of course there's a problem: What if MyObject is a CSG with nested
> transformations?

I would really prefer the dot operator instead, it is shorter by 1 
character and a lot more flexible(it doesn't have the problems with CSG 
transforms).
#declare Trans = transform {transformations(MyObject)}
#declare Trans = transform {MyObject.transformations}
#declare Trans = transform {MyObject.SubObject.transformations}

However, I don't know how easy this would be...it would have to use the 
label feature, and there is probably already code that can be adapted to 
do the job in MegaPOV. The same thing would be useful for textures and 
interior.
This patch is still useful in some cases, though. We could implement 
functions to access those variables as a stop-gap measure, but I don't 
think that is a good idea...people would begin to use them, and they 
would have to be removed later.
I will check out the label code, and see if I can do anything about it.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

There's another problem. What about this:

box
{ <1,2,3>, <4,5,6>
  rotate x*30
  texture { Whatever }
  rotate y*45
}

  What will be the transformation got out of that?


  Btw: I have one idea (which has only little to do with this transformations
thing):

  In latex you can attach a label to most items, for example:

\section{Why povray is the best?} \label{First section}

  Then you can refer to that section by writing for example:

For more information, see section \ref{First section}.

  This will substitute the \ref-statement with the appropriate section number
(which may change when adding more section before that one).

  In povray this kind of labeling would just be a shortcut for first
#declaring the thing and then creating an instance of it. It would just
do both things at once.
  Then perhaps you could do something like (not necessarily with this syntax):

box \label{MyBox}
{ <1,2,3>, <4,5,6>
  transform \label{MyBoxTrans}
  { rotate x*30
  }
}

object { MyBox transform { MyBoxTrans inverse } }

  This would create two boxes. The first with transformations and the second
without.

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

In article <3905aa7f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   There's another problem. What about this:
> 
> box
> { <1,2,3>, <4,5,6>
>   rotate x*30
>   texture { Whatever }
>   rotate y*45
> }
> 
>   What will be the transformation got out of that?

transform {rotate x*30 rotate y*45}
There is only one transform struct per object, all transforms are added 
into it. The transform struct contains two matrices, this is what made 
implementing "inverse" so easy.


>   In povray this kind of labeling would just be a shortcut for first
> #declaring the thing and then creating an instance of it. It would just
> do both things at once.
>   Then perhaps you could do something like (not necessarily with this 
>   syntax):
> 
> box \label{MyBox}
> { <1,2,3>, <4,5,6>
>   transform \label{MyBoxTrans}
>   { rotate x*30
>   }
> }
> 
> object { MyBox transform { MyBoxTrans inverse } }
> 
>   This would create two boxes. The first with transformations and the 
> second without.

Maybe an "identifier" keyword could be added to everything that can be 
defined, something like this:
object {...
    identifier local LocalObject
    texture {...
        identifier global GlobalTex
    }
}

While I think all #declare and #local statements should at least allow a 
semicolon ending, I don't think one should be used here. It would be 
inconsistent with the other flags/settings.
While something like this might be handy, I don't think it is really 
necessary.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote...
>   I think that this patch is not of very much use if we can't get the
> transformations from an object. You seldom define the transformations of
> an object separately.

But if you really cared about the transformations and needed to use them
(and/or their inverse) somewhere, it would be very easy to declare the
transformations separately.  This feature, though useful, is not necessary
for the functionality of Chris' patch.

-Nathan

Post a reply to this message