![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3906b3c9@news.povray.org>, Warp <war### [at] tag povray org>
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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 25 Apr 2000 11:06:46 -0500, Chris Huff wrote:
>In article <3905aa7f@news.povray.org>, Warp <war### [at] tag povray org>
>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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <slr### [at] linux parkerr fwi com>,
ron### [at] povray org 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39061954@news.povray.org>, "Nathan Kopp" <Nat### [at] Kopp com>
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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |