In article <472506d6@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > I thought 
> > about it, and it just won't work, not without having to add a command
 
> > word to every level of a compound object you want to use it on, which i
s 
> > imho damn stupid, if there is a better way.
> 
>   Exactly how is your idea going to alleviate any such problem?
> 
>   What if someone doesn't *want* to use any transformation arrays but
> something else? Why would you force him to use a transformation array
> when there's no need to?
> 
How the hell is giving someone the ability to set something like this up 
"forcing" them to do it? I never said this should be the only way to do 
anything, just that its a way you could streamline some things, so that 
you don't have to code a lot of extra stuff for objects with predefined 
actions (i.e. ones you don't need to calculate in some explicit 
fashion). If you know that object X is moving as you want/intend it to, 
and will always follow that path, why recompute every movements via 
script, if you can simply dump the path data into a table, then let the 
parser/engine apply the transforms needed, without you explicitly 
telling it to? It doesn't make any sense to me that you should be 
**forcing**, and in this case the term is appropriate, everyone to be an 
expert programmer and write all the loops and functions themselves, for 
every object, to get the same result. And I agreed with you that yes, 
someone could create a plugin to do the same thing, but I also tried to 
point out that such a plugin won't work right **unless** there is some 
sort of intercept event, which will let the plugin process things in a 
streamlined fashion. The alternative is to force calculation on each sub 
object by keyword, which *yes* that will work, but it means adding a 
damn keyword to every level of a compound object. Why? Because without 
it there is no way the parser could know that you "intended" to apply 
transforms to that sub object, thus triggering the event needed to read 
those transforms from a table. You have to either implicitly allow 
transforms to be applied for such a system to work, or you have to 
explicitly tell it which parts of the object "require" such application. 
I thought about it and the only other way you can do it is to write 
something "specific" to each object you plan to do it with. In other 
words, you can't really provide a single "generic" solution for doing 
this, at least not without changing the existing syntax radically.

Ok, sure, you can have some sort of object level function, like "apply 
transforms" and some sort of plugin that can "step through" the sub 
objects using something like "temp = GetNextChildObject(My_Object)", or
 
something like that. Point being, you **must** have some way to step 
through such a thing to make it work, whether you code it, someone else 
codes it as a plugin, or the parser+core provide some simplified method 
of doing the same thing. I just think that its easier to have the parser 
fire an object level event, where you can then check to see if there 
"is" a table available with the needed data in it, apply transforms from 
there, then go to the next object, instead of having to do 100% of it in 
a damn script.

>   I'm tired of repeating myself this is going nowhere.
> 
Well, if you ever explained how *you* think things should be done on an 
implementation level, and not just vague comments about applying an 
array, then we might find some middle ground. I suspect you are not 
getting some key aspect of what I am trying to describe, so you are 
missing the point, but its damn hard to tell when you don't talk about 
the underlying mechanisms, but just wave your hands and go, "Like so!"

> > Your idea, that you explicitly tell it to apply a transform (or even 
> > a table of them) every damn time is programically complex,
> 
>   How exactly is your way better? There must be some way of changing
> those transformations if you need to. Your "solution" only adds one
> extra layer of complexity to the whole thing, a layer which doesn't
> need to be there.
> 
>   Your solution:
> 
>   1) At the beginning initializes the array with some values.
>   2) At each frame runs some commands which change the array.
> 
>   The generally used solution for this:
> 
>   1) Applies the transformations at each frame.
> 
>   Your "solution" has two distinct steps, the general solution has only
> one.
> 
Umm. I don't get that at all. How is it two steps, instead of one?

Ok, lets try another tack. Here is what I am looking for/at:

The system must:

1. Take a table, containing data specific to an entire nested compound 
object and apply all transformations needed to the entire structure.

2. Create some level of association between the table in use and the 
object, to make it clear which tables belong to which compound objects.

2. Optional, but desirable, it should be implicit. In other words, you 
shouldn't have to do more than change the contents of the table and have 
it work. You do not need to **specifically** tell the parser to apply 
the same table or any changes you make.

