In article <470df2c7$1@news.povray.org>, 
fab### [at] yourshoesskynetbe says...

> > 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 h
e
> > 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 transformatio
n
> > 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.
> 
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.

> Objects could even have some kind of "extended data" that could be attach
ed
> 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 transform
ations
> > then he can do so. However, most importantly, he is not *forced* to do 
so
> > if he doesn't want to.
> 
> Yep.
> 
> Fabien.
> 
Look, the only reason I am suggesting it is so that when you create an 
object the current "history" or "state" is accessible, so you can look 
at it, or change it. Sigh.. I have a feeling people are just so stuck on 
the idea of how they do things "now" that they just don't get why the 
solutions being proposed are either a) worse than mine, or b) make no 
sense in an SDL that doesn't work *exactly* like the way it does now.


-- 
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 <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' wil
l 
> >>   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" unti
l 
> > 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.

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

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

You are talking to a Warp.

Fabien.

Post a reply to this message

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 will 
> to store 20 transforms in the object

  You don't get it, do you? Forcing a transformation array to exist in every
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.

  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 those
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 think
the current POV-Ray manages without such arrays? And no, the answer is not
"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.

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

  What the heck are you talking about? Object-specific transformation arrays
are needed to preserve the current SDL?

  The more you write, the weirder it gets.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> Your solution **still** requires extra arrays, or code, or **some** way 
> to get the changing data "to" the object to transform it.

  Well, you have to define the objects somehow. You could as well
define them so that the transformations can be executed at each frame,
at *no additional cost*. The transformation code must exist in one form
or another.

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

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

  I don't think you even understand how transformation matrices work.
If you really think that an individual transformation couldn't be removed
from a transformation matrix even after several other transformations
have been applied to it, then you should *really* acquaint yourself with
transformation matrices and the math involved.

  In all these posts I haven't even been talking about removing/changing
one single transformation from the transformation matrix, but even that
is certainly possible to do to a transformation matrix, if you really
wanted to do so. (No, it's not possible to retrieve every individual
transformation which has been applied to a transformation matrix, but
if you already know which transformations has been applied to it, it is
possible to undo one of them. Anyways, that's not very relevant.)

> Some how you have to 
> both save memory "and" provide a way to change interdependent 
> transforms

  You don't understand this either, do you? The memory wasting comes in
your solution in that *every* object will have a useless array, wasting
memory, when none is needed.

  In other words, in your "solution" every object has a transformation
array *and* there exists SDL code which writes values to that array.
In the correct solution there's no such array and only the code exists.

  Do you understand now how there's less memory requirements in this way?

>, which, unless you are a fracking mathmatician, isn't going 
> to be practical.

  You don't need to be a mathematician to apply a series of transformations
to an object. It's just a question of syntax.

> any solution you come up with, at minimum, is going to 
> require some transforms to be user changable

  How does the current SDL handle transformations which change from one
frame to the other? Why should the new SDL be any different (except that
re-parsing the object itself can be skipped)?

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

  Why is it worse?

  The only thing which is worse is your solution: You are hard-coding one
specific solution, and you are wasting memory by having a useless array
in each single object.

> 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

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> > 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.
> > 
> 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.

  What the heck do you need a "transformation history" for? You don't need
it currently, nor you need it in the future SDL either. Why would it be
any useful?

  The "transformation history" is in the SDL code you write. Why do you
need to store it somewhere else as well? That's just a completely useless
waste of memory.

> Look, the only reason I am suggesting it is so that when you create an 
> object the current "history" or "state" is accessible, so you can look 
> at it, or change it.

  Why do you need to "look at it" and "change it"? The transformations
are already in the SDL code you write. Just write them so that they
change appropriately at each frame. I just can't see what the heck is
the problem.

> Sigh.. I have a feeling people are just so stuck on 
> the idea of how they do things "now" that they just don't get why the 
> solutions being proposed are either a) worse than mine, or b) make no 
> sense in an SDL that doesn't work *exactly* like the way it does now.

  There's a reason why there are no "transformation arrays" in the current
SDL. The reason is that they are not needed. They would only be a completely
useless waste of space.

  And once again, you would be hard-coding one specific solution. That is
not the way to go. Hard-coding solutions is bad programming.

-- 
                                                          - Warp

Post a reply to this message

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