Patrick Elliott wrote:
> that, "If you are going to store that stuff in an array, lets at least 
> assign the array to something that "looks" like its part of the object, 
> and not some separate entity." In other words, if you are going to apply 
> 10 transforms to object Z, then *make that array* part of the Z object, 
> *at least* from the perspective of the coder.

Why not just allow arrays that can be indexed by objects? Then you can 
have multiple arrays of transformations per object. You could have a 
"walking" array, indexed by body part, where each element is an array of 
transforms to be applied at each step of the walk cycle, then a 
"running" array indexed by body parts ....

Walking gets
object arm = cylinder(....)
object leg = blob(...)
translate(arm, walk[arm].translates[frame % 6])
rotate(arm, walk[arm].rotates[frame % 6])
translate(leg, walk[leg].mytranslate[frame % 6])

Running gets
object arm = cylinder(....)
object leg = blob(...)
translate(arm, run[arm].translates[frame % 6])
rotate(arm, run[arm].rotates[frame % 6])
translate(leg, run[leg].translates[frame % 6])

 > That way you can tell
> "what" they belong to by simply referencing the object they belong to, 
> not some arbitrary array that has no association, save that you just 
> happen to use it for that.

Arbitrary associations is the meat of programming. There's no real 
reason that a translation "belongs" more to an object than to an 
animation cycle than to a room of the house you're modeling.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Patrick Elliott nous apporta ses lumieres en ce 2007/10/10 01:42:

> I think we are talking past each other here in some respects. Yeah, I 
> agree, if they work in the sense that they should, i.e., scaling 
> "before" defining the last object in a union also scales "that" object, 
That's not a valid syntax and generate an error at the next object encountered.
You can transform any individual element.
You can transform the whole CSG object, but ONLY after every last one of it's 
elements have been included.
> not just the prior ones, then applying all transforms "after" is 
> perfectly valid. It doesn't fundamentally change my argument, which is 
> that, "If you are going to store that stuff in an array, lets at least 
> assign the array to something that "looks" like its part of the object, 
> and not some separate entity." In other words, if you are going to apply 
> 10 transforms to object Z, then *make that array* part of the Z object, 
> *at least* from the perspective of the coder. That way you can tell 
> "what" they belong to by simply referencing the object they belong to, 
> not some arbitrary array that has no association, save that you just 
> happen to use it for that.
> 
> Or is there some huge objection to making it even than simplified?
> 
> Oh, and the idea of placing each "type" of transform into a separate 
> array is more like a filter. I.e., you want to change the 3rd "scale", 
> just reference the 3rd scale in the array, even if it is "actually" the 
> 7th transform. This doesn't even need to be a separate array, just a 
> function call that counts the transforms in the main array, until it 
> gets the "nth" transform of the type requested. In other words, 
> something like:
> 
> function translate(n)
>   c = -1
>   for each temp in self.transforms
>     if type(temp) = "translate" then
>       c = c + 1
>     end if
>   next
>   if c > -1 then
>     return c
>   else
>     return -1
>   end if
> end function
> 
> "transforms" being the "array" that is used to track "all" transforms 
> applied to that object in the original SDL step that created it, which 
> would be identical to the existing SDL. This doesn't prevent you adding 
> new transforms, either via the existing SDL method, or via the object 
> reference, or even *deleting* one that was previously applied (which 
> isn't currently possible).
> 
> Hope that is clearer.
> 
You obviously miss a fundamental point: there is only ONE transform matrix per 
object that contain the SUMATION of every single transforms applyed to that 
object. There is no transform array, there never was any such thing.
Using an array of transforms would be wastefull. It would uselessly use extra 
memory. It would make rendering slow as the whole array will need to be computed 
for every ray that encounter the object, as well as any CSG operation that use 
that object. That array will need to be dynamic as you can never tell beforehand 
how many transforms will be applyed to any particular object, adding some 
useless overhead, and requiring still more memory.

-- 
Alain
-------------------------------------------------
Don't waste your time on a man/woman, who isn't willing to waste their time on you.

Post a reply to this message

Alain wrote:
> You obviously miss a fundamental point: there is only ONE transform 
> matrix per object that contain the SUMATION of every single transforms 
> applyed to that object. There is no transform array, there never was any 
> such thing.

I'm amazed at the number of people arguing
"This is how the next one should be."
"No, this is how the current one is."
"But this is how the *next* one should be."
"Don't you understand this is how the current one *is*?"

> Using an array of transforms would be wastefull. It would uselessly use 
> extra memory.

It's only useless if you don't need it.

> It would make rendering slow as the whole array will need 
> to be computed for every ray that encounter the object, 

Nonesense. Once the tracing starts, you compute the final transformation 
matrix, just like you do now when there are multiple transforms.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:470cf833$1@news.povray.org...
> Alain wrote:
>> You obviously miss a fundamental point: there is only ONE transform 
>> matrix per object that contain the SUMATION of every single transforms 
>> applyed to that object. There is no transform array, there never was any 
>> such thing.
>
> I'm amazed at the number of people arguing
> "This is how the next one should be."
> "No, this is how the current one is."
> "But this is how the *next* one should be."
> "Don't you understand this is how the current one *is*?"

that's not how it is, it's more like this:

"This is how the next one should be."
"No, this is how the current one is, and there's absolutely no reason why 
that particular part should change."
"But this is how the *next* one should be."
"You really don't understand why the current one is the way it is, do you?"

If you ask me, keeping an array of transformations makes it all needlessly 
complicated. If you want such an array, define it yourself in SDL, there's 
absolutely no need for it in the POV-core.

In my opinion, the main idea of the new SDL should be to seperate the 
core-functionality from the user-definable functionality.  At the very base 
of the rendering-process, having an array of transformations is simply 
ridiculous.  If users want such an array, then I'm sure someone will write 
an inc-file (or whatever) that makes this possible and even easy to do.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> What I was saying is that we should distinguish between the 'first 
> creation' and the 'final creation'. Calling both simply 'creation' will
 
>   lead to confusion (as shown is this thread. Much of what you and 
> Patrck are writing does not make sense to me, because for me 'creation'
 
> is 'final creation').
> 
How about "intermediary" creations then, just to confuse things more. 
lol Technically, by your definition, the object is never "created" until 
the frame in rendered, at least in any system like we are talking about, 
where each "frame" is defined not by re-running the entire script, but 
only via the command "in" the script.

In other words, in the current model we do this:

render("myfile")

in a true animation system, we do this:

'Set up a bunch of objects.
...
render
'Change the objects some.
...
render
'Change them some more.
...
render

The "render" step is explicit in the script, since it only happens 
"when" all the changes are made, not an external process that just runs 
an SDL through it, and recalcs the data for everything as it does it, 
based on the existing clock scheme, which is kind of limited. Mind you, 
making that change, depending on how it was done, could break existing 
SDL. Mind you, a command that "requests" the prior behavior could be 
used to solve that. Note, allowing a "render" command to explicitly tell 
it when you are ready to render the result means you could simply do:

light {...}
camera {...}
plane {...}
object1 {...}
render
object2 {...}
render
...

And produce a frame by frame set of changes. Could be useful for 
debugging too. Not sure what is causing a problem, go through one object 
at a time, until you find a frame where the problem crops up.

Note: Obviously one thing you can do with this is make the "render" 
command do several things. If you haven't set any animation/clock 
parameters, then it generates the same name each time. If you have set 
them, it increments a frame count each time you use it, while also 
incrementing the clock by the predefined amount. Obviously, to limit the 
need for the definition files currently used, since you might want 
better control over things, you would want clock data 
accessable/changable via something like:

clock.state - on/off
clock.start_frame
clock.frame
clock.end_frame
clock.increment

Same possibly even with things like the render size, etc.

You could conceivably even allow "render" to also allow "render
(frame_number, fill)". I.e., if you want to freeze frame, instead of 
generating 10 identical frames you just change the "frame" you are on, 
then specific that everything between "last frame" and "current frame" 
gets filled with the last rendered image.

Mind you this could be done, in *some* software by just telling that to 
duplicated those frames, but not all of them will do that, and if at 
some point someone added a stream encoder to POVRay, being able to 
explicitly tell it that frames 5-15 are duplicates would speed up the 
process of both generating those frames "and" encoding them, the encoder 
could just be told, by the engine, to encode the same "frame" ten times, 
at the frame rate it was already given. No additional "data" need be 
produced.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <470ced0a$1@news.povray.org>, ele### [at] netscapenet 
says...
> Patrick Elliott nous apporta ses lumieres en ce 2007/10/10 01:42:
> 
> > I think we are talking past each other here in some respects. Yeah, I
 
> > agree, if they work in the sense that they should, i.e., scaling 
> > "before" defining the last object in a union also scales "that" object,
 
> That's not a valid syntax and generate an error at the next object encoun
tered.
> You can transform any individual element.
> You can transform the whole CSG object, but ONLY after every last one of 
it's 
> elements have been included.
> > not just the prior ones, then applying all transforms "after" is 
> > perfectly valid. It doesn't fundamentally change my argument, which is
 
> > that, "If you are going to store that stuff in an array, lets at least
 
> > assign the array to something that "looks" like its part of the object,
 
> > and not some separate entity." In other words, if you are going to appl
y 
> > 10 transforms to object Z, then *make that array* part of the Z object,
 
> > *at least* from the perspective of the coder. That way you can tell 
> > "what" they belong to by simply referencing the object they belong to,
 
> > not some arbitrary array that has no association, save that you just 
> > happen to use it for that.
> > 
> > Or is there some huge objection to making it even than simplified?
> > 
> > Oh, and the idea of placing each "type" of transform into a separate 
> > array is more like a filter. I.e., you want to change the 3rd "scale",
 
> > just reference the 3rd scale in the array, even if it is "actually" the
 
> > 7th transform. This doesn't even need to be a separate array, just a 
> > function call that counts the transforms in the main array, until it 
> > gets the "nth" transform of the type requested. In other words, 
> > something like:
> > 
> > function translate(n)
> >   c = -1
> >   for each temp in self.transforms
> >     if type(temp) = "translate" then
> >       c = c + 1
> >     end if
> >   next
> >   if c > -1 then
> >     return c
> >   else
> >     return -1
> >   end if
> > end function
> > 
> > "transforms" being the "array" that is used to track "all" transforms
 
> > applied to that object in the original SDL step that created it, which
 
> > would be identical to the existing SDL. This doesn't prevent you adding
 
> > new transforms, either via the existing SDL method, or via the object
 
> > reference, or even *deleting* one that was previously applied (which 
> > isn't currently possible).
> > 
> > Hope that is clearer.
> > 
> You obviously miss a fundamental point: there is only ONE transform matri
x per 
> object that contain the SUMATION of every single transforms applyed to th
at 
> object. There is no transform array, there never was any such thing.
> Using an array of transforms would be wastefull. It would uselessly use e
xtra 
> memory. It would make rendering slow as the whole array will need to be c
omputed 
> for every ray that encounter the object, as well as any CSG operation tha
t use 
> that object. That array will need to be dynamic as you can never tell bef
orehand 
> how many transforms will be applyed to any particular object, adding some
 
> useless overhead, and requiring still more memory.
> 
And you are missing the point that you can't functionally work things 
that way in animation. Lets put it any other way, you have a matrix:

|0 0 0 1|
|4 3 1 0|
|1 0 2 3|
|5 2 3 0|

Or something, this is just random made up, but it serves the point. 
Where in that matrix is the "rotate this after moving it to point X, so 
that it acts like an arm, instead of rotating at the object center"? 
Even if you revert, you **still** have to then move it to the point on 
the object needed to rotate it, before also doing what ever else you 
need to make it work right. The fact that the cumulative matrix contains 
everything done to that point is ****meaningless**** from the standpoint 
of animation, because when animating you don't give a frack what the 
"final" result is, you want to render based on intermediary results, 
which changes that matrix "for every frame". If you revert it, you still 
have to keep track of what transforms you did, and in what order, so 
that you get the right matrix, which means you are **still** using up 
the memory to keep track of them in some fashion, while your seem to 
imagine that you can just wave a magic wand and have the memory issue go 
away. Either way, you have to reapply all the transforms "in each 
frame". I don't see how storing those in something that references them 
as part of the object they belong to does "anything" to change how much 
memory ends up being used.

Basically, you are still thinking in terms of a script that goes through 
in one pass, producing one "single" final result, which has to be 
rebuilt in the next frame. All objects in a script that doesn't reparse 
"never" reach that "complete" state you are going on about, they are in 
continual transition, so its not possible to just generate a static 
matrix, which automatically solves every problem. You still have to 
change that matrix in a way that produces the result you want, which 
isn't practical if you are working with an already transformed objects, 
which has multiple changes to the matrix, all of them interdependent on 
each other. And, even if you are right, I have yet to see you provide 
any example to prove either of us discussing the issue from our side of 
the line with proof that you are right and we don't get it. In fact, the 
only solution you can come up with is basically the same thing we are 
already saying, just separated from the object.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <470cecd7@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > that, "If you are going to store that stuff in an array, lets at least
 
> > assign the array to something that "looks" like its part of the object,
 
> > and not some separate entity." In other words, if you are going to appl
y 
> > 10 transforms to object Z, then *make that array* part of the Z object,
 
> > *at least* from the perspective of the coder.
> 
> Why not just allow arrays that can be indexed by objects? Then you can 
> have multiple arrays of transformations per object. You could have a 
> "walking" array, indexed by body part, where each element is an array of
 
> transforms to be applied at each step of the walk cycle, then a 
> "running" array indexed by body parts ....
> 
> Walking gets
> object arm = cylinder(....)
> object leg = blob(...)
> translate(arm, walk[arm].translates[frame % 6])
> rotate(arm, walk[arm].rotates[frame % 6])
> translate(leg, walk[leg].mytranslate[frame % 6])
> 
> Running gets
> object arm = cylinder(....)
> object leg = blob(...)
> translate(arm, run[arm].translates[frame % 6])
> rotate(arm, run[arm].rotates[frame % 6])
> translate(leg, run[leg].translates[frame % 6])
> 
Umm. Because it doesn't make much sense? Seriously, any such transforms 
are going to be "very" specific to the IK chain of the particular object 
you are working with. There is no point in making an array called 
"walk", which contains the needed transforms, instead of making it part 
of the object, because logically it can't be applied to any "other" 
objects. The only argument that could be made is that you might want 50 
marching robots, which all move the same way. If you plan to add any 
sort of variability in their motion though, you run into the same 
problem, no single set of transforms will be applicable to "every" IK 
chain in those 50, so trying to apply the same one to all of them won't 
work.

This does present an issue though. Its true that storing these "will" 
hog memory. The simplest solution is to store a master list, which 
includes calls to a function that can vary the motion, dependent on the 
objects ID, of some sort. In other words, instead of storing something 
like: arm.transform(6)="rotate <4,5,3>", you store arm.transform(6)
="rotate <calc_angle(self.ID),5,3>", where calc_angle would get the 
"frame" number from the animation object, check the ID, then figure out 
what its supposed to do from that.

In a sense, when rendering, no object ever "completes" its creation 
cycle until the final parse happens. All objects exist, with "blank" 
transform matrices, **until** you call "render" at which point the 
"script" inside the array is played out for each level, starting at the 
deepest, until a final matrix for each object is completed, *then* the 
render happens. I don't see how else you handle it and *still* preserve 
the current SDL model. You can't simply revert, without replaying the 
transforms anyway, nor can you just toss a new one in, and hope that 
somehow the engine will produce the result you wanted. You have to delay 
final creation "until" you inform the engine that you want it to render 
the result.

Again, as with my prior post on that, a scene marked to use the "old" 
behavior wouldn't do that, it would complete, then render. In a scripted 
animation though, "complete" when talking about the state of an object 
is either referring to one where the types and number of transforms are 
"intentionally" limited, or its a real fuzzy concept, at best. lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <470cf833$1@news.povray.org>, dne### [at] sanrrcom says...
> Alain wrote:
> > You obviously miss a fundamental point: there is only ONE transform 
> > matrix per object that contain the SUMATION of every single transforms
 
> > applyed to that object. There is no transform array, there never was an
y 
> > such thing.
> 
> I'm amazed at the number of people arguing
> "This is how the next one should be."
> "No, this is how the current one is."
> "But this is how the *next* one should be."
> "Don't you understand this is how the current one *is*?"
> 
> > Using an array of transforms would be wastefull. It would uselessly use
 
> > extra memory.
> 
> It's only useless if you don't need it.
> 
> > It would make rendering slow as the whole array will need 
> > to be computed for every ray that encounter the object, 
> 
> Nonesense. Once the tracing starts, you compute the final transformation
 
> matrix, just like you do now when there are multiple transforms.
> 
> 
Thank you. A force of reason. lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <470d186a$1@news.povray.org>, zeg### [at] povplacecom 
says...
> "Darren New" <dne### [at] sanrrcom> wrote in message 
> news:470cf833$1@news.povray.org...
> > Alain wrote:
> >> You obviously miss a fundamental point: there is only ONE transform 
> >> matrix per object that contain the SUMATION of every single transforms
 
> >> applyed to that object. There is no transform array, there never was a
ny 
> >> such thing.
> >
> > I'm amazed at the number of people arguing
> > "This is how the next one should be."
> > "No, this is how the current one is."
> > "But this is how the *next* one should be."
> > "Don't you understand this is how the current one *is*?"
> 
> that's not how it is, it's more like this:
> 
> "This is how the next one should be."
> "No, this is how the current one is, and there's absolutely no reason why
 
> that particular part should change."
> "But this is how the *next* one should be."
> "You really don't understand why the current one is the way it is, do you
?"
> 
> If you ask me, keeping an array of transformations makes it all needlessl
y 
> complicated. If you want such an array, define it yourself in SDL, there'
s 
> absolutely no need for it in the POV-core.
> 
> In my opinion, the main idea of the new SDL should be to seperate the 
> core-functionality from the user-definable functionality.  At the very ba
se 
> of the rendering-process, having an array of transformations is simply 
> ridiculous.  If users want such an array, then I'm sure someone will writ
e 
> an inc-file (or whatever) that makes this possible and even easy to do.
> 
> cu!
> 
Your seriously missing the point. Sure, you could just create an array, 
but we are looking at how you A) maintain the syntax while B) also 
supporting **real** animation and flexibility in a new SDL. Lets put it 
simpler. Right now, if you used SDL like the following certain things 
will happen:

object {
  foot{some_transforms}
  low_leg{some_transforms}
  top_leg{some_transforms}
  some_transforms
}

The parser is going to "immediately" perform each transform 
"statically" to each sub object, then to the final one, parse the rest 
of the script, then render. You *can't* do it that way in a SDL/script 
that doesn't exit, it has to be able to handle the "final" creation 
"just before" the render, so you can make changes from frame to frame, 
without reparsing the entire file. What I would be proposing is:

object {
  foot{some_transforms} // Object created, transforms stored in 
foot.transforms.
  low_leg{some_transforms} // Object created, transforms stored in 
low_leg.transforms.
  top_leg{some_transforms} // Object created, transforms stored in 
top_leg.transforms.
  some_transforms //Final transforms still stored, since they may 
contain things "dependent" on function calls or variables, which may 
change.
}
 // Transform functions stepped through for every object, generating 
**this** frames transformation matrices, then the engine renders the 
result.
render
top_leg.transform(2)="rotate <5,0,0>" // Change position of the leg.
// Again, the matrices are created for "this" frame, then rendered.
render

Mind you, a good system will also flag object that do change between 
frames, so only those objects that "need" to have there matrix 
recalculated have it done. Noting too that those containing "variables" 
instead of specific locations must always be recalculated (since the 
variables could change). That won't slow things down, it will bloody 
speed them up, for all objects that don't have "calculated" rotations, 
translations, etc., since the last thing you want to do is recalculate 
the transform matrix for 500 static objects that "don't move" between 
one frame and the next, if all you want to do is make the robot take a 
step. The current SDL has to recalculate ***every*** matrix for 
***every*** frame. Memory be damned. Yes, it "might" take more, 
depending on if some shortcut does/doesn't exist to help avoid that 
issue, but you can't fix the limitation that exists in how the current 
SDL works by pretending it doesn't exist at all, or that you can fix it 
by without changing how the parser/engine works.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:

>> 
> And you are missing the point that you can't functionally work things
> that way in animation. Lets put it any other way, you have a matrix:
> 
> |0 0 0 1|
> |4 3 1 0|
> |1 0 2 3|
> |5 2 3 0|
> 
> Or something, this is just random made up, but it serves the point.
> Where in that matrix is the "rotate this after moving it to point X, so
> that it acts like an arm, instead of rotating at the object center"?
> Even if you revert, you **still** have to then move it to the point on
> the object needed to rotate it, before also doing what ever else you
> need to make it work right. The fact that the cumulative matrix contains
> everything done to that point is ****meaningless**** from the standpoint
> of animation, because when animating you don't give a frack what the
> "final" result is, you want to render based on intermediary results,
> which changes that matrix "for every frame". If you revert it, you still
> have to keep track of what transforms you did, and in what order, so
> that you get the right matrix, which means you are **still** using up
> the memory to keep track of them in some fashion, while your seem to
> imagine that you can just wave a magic wand and have the memory issue go
> away. Either way, you have to reapply all the transforms "in each
> frame". I don't see how storing those in something that references them
> as part of the object they belong to does "anything" to change how much
> memory ends up being used.
> 
> Basically, you are still thinking in terms of a script that goes through
> in one pass, producing one "single" final result, which has to be
> rebuilt in the next frame. All objects in a script that doesn't reparse
> "never" reach that "complete" state you are going on about, they are in
> continual transition, so its not possible to just generate a static
> matrix, which automatically solves every problem. You still have to
> change that matrix in a way that produces the result you want, which
> isn't practical if you are working with an already transformed objects,
> which has multiple changes to the matrix, all of them interdependent on
> each other. And, even if you are right, I have yet to see you provide
> any example to prove either of us discussing the issue from our side of
> the line with proof that you are right and we don't get it. In fact, the
> only solution you can come up with is basically the same thing we are
> already saying, just separated from the object.
> 

I'm not all that technical as far as Povray goes, but I have made quite a
few animations of robot arms (industrial ones) with multiple joints and
tools. I never had a need for an array of transformations but always
applied transforms "from the hand back".
Sorry, can't show any code here but it's basically something like :
object { Hand rotate x * Something }
object { Wrist rotate z * SomethingElse }
object { LowerArm rotate z * AnotherSomething }
object { UpperArm rotate z * AnotherSomethingTo }
object { Shoulder rotate z * JetMoreSomething }
object { Base rotate y * Avalue }

In the end the Hand object goes through a bunch of transforms that will put
it where I want it
-- 
Ger

Post a reply to this message