3. This isn't a *required* method.

Its a method that can be used in cases where the transforms *may* change 
periodically, but not every frame, or where those transforms are based 
solely on specific data, like the clock, where the main script has no 
need to change the contents at all, but where the data itself must be 
calculated. In other words, you never "update" something like "rotate 
x*clock", so logically, there should be no reason you should have to 
explicitly tell the system to update it. You are not in that case 
telling it of change the data in the array, just telling it to 
recalculate from the **same** data.

This is supposed to save work, since the point is to a) not have to tell 
the system to apply changes to "every" object individually and b) not 
have to directly specify that you *want* it to update the object.

Your code, more or less:

Frame 1:
Define array1, array2, array3.
Apply array1 to object1.
Apply array2 to object2.
Apply array3 to object3.
Frame 2:
Apply array1 to object1.
Apply array2 to object2.
Apply array3 to object3.
Frame 3:
Change something in array2.
Apply array1 to object1.
Apply array2 to object2.
Apply array3 to object3.

My code, more or less:

Frame 1:
Define table1.
Link table one to object1.
-->Parser in last step does "for every sub_object in object1 apply 
table1.objectname.array()"
Frame 2:
-->Parser in last step does "for every sub_object in object1 apply 
table1.objectname.array()"
Frame 3:
Change something in table1.
-->Parser in last step does "for every sub_object in object1 apply 
table1.objectname.array()"

How is that, "two steps, instead of one"? Looks to me like you spend a 
lot of time in your method running the same commands, over and over, to 
force it to do something. Mine does it without that.

Mind you, you **could** do it your way with a table, but then you are 
stuck having to also code the "for each sub_object in blah" stuff into 
your own code as well. We are trying to make something that ***allows*** 
people with programming skill to do more things, not **requires** them 
to have it to start with. On a basic level, "both" your way and mine 
allow the same thing, yours requires the whole thing to sit in the 
script space, when handling the data/object manipulation is going to 
cost more and risk memory leaks (depending on how object termination and 
pointers to them are handled in the language and between frames), as 
well as other possible bugs, which exist "solely" due to handling all of 
it in the script space, instead of on a deeper level. Your method, no 
matter if it is done array by array, or using a table and some sort of 
"for each" system, also isn't implicit. I.e., you still have to "tell" 
the system that you want to do such a thing, instead of having the 
system determine that itself, by noting the presence of the table, or 
just one flag on the main union level, which turns it on.

At absolute best, you could, with your version, make a plugin that 
walked through the table and objects, to apply the needed transforms, 
but you still only manage to do this:

Frame 1:
Define table1.
call AutoTrans(object1)
Frame 2:
call AutoTrans(object1)
Frame 3:
Change something in table1.
call AutoTrans(object1)

This is way better. And its not a bad compromise, assuming a) you can 
step through the objects sub objects properly to do it and apply the 
table, and b) the process of retrieving pointers to each of them, 
reading the data, then applying the transform *is* still fast enough in 
a JIT or other non-optimized plugin/include. But, it loses the 
associative link between objects and tables that I wanted, and you still 
have to explicitly tell the system to apply the transforms, instead of 
simply giving it a set, then letting it handle that itself.

Yes, you could live without both. But, I don't think you can say with 
certainty which *type* of method for handling this would be faster, 
since its doing a damn sight more here than just applying some 
transforms. Show me some real numbers that prove there isn't enough of a 
cost, from all three things being done there, to make it useful to 
provide handling of it deeper in the system. Obviously, you can't, since 
we don't have anything to work with at this point to try, but I just 
don't see how you get, "Transforms don't cost much time.", when it only 
one of the things being performed to produce this effect.

Feel free to rant some more about it. But this time, please give a clear 
explanation for how you manage to do this *without* basically doing what 
I described, or by, worse, not allowing someone to apply a table to the 
whole nest of objects at all, but making them do it one at a time (which 
is imho damn silly, since it not only disassociates the data from the 
object, it disassociates the data from other related data).

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