Warp <war### [at] tagpovrayorg> wrote...
>   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 } }
>

There are problems with this approach (by which I mean using labeling to
#declare and create an instance).  The problems are these:

1) memory consumption.  If you #declare and then make an instance, you have
two copies of the object in memory.  One copy is created in the symbol table
when you #declare it.  The second copy is created when you make an instance
of the object.  The first copy remains in the symbol table in case you want
to make another instance.  If you did this with too many objects (or just a
few large objects) in a scene, it would be very bad.

2) ambiguity.  Because there are two copies of object "MyBox", if you tried
to access an attribute of MyBox, which would it access -- the copy in the
symbol table or the copy in the scene.  That one might be a bit too easy to
answer, so what if you were able to modify "MyBox", such as adding a new
transform or texture -- then which copy would be modified, and how would it
affect past and future instances?

These issues could be resolved, but it would not at all be easy to do so
with the current POV code.  I ran into these same problems when dealing with
labels for persistent scenes for animations.

-Nathan

Post a reply to this message

Suppose that I have this:

#declare MyObject=
  box
  { 0, 1
    rotate x*30
    texture { Whatever }
    scale <1,.5,1> translate x*10 rotate y*60
  }

  How should I declare the transformations so that I could apply them to
MyObject as above and the use the sum of all those transformations (for
example inverted)?

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

Warp <war### [at] tagpovrayorg> writes:

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

A further problem is that this doesn't work with the recent patche of
"plane" and "triangle". As far as I know, the transformations are omitted
by the patch to increase the rendering speed.

Thomas
-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

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

>   Suppose that I have this:
> 
> #declare MyObject=
>   box
>   { 0, 1
>     rotate x*30
>     texture { Whatever }
>     scale <1,.5,1> translate x*10 rotate y*60
>   }
> 
>   How should I declare the transformations so that I could apply them to
> MyObject as above and the use the sum of all those transformations (for
> example inverted)?

#declare TransA = transform {rotate x*30}
#declare TransB = transform {scale <1,.5,1> translate x*10 rotate y*60}
#declare InvTrans =
transform {
    transform {TransA}
    transform {TransB}
    inverse
}

#declare MyObject=
box { 0, 1
    transform {TransA}
    texture { Whatever }
    transform {TransB}
}

Using the additional syntax of my patch, of course.

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

On Tue, 25 Apr 2000 11:06:46 -0500, Chris Huff wrote:
>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.

Trick question: what's the transform matrix for the sphere in

sphere {
  0, 2
  translate <1,0,1>
  scale 2
}

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
These are my opinions.  I do NOT speak for the POV-Team.

Post a reply to this message

In article <slr### [at] linuxparkerrfwicom>, 
ron### [at] povrayorg wrote:

> Trick question: what's the transform matrix for the sphere in
> 
> sphere {
>   0, 2
>   translate <1,0,1>
>   scale 2
> }

NULL

The translate value is added to the position in this case, and the 
transform structure isn't even created, so the matrix doesn't exist. 
Right?

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

In article <39061954@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> 1) memory consumption.  If you #declare and then make an instance, 
> you have two copies of the object in memory.  One copy is created in 
> the symbol table when you #declare it.  The second copy is created 
> when you make an instance of the object.  The first copy remains in 
> the symbol table in case you want to make another instance.  If you 
> did this with too many objects (or just a few large objects) in a 
> scene, it would be very bad.

I don't see this as being a huge problem...you would get the same by 
#declaring the object, wouldn't you?


> 2) ambiguity.  Because there are two copies of object "MyBox", if you 
> tried to access an attribute of MyBox, which would it access -- the 
> copy in the symbol table or the copy in the scene.  That one might be 
> a bit too easy to answer, so what if you were able to modify "MyBox", 
> such as adding a new transform or texture -- then which copy would be 
> modified, and how would it affect past and future instances?

This is a bigger problem. I would say the variable is separate from the 
object in the scene, so you would always manipulate the one in the 
symbol table. Otherwise, you would sometimes be manipulating one of the 
in-scene copies(of which there could be many), and sometimes the one in 
the symbol table(when there aren't any in the scene). Future instances 
would reflect changes made.


> These issues could be resolved, but it would not at all be easy to do 
> so with the current POV code.  I ran into these same problems when 
> dealing with labels for persistent scenes for animations.

They would definitely be hard to fix...hopefully, during the C++ 
rewrite, these things could at least be planned for.

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