> 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

Warp wrote:
> 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.

Sure. I'm not the one advocating that every object gets such an array. 
:-) I'm just pointing out that some of the objections are mistaken. 
Arrays you can index by objects and into which you can store anything 
(including transformations) would seem to be the obvious way to go.

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

In article <470dbc43$1@news.povray.org>, dne### [at] sanrrcom says...
> 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 objec
t 
> > 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.
> 
But, nothing is stopping you from trading out the arrays, like you would 
with any other similar case. And yeah, I covered the issue with applying 
the "same" walk to anything you want. 1) it wouldn't really work, unless 
it had identical parts, and 2) for realistic animation of anything other 
than marching robots, its not applicable, since you never want two 
objects behaving 100% identically to each other.

Ok, lets get at a practical example. Lets say all you have is a sphere 
and torus. The torus is rotated a bit out of the plane of rotation. The 
initial design would look like (not checking the code, so I hope it 
comes out close. lol):

#define wobble = union{
  sphere {<0,0,0>, 1}
  torus {<0,0,0>, .5, 2> rotate <.1,0,0>
  texture{blah}
  rotate <0,clock,0>
  translate <56,43,12>
}
                    
This makes an object that, from the code perspective, looks like:

wobble
  \-sphere
    \-location
    \-size
  \-torus
    \-location
    \-size
    \-transforms
      \-[0] rotate <.1,0,0>
  \-texture
    \-...
  \-transforms
    [0] rotate <0, clock, 0>
    [1] translate <56,43,12>

This "continues" to be the way it works for 10 frames. Then you "keep" 
the rotation, but also change the angle of the torus (over 10 more 
frames).

toruschange[0] = "rotate <.1 * (20-10/10),0,0>"
toruschange[0] = "rotate <0,0,0>"
wobble.torus.transforms[0] = toruschange[0]

Then at frame 21 you "stop" both the rotation and the change to the 
torus, but send the object zipping down some 3D path:

z = clock //Lets say its now also 21.
main_trans[0] = "rotate <0,z,0>"
main_trans[1] = "translate GetLocation()"
wobble.torus.transforms[0] = toruschange[1]
wobble.transforms = main_trans

In this case z, unless you change it, will "remain" 21, so from then on 
you don't need to update anything in the object, and "GetLocation" 
returns a "path" that the object is going to follow, so that is 
automatically recalculated each frame, before the render happens.

You saving memory this way, because you **don't** have to change any 
transforms that you don't have to, while your way requires they all be 
stored, even the ones that don't change. Further, the "initial" state is 
"stored" in the object, so if instead you wanted wobble to do nothing 
but sit in one place through the entire animation, without ever changing 
its behavior, you don't ever have to do anything more than set use the 
SDL to tell it to use the clock value the determining how much to rotate 
it each frame.

Note, it might be useful to allow the "clock" to return both an integer 
of all "seconds" that have passed, as well as things like clock.seconds, 
clock.minutes, etc. Just for the sake of only having to do, "rotate <0, 
clock.seconds * 6, 0>", instead of something like "rotate <0, mod(clock 
/ 60) * 60, 0>". Mind, that isn't that bad, but a more direct way to get 
the number might be nice anyway, especially if you are incrementing the 
time by a large factor, like for time lapse or something.

-- 
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 <470dec42@news.povray.org>, war### [at] tagpovrayorg says...
> 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 transformatio
n 
> > 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.)
> 
Your solution **still** requires extra arrays, or code, or **some** way 
to get the changing data "to" the object to transform it. If anything, 
as I try to explain in another post, your method is actually **more** of 
a memory hog. You keep claiming that you can just somehow "untransform" 
the matrix, or change it later, even when doing something like 
translate->rotate->translate irrevocably creates conditions where its no 
longer as simple as just adding one new rotation. Some how you have to 
both save memory "and" provide a way to change interdependent 
transforms, which, unless you are a fracking mathmatician, isn't going 
to be practical. any solution you come up with, at minimum, is going to 
require some transforms to be user changable, after the fact, and 
keeping **all** of them in an array, to be applied later, is **worse** 
that keeping all the of the initial states on the object, then just 
changing the one you actually need to.

I haven't seen any argument from you that does a thing to truly address 
that issue.

-- 
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 <470ec586$1@news.povray.org>, dne### [at] sanrrcom says...
> Warp wrote:
> > 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 transformati
on 
> >> 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.
> 
> Sure. I'm not the one advocating that every object gets such an array. 
> :-) I'm just pointing out that some of the objections are mistaken. 
> Arrays you can index by objects and into which you can store anything 
> (including transformations) would seem to be the obvious way to go.
> 
Why? Its going to cost you more memory to store 20 transforms for an IK 
chain, and all changes needed for them, in separate arrays, than it will 
to store 20 transforms in the object, then apply only 3-4 changes from 
"your" array, which are needed to change the specific parts that are 
needed. One uses, lets say 20*5, just to pick an arbitrary number for 
the storage needed, + 4*5*number of changes. Yours requires 20*5*number 
of total changes you need. If the number of changes are say 10, then 
mine takes 20*5 + 4 * 5 * 10 = 300, yours takes 20*5*10 = 1,000. How th
e 
heck is that "better"? Mind you, this is a "simple" example. It only 
gets worse if it something that has 10 IK change points, and 90 objects. 
In that case its 90 * 5 * 10, or 4500 for you, and 90 * 5 + 10 * 5 * 10, 
or 950 for mine. Its only *equal* if every object has to have "every" 
transform changed between frames, and thus all of them replayed into the 
object. The more objects that are part of the IK design, the more insane 
your number gets, while mine only grows depending on the number of 
"specific" transforms you need to change during animation, plus the 
total number of original transforms.

Yes, it would be nice to have a solution that doesn't require any such 
thing to start with, and you can get by with that, to some extent, by 
having a function call to something that determines the next change, 
instead of a straight change. I have not however seen anything to 
convince me that "some" sort of solution similar to this isn't needed. 
At least not unless you throw out the entire old SDL and force everyone 
to use "your" solution to apply all the transforms all at once, every 
frame, which means abandoning the original SDL, since it can't currently 
work that way.

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