In article <4711cecb@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > 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
.
> 
>   How are you going to tell it that regardless of the transformation arra
y?
> 
>   The only "problem" your transformation array "solves" is that it makes
> it possible to change individual transformations stored in that array.
> However, that doesn't solve the issue of *how* you are going to change
> those transformations in later frames. What kind of code will you write
> in order to do that?
> 
>   And that's exactly why the transformation array is not needed: The exac
t
> same code that can be used to change the array can also be used to apply
> all the transformations (optionally modified from previous frames) to the
> object.
> 
>   Besides, your array solution presents other problems which are not
> problems in a "apply transformations with SDL code". For example, what
> if you want to insert a new transformation somewhere in the series of
> transformations? Or what if you want to remove some transformation?
> What if you want an alternative series of transformations at different
> frames?
>   You would need to offer all kinds of functions to modify the array,
> and the user needs to write some SDL code to call those modifications.
> 
>   However, with the same effort the user could simply call the functions
> which apply transformations to the object directly. Adding or removing
> transformations is simply a question of putting them in conditional
> statements. Applying alternative series of transformations is simply a
> question of if-else or switch blocks.
> 
Huh? How? Your missing the point. The initial structure of the object 
**must** be static. Why? Because if it isn't, then you have to reparse 
the entire structure. Currently you can't tell something that you want 
to add transforms to the 6th nested object in some complex series of 
unions, nor can you "change" those. Its just not possible to do at all. 
The object, once it exists, is static on "all" levels other than the 
base union. All subobjects are inaccessible. That only gets worse when 
dealing with a change to the SDL that allows it to run like a program, 
instead of as a one pass, then reparse for the next frame, system, like 
we have now. If-else blocks won't work because by the time you get to 
the next frame all of the "code" that contains them will have already 
executed, and isn't reparsed, so those statements are **never** checked 
to determine what the new result will be. Instead you have to disconnect 
the object definition, the if-else statements and the execution, so that 
you 1) create an object with some static and some non-static transforms, 
2) render the first version, then 3) access those transforms you need to 
change. Yes, you could do that, sort of, now, but only via something 
like macros, and that won't work in this case, since you can't simply 
throw out the prior frames version, then reparse the macro. You have to 
have an already existing object, which you can make "some" adjustments 
to. Macros don't do that. A Macro would **recreate** the entire object 
each and every time. **Every** method that currently exists in the SDL 
works the way it does *precisely* because the assumption is that you 
won't be changing and *existing* object, but creating a **new** one, 
every single frame. The two implimentations are fundamentally different.

If not, then please, explain to me how I am wrong here. Tell me how, 
with something like an IK chain, you can **change** an object in the 
sub-chain **after** it has already been calculated and added to a union. 
I am willing to bet that if you **really** think about it, its not 
possible. It needs to be possible if you are running a script, instead 
of just parsing a single frame.

> > 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.
> 
>   That's not a technical limitation. That's just a syntax limitation.
> 
>   It would be perfectly possible in the current POV-Ray to change the
> transformation matrix of an existing object if someone simply added the
> proper syntax for it. (And that's exactly one of the reasons why the
> whole new SDL is being discussed. To add easy support for such things.)
> 
Ok, fine. But how do you do that, without adding something that is at 
least semantically the same as what I propose? And why, again, does it 
make sense to store "every" transforms in some array, to be applied all 
at once, instead of maintaining an array of "existing" transforms 
applied the the object, then only adding to, changing or deleting the 
specific on you need to?

> > In an SDL that supports its own animation/render functions, you can't
 
> > have "static" objects.
> 
>   POV-Ray doesn't assume that objects are "static". It's just that there'
s
> no syntax to change the transformation matrix of an existing object. Plai
n
> and simple.
> 
> > 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.
> 
>   Why do you have this obsession that individual transformations *must*
> be stored somewhere?
> 
>   You *apply* transformations in the SDL code. You don't *store* them
> (not as individual transformations anyways). That's because the individua
l
> transformations are already "stored" in the SDL code itself. Why do you
> need to store them in two places?
> 
Yes, they don't have to be. The can be calculated as you go, but they 
still have to then be **applied** individually, regardless of if you 
plan to repeated apply the same initial translate, then a changing 
rotate, then another translate, or something. It might not be "stored" 
any place, but you are still wasting code to do something that is 
functionally the same thing. But yes, if you want to do it that way, you 
could. I suppose, in that sense my idea just means that you have access 
to what ever "initial" state you started with, in a way that is more 
accessible than just returning the matrix and then wondering how the 
hell you got to there (since you can't exactly ask the code itself what 
transforms where needed to get to that point). So, OK, I admit, what I 
propose may not be strictly necessary, it might be useful some times, 
and its a little nicer to have such data "on" the object it effects, 
instead of seperate from it, when you do need it.

>   At each frame you simply execute that SDL which applies the transformat
ions
> to the objects.
>   You are going to have to execute some SDL at each frame anyways (to
> change transformations). It's not any more difficult to simply execute
> the SDL code which applies all the transformations.
> 
> > 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 tryin
g 
> > to get across too.
> 
>   Let me see your suggestion about the new SDL code which modifies the
> "transformation array" at each frame.
>   My answer is that it's the exact same thing, but without the transforma
tion
> array. Simply apply all the transformations to the object at each frame.
> 
Well, I think I am thinking more in terms of the data end, rather than 
the program end. I am thinking in terms of, "Automatic application of 
known transforms.", you are thinking more in terms of, "Manual 
application of any needed transforms." Both work. Your would use far 
less memory than mine, but it slightly obfuscates how the data is 
associated with the object, which is what I was thinking about when I 
got the idea. I wouldn't mind, on after thought, making the array itself 
even more option, so that objects where it could be easier to keep track 
of things with my method could use it. Basically, if you are going to 
use pre-calced arrays of actions, you could either apply them from a 
non-linked version, which would require "manual" application, or you 
could put the array on the object itself, and have to implicitly 
applied.

That might be a better idea anyway. For those cases where you are only 
dealing with "one" compound object, and you are not going to apply the 
transforms to anything else, being able to just define them once, then 
have the system auto-apply them, could help keep the code cleaner, and 
since in "that" case, you are using such an array anyway, having it 
associatively connected to the object itself, as least as far as the 
code is concerned, won't change how much memory is/isn't used. It just 
removes the need, in those cases, of having to remember to manually 
apply the transforms.

This means it wouldn't use the same syntax though. It would be something 
like:

fred.autotransforms = mytable

Where mytable would be the same array you use to do:

fred.applytransforms = mytable.main(1)

Presuming that the number in () was a frame number. A table could thus 
define a range of frames for a set of transforms, or even contain a 
structure for the entire object. The "array" would be seperate, as you 
suggest, but you could access it, "a = fred.autotransforms.main(0)" and
 
you get the benefit that you don't have to use the "applytransforms" 
command **ever** unless you are programatically calculating the results 
(instead of using a list).

You get what I intended, what you think would be better, and the *cost* 
in memory doesn't change by anything other than the pointer needed to 
link the "object" to the "array/table" used to store the transforms for 
each frame.

I admit, this makes more sense than what I was thinking, while still 
providing both the contextual associations I thought would be useful 
"and" the auto-application which imho, makes way more sense than having 
to write hundred of lines of nothing but object.applythis(blah), to get 
the same results, especially in cases where that isn't even necessary 
(like when using "pre-calced" transforms from a database or file).

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