Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> 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.

  Why do objects need a transformation history? Why would you waste memory
in such a thing?

  The current SDL does not need a "transformation history" nor does the
new one. That's because the SDL code itself is the "transformation history".
Why do you need to store it in two places?

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

  Why waste memory in something which will seldom be used?

  Wouldn't it be better to make a SDL where you can create a new version
of the object with the "extended data" instead? That way if you have
100000 objects in your scene and only one of them needs the "extended data",
memory is not wasted for useless "extended data" in those 99999 other
objects.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Patrick Elliott <sel### [at] rraznet> wrote:
> > I haven't seen any argument from you that does a thing to truly address
> > that issue.
>
>   That's because you have a misunderstanding about how transformations work.
>
>   Answer me this: Why the current POV-Ray doesn't need object-specific
> transformation arrays?
>   The answer is not "because it re-parses the objects at each frame".
> That re-parsing could perfectly be skipped with the proper syntax changes.
>
> --
>                                                           - Warp

Appart from this (somewhat sterile) passionate discussion, the problem of
animation-specific features and releted syntax seems to be a major concern
for POV4. I encourage other people here to search for ideas and make
propositions. Patrick proposed something, Warp disagrees, and both argue.
OK, fine.

Now, are there here experienced people that could give us some additional
advise and share their knowledge to help us find our way? Warp, you seem to
have theoretical skills and experience, more than many of us. How would you
envision things if you were to design the new language?

Bruno

Post a reply to this message

Bruno Cabasson wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> Patrick Elliott <sel### [at] rraznet> wrote:
>>> I haven't seen any argument from you that does a thing to truly address
>>> that issue.
>>   That's because you have a misunderstanding about how transformations work.
>>
>>   Answer me this: Why the current POV-Ray doesn't need object-specific
>> transformation arrays?
>>   The answer is not "because it re-parses the objects at each frame".
>> That re-parsing could perfectly be skipped with the proper syntax changes.
>>
>> --
>>                                                           - Warp
> 
> Appart from this (somewhat sterile) passionate discussion, the problem of
> animation-specific features and releted syntax seems to be a major concern
> for POV4. I encourage other people here to search for ideas and make
> propositions. Patrick proposed something, Warp disagrees, and both argue.
> OK, fine.
> 
> Now, are there here experienced people that could give us some additional
> advise and share their knowledge to help us find our way? 

I tried to explain my views in my oct 9 22:47 post in this thread.
( 
http://news.povray.org/povray.general/message/%3C470BE8E1.80902%40hotmail.com%3E/#%3C470BE8E1.80902%40hotmail.com%3E

)
Not much needs to be added to the current implementation of the objects 
and how we define them. There is no need to break the definition of any 
existing SDL object.

For animation to be more simply handled it is enough if we get some 
access to subparts of an object and their current transformation matrix.
For this to work there must be a way to name subparts of an object, 
because we would like to say Human.LeftArm.ForeArm.rotate(<10,0,0>) That 
would mean that the SDL syntax has to be expanded slightly e.g. like

Human=union{
   Head=union{
     sphere{...}
     ...}
   }
   LeftArm=union{
     ...
   }
   RightArm=union{
     ...
   }
   ...
}

(unless the '=' would cause trouble during parsing, then ':' might do.)
If the (optional) name is left out it should default to a predictable 
name e.g. __Child[N] So, to get a bigger head we could write: 
Human.Head.__Child1.scale{1.5)

Possibly the base of the default name could even be name of the object, 
  resulting in Human.Head.sphere1.scale(1.5) and the right arm may be 
accessible as Human.union3, but I cannot see if that would screw up the 
parsing or not.

Post a reply to this message

Patrick Elliott wrote:
> In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
> says...
>> 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.
>>
> Yes, I had considered that, but its better to have a compatibility flag, 
> both so that someone doesn't try to run an old SDL, then wonder why it 
> didn't work right, and so that someone using a *new* SDL could be warned 
> that they forgot to actually render anything. Its kind of a toss up 
> though.
> 
There could be a problem with a compatibility flag if someone is 
including some old code. Then again the #version 3.6; compatibility flag 
never gave problems. Actually, as you might have noticed, I would prefer 
a 'camera(Scene)' kind of syntax in stead of a 'render' command for many 
reasons (some not even mentioned anywhere yet). Which points more to a 
compatibility flag than an implicit 'render' command.

Post a reply to this message

Patrick Elliott 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 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.

Then store it as two arrays.

The only difference is whether one of the arrays is "in the object" 
being transformed or not.

What's the semantic difference between having an array pointer 
associated with each object to store transforms and having an array 
indexed by object whose values are arrays of transforms?

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

You're trying to evaluate the efficiency of code that was thrown off as 
an exemplar of what I was expressing. That's rarely a productive analysis.

> Its only *equal* if every object has to have "every" 
> transform changed between frames, and thus all of them replayed into the 
> object.

And if not, then you code multiple arrays in SDL: One for the transforms 
that change, one for the transforms that don't.

Think about this before answering: What's the benefit of having one 
array of transforms assigned to every object, vs having arrays indexed 
by objects that can have arrays of transforms assigned as values?

-- 
   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:
> Gah!! This is exactly what I am talking about. And everyone else is 
> instead saying, "Gosh, this is silly, why not just store every single 
> transform some place else, so it takes up even more memory, then apply 
> them all over again anyway, not from the history, but from a bunch of 
> arrays?" Feel like I am talking to a wall here.

Honestly, you're not being very clear about why you think your method is 
superior.  You might have something, but without transferring the ideas 
from your head to the keyboard, it's difficult to see why your mechanism 
is better.

-- 
   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:
> and so that someone using a *new* SDL could be warned 
> that they forgot to actually render anything. 

Having used systems where the name under which they're invoked makes a 
difference between whether the interpret enters a GUI event loop or runs 
as a straight-through execution and exits, I can say that it's probably 
a mistake to do that. The maintainers of the interpreter feel the same 
way, and moved the event loop into a loadable package with the 
requirement you start it when you're ready.

Having said that, perhaps a command-line option that says "No, really, 
render whatever you have when you get to the end of the input" would be 
a good idea, for people who are building a library or something and want 
to see how it looks during development.

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

In article <4710eb4d$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott 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, then apply only 3-4 changes from
 
> > "your" array, which are needed to change the specific parts that are 
> > needed.
> 
> Then store it as two arrays.
> 
> The only difference is whether one of the arrays is "in the object" 
> being transformed or not.
> 
> What's the semantic difference between having an array pointer 
> associated with each object to store transforms and having an array 
> indexed by object whose values are arrays of transforms?
> 

No semantic difference, just associative. And when you are dealing with 
objects that is often more important than semantics. Its why you don't 
usually find most OOP languages placing the arrays of icons/objects or 
enumerations that *belong* to them in separate arrays and "force" the 
coder to add code like:

ondraw() {
  for each icon in some_external_array
    draw(icon);
}

instead of:

ondraw() {
  for each icon in self.icon_array
    draw(icon);
}

Semantically they are **identical**, associatively they are 
**completely** different.

-- 
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 <47109fba@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > You keep claiming that you can just somehow "untransform" 
> > the matrix
> 
>   Do you understand the concept of resetting a transformation matrix?
> Or is that concept way too difficult for you to comprehend?
> 
Think I have already addressed most of this in the other post I made 
today, so I am not going to bother with most of it. I will once again 
mention this one... There are only **two** ways I can see of doing that, 
either a) you have to do the **opposite** set of transforms to get it 
back to the state you want to start from, which **may not** be the 
original blank state that the object had when first instanced, or b) you 
have to reset it back to the very first state it had **prior** to any 
transforms, then reapply **all** of them. The first you can't do unless 
you keep track of what they where, which doesn't make much more sense 
than what you are already complaining about, and the later is just 
absolutely stupid, since you might as well not even bother applying any 
transforms to the original object(s), until you need, just before you 
render it. Neither of them help your case, since they both require 
somehow "tracking" what you did to the original, or storing all your 
transforms, including the first state, in some other array.

Hopefully, the hybrid concept I posted about earlier "fixes" the issue 
you are rambling about vis a vie the memory usage on objects that don't 
need the array. That just leaves the absurd claim that you can somehow 
reset a matrix to a usable state without keeping a big array with "all" 
of the transforms in it, which is semantically the same damn thing I 
suggested, or if you keep all of the transforms on the object, so that 
you only have to, at the last minute, change the *specific* transform(s) 
needed for that frame, which would both save more space than your 
version, and is "associatively" more reasonable.

I know damn well what "reseting" the matrix means. It doesn't change a 
damn thing with respect to either of our positions, all it does is bring 
up a useless straw man. Unless of course you know some magic formula for 
"resetting" it to a prior state, without resetting to all the way back 
to the "initial" state, without any way to tell how the hell it got to 
that state, or what is needed to reset it. Objects are, once instanced, 
basically black boxes. They have a static state, with no memory of how 
*they* got there. The only way to correct that is to delay the creation 
of that state until you are ready to render. Then the problems are a) 
are some states "static" in the sense we don't need an array at all, b) 
for the ones that are not static, can we 1) revert to some state that 
"isn't" completely blank before applying a change (I say no, since the 
parser doesn't have any better idea than we do how it got to that point, 
given that all you have at that point is the "final" matrix), 2) delay 
creation of the matrix until needed, so we don't have to revert it, but 
apply "all" transforms via an external source, or 3) delay creation of 
the matrix until needed, so we don't have to revert it, keeping a *copy* 
of the transforms from the last frame on the object, so you only need to 
adjust the *specific* ones needed for this frame from an external 
source, instead of *all of them*.

Or do you want to beat the straw man some more?

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