In article <47109c94@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > 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 wil
l 
> > to store 20 transforms in the object
> 
>   You don't get it, do you? Forcing a transformation array to exist in ev
ery
> single object increases memory consumption compared to objects not having
> such an array, and a separate SDL array being used only in objects which
> need it.
> 
See, I don't disagree with you about that at all. But it brings up a 
problem how how you "tell" the parser that the object you are defining 
is "supposed" to be changed later. It also doesn't address other issues.

>   If you have 10000 objects in your scene, 10 of which are IK'ed, forcing
> a transformation array to exist for every single one of the 10000 objects
> (even if those arrays are empty or contain just one transformation) is
> going to consume much more memory than if the array existed only for thos
e
> 10 IK'ed objects.
> 
>   Do you think having an empty array in an object takes no memory?
> 
>   Anyways, no array is needed, not even for IK'ed objects. How do you thi
nk
> the current POV-Ray manages without such arrays? And no, the answer is no
t
> "by reparsing every object each time".
> 
> > 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.
> 
>   Those numbers don't make any sense.
> 
Why not? Its hardly helpful to just insist they don't make sense without 
saying why. Because they are not realistic? True, but its supposed to be 
an example of what happens if you had to store "all" transforms for an 
object externally, compared to only storing those you need to change in 
an external array, and patching them into the object. My point was that 
if you do the later, you use **more** room than if you had all of them 
stored on the object, when only stored, externally, those that you 
needed to make changes to.

This is irrelevant (if) you have some way to specify which transforms on 
an object "need to" support later changes. Though, I am not sure how the 
hell that fixes it, since you can't just substitute the rotation in an 
object, or a translations, and get the same result, if the rest of the 
transform is static. It means you break interdependence of those 
transforms. I am still waiting for an example of how you avoid that 
problem, instead of just a lot of hand waving about how it isn't one.

Example, you *need* to rotate an object to some position, then move it, 
then rotate it again. That one you "could" in theory keep track of the 
transform "prior" to the final rotation, since that is probably the one 
you will be changing, but you have to "at least" keep track of that 
matrix, because the result of the final rotation is ***not*** based on 
the origin, the original location of the object, or any other simple 
condition, its *dependent* on the two prior transforms. This only gets 
worse if you, say, want the robot to fall apart, since that means you 
are likely to be making changes to a) the original translation, b) the 
original rotation, c) the final rotation, and d) anything else you did 
to it. In other words, you are right back the where you where before, 
storing all of the transforms, so that you can change "only" the one 
needed for the frames before the falling apart, then later change "all" 
of them, when it is falling apart.

> > 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 currentl
y 
> > work that way.
> 
>   What the heck are you talking about? Object-specific transformation arr
ays
> are needed to preserve the current SDL?
> 
>   The more you write, the weirder it gets.
> 
Sigh.. Your just getting it at all. The ***existing*** SDL assumes that 
each "frame" is "static", as so is the object. Its not possible in the 
current design to change the matrix for and object in "any" sense other 
than in the final object. In something like an IK chain, only the 
"main" object, which all others are a subset of, can be changed at the 
last minute, because its the only one that is "accessible", the rest are 
predetermined, having already been declared by that point, and you can't 
even do something like making a copy of the object and substituting a 
completely *different* matrix on part of it, unless you explicitly coded 
those transforms so that they are calculated, using variables, etc. And 
even then, if you made A = 10, then later A = 20, its **still** static,
 
with the value of 10, because the SDL isn't going to **go back** and 
replace 10 with 20 just before you render. Its going to use what ever 
value A had *when* it parses the object. Its *completely* static.

In an SDL that supports its own animation/render functions, you can't 
have "static" objects. They need to be changeable at any point, so that 
if you change the value of A, the new SDL can figure out that you 
**now** want the object to rotate or translate by 20, not 10. You can do 
this two ways. 1. Track the transforms for the object, then simply 
replace the one you need to change. 2. Generate a static object 
"anyway", then apply your own transform to its parts, to produce the 
result you want. Either way you are going to be using memory to do it.


But yeah, I see your point in having it static, then applying transforms 
"after" the fact. How about a sane compromise then.. Make the SDL so 
that its like:

#define fred = union{
  arm{rotate <1,2,3>
      translate <3,4,5>
      rotate <x,0,0>
      storetrans
  }
}

If you don't include the "storetrans" keyword the object is treated "as 
currently", and the result is a static object, which you "can't" 
transform anything on between frames. If you do use it, then those 
transforms are stored in an array and **only** applied just prior to the 
render step, so that you can substitute what ever changes you want, and 
**any** point in the matrix. That solves both problems. Objects that 
don't need to be animated, which hopefully is *most* of them, don't 
store anything but their static matrix, defined *when* the object is 
created. Objects that require animation will "delay" their matrix 
creation until expressly needed, so you can make any change you want to 
them. And you **still** only need to store, in your non-object linked 
array, the transform(s) you want changed, not all of them. Its a good 
compromise I think. Then again, this requires that I can first convince 
you that what I am talking about makes some sort of sense to start with. 
Again, your idea is fine, but this compromise would "still" reduce 
memory use, since for objects that require transforms to be applied 
"post initial creation" only the non-static matrices need be 
recalculated and your array only need to hold those changes "specific" 
to what you are trying to adjust, not every transform applied to the 
subobject.

Look, if you still think I am full of it, then why not agree on some 
example concept, with a specific number of parts, etc. Then each of us 
can give a psuedocode example of what the hell we are talking about, 
because I am not entirely sure I am not missing something you are trying 
to get across too.

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