 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <470cecd7@news.povray.org>, dne### [at] san rrcom 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
But this could be handled in SDL, no ? Keeping track of every
transform, and having a directive to indicate what should be
reparsed and what shouldn't...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> 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.
Errr, well, have you used Hash Animation Master? As long as you name the
bones the same there, you can apply the "walk" to anything you want.
However, you missed my point, which was that if the array is separate
from the object, you can have multiple arrays and hence multiple sets of
transformations that apply to the object at different times in the
animation. If the character walks a while, then runs a while, do you
put the walk transformations or the run transformations in the object?
If the array can be indexed by the object itself, then there's no
question in the code of the transformation being "off separate"
somewhere that's hard to find.
--
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 wrote:
> 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.
You could also assume that a render command is implicit at the end of
parsing if none is given.
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.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > 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.
It's not a question of efficiency, it's a question of not hard-coding
one specific solution where no such hard-coding is necessary at all.
(Besides, it *is* a question of efficiency too: Those arrays will
consume extra memory which is not necessary to be consumed. This may
become an issue with millions of objects.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> But this could be handled in SDL, no ?
The main problem is that this "store all transformations in an array
inside the object" is a hard-coded solution which makes no sense. It
needlessly fixes this "problem" (which really isn't a problem at all,
which is something they just cannot seem to comprehend) with one single
hard-coded solution. If someone would like to use a different approach
then the internal array would be a completely useless waste of memory.
Let's assume someone is implementing something where he really wants,
for whatever reason, to store all the individual transformations in a
data structure (instead of simply executing a series of commands which
will accumulate the transformations into a single transformation matrix).
What happens if the data structure he wants to use is a list? What if he
wants to have *several* data structures containing alternative sets of
transformations? What if he wants the transformations in a binary tree?
He will have to implement these solutions in SDL, and the transformation
array inside the object will be a useless waste of memory.
Moreover: What if, which will be the usual case, he doesn't need to
store the individual transformations anywhere? Who is going to give him
back the memory wasted by the useless internal transformation array?
The right solution is to be able, at each frame, to apply a set of
transformations to the object as function calls (which syntax is to
be decided). Internally these transformations will work as currently
in POV-Ray (ie. they are accumulated into a transformation matrix).
If someone really wants to use an array to store individual transformations
then he can do so. However, most importantly, he is not *forced* to do so
if he doesn't want to.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> But this could be handled in SDL, no ?
>
> The main problem is that this "store all transformations in an array
> inside the object" is a hard-coded solution which makes no sense. It
> needlessly fixes this "problem" (which really isn't a problem at all,
> which is something they just cannot seem to comprehend) with one single
> hard-coded solution. If someone would like to use a different approach
> then the internal array would be a completely useless waste of memory.
>
> Let's assume someone is implementing something where he really wants,
> for whatever reason, to store all the individual transformations in a
> data structure (instead of simply executing a series of commands which
> will accumulate the transformations into a single transformation matrix).
> What happens if the data structure he wants to use is a list? What if he
> wants to have *several* data structures containing alternative sets of
> transformations? What if he wants the transformations in a binary tree?
> He will have to implement these solutions in SDL, and the transformation
> array inside the object will be a useless waste of memory.
That's what I meant : implement the "transformation history" using SDL.
If the SDL is powerful enough, it could even be automatic : each time
something tranforms an object, an "event" mechanism adds the transform
to the history.
Objects could even have some kind of "extended data" that could be attached
to them, and be used as the user wishes. (it would help things like
parent-chlid relations between objects)
> If someone really wants to use an array to store individual transformations
> then he can do so. However, most importantly, he is not *forced* to do so
> if he doesn't want to.
Yep.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
