Warp wrote:
>   What makes you think that JIT-compiled code is relevantly slower than
> regularly-compiled code?

It's hard to do global optimizations. It's easier to do processor- and 
data-specific optimizations. Depending on the HLL you're compiling 
*from*, it could go either way.

-- 
   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 <4721bb6d@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Obviously the *major* disadvantage to doing it that way is that you are
 
> > either running it uncompiled, or JIT compiled, both of which might slow
 
> > things down too much
> 
>   What makes you think that JIT-compiled code is relevantly slower than
> regularly-compiled code?
> 
>   Besides, transforming objects is not one of the most speed-critical
> things in rendering. It's a pre-rendering step done once (per frame)
> and that's it. Hardly anything that needs extreme speed.
> 
Except that in many cases the parsing, and thus script execution, is 
already taking far longer than the actual render, so it *does* matter 
how its done. And as Darren points out, JIT optimization its hardly the 
same as processor optimization.

Having thought about it, there needs to be something close to the core 
to do this anyway. As I see it there are two ways to handle it, before 
rendering, do a call to some sort of "transforms" event, which would 
call a function like:

function on_transforms (object){
  if exists object.autotransforms {
    for each trans in object.autotransforms {
      call transform(trans)}}}

This would happen for "every" subobject in a union or other layered 
object. But, this bit of code it so simple there is no reason at all 
that you can't have it built in some place, since you already **need** a 
way to intercept the render, so you can auto-add the transforms. The 
difficulty is that you either have to have an array for every object, or 
if you use a table of some sort, the object.autotransforms needs to be 
smart enough to check for a table, and if the object being tested is 
"in" that table as something which needs to be transformed. I.e., it 
needs to walk the table somehow, and return an array for "that" object 
from in it. another way is to not step through the table, but rather to 
mark each object, so it knows to look in the table for it. This would be 
like a flag. Such a flag does away with the need to add code on the 
lower levels to "automatically" feed every object through the above code 
fragment, which would be faster, but it also means you would have to 
"mark" every section of a compound object that need to be read from the 
table(s) instead. I.e., the could would still be present, but triggered 
by the presence of the keyword, which could then be handled in a plugin, 
instead of in the engine.

The former version "must" be in the engine, or at least the latch needed 
to intercept with. The reason is simple. Since the later is triggered by 
a key word, you can add the keyword as a plugin, along with the code 
needed to handle its presence. If you do it the other way, you **must** 
already have the means to stop the engine *before* it renders anything, 
so as to test for and process the changes you want, before allowing it 
to continue.

If however, it was decided that such an intercept prior to the render 
step was useful for other things, then it becomes less relevant, *but* 
then the question is still, "Does stepping through a lot of these calls 
cost more time in 'script' or compiled with proper optimizations?" Its 
not much code, but it "is" a bottleneck, and one that might be faster as 
part of something that also supports multiple core processing, where as 
the script itself... might not do that so well. How many copies of the 
script is likely to be "allowed" to run? Or for that matter, is it even 
possible to split parts of a script to a separate thread, on a different 
processor. This is one case where doing that could vastly speed up 
application of the transforms, since you could calculate the matrices 
for as many objects as you have threads/processors. In fact, that is 
faster, in theory, than you could do the same transforms directly. 
Right?

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

Patrick Elliott <sel### [at] rraznet> wrote:
> Except that in many cases the parsing, and thus script execution, is 
> already taking far longer than the actual render, so it *does* matter 
> how its done.

  Applying transformations is not the heaviest operation during parsing.
You will not gain any parsing speed using your suggestion.

> And as Darren points out, JIT optimization its hardly the 
> same as processor optimization.

  We are talking about some percents. You wrote as if JIT-compiled code
was several orders of magnitude slower than compiled code.

-- 
                                                          - Warp

Post a reply to this message

In article <4722dd91@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Except that in many cases the parsing, and thus script execution, is 
> > already taking far longer than the actual render, so it *does* matter
 
> > how its done.
> 
>   Applying transformations is not the heaviest operation during parsing.
> You will not gain any parsing speed using your suggestion.
> 
> > And as Darren points out, JIT optimization its hardly the 
> > same as processor optimization.
> 
>   We are talking about some percents. You wrote as if JIT-compiled code
> was several orders of magnitude slower than compiled code.
> 
It probably isn't, but we are not talking about just handling 
transformations, but the overhead of handling data needed to do that. 
Your still using the same commands to do the transforms, but you are not 
doing them directly, you are reading them from a table, then passing 
each to the part of the system that handles transforms. That means its 
going to take slightly longer. Mind you, its possible you could make a 
table layout that short cut things, like tokenizing the commands, which 
would make lookup slightly faster, maybe. But again, its still 
"percentages" as you say.

You seem to have missed part of what I wrote though. On some level you 
are still dealing with the problem if if you are going to parse one 
command, to add the table, then use an intercept, prior to the final 
render step, to process the table, or you **also** parse a separate 
command for every part of the object that need to gets its transforms 
from the table. The later adds for extra time to detect that command, 
every time it appears, as well as the process or retrieving the data 
itself from the table, so it knows what transforms to apply. Whether or 
not the actual computations for the transforms themselves are trivial 
delays has no meaning to if the added commands, or the method used to 
retrieve the data to be applied to the transforms, is going to cause 
more time to be used. At mimimum, its going to cost a *slight* amount of 
additional time, no matter which method you use, compare to parsing 
**each command** by itself. I am not sure, other than something silly 
like tokenization, which could be meaningless on a modern processor, 
that you could speed up the retrieval of the data from the table(s).

Yes, we are talking about percentages here, but those can matter, 
especially if there are bottlenecks. And, as I said, if you had 4 cores, 
each reading one objects table, each of those tables containing say 3 
transforms per object, with 20 objects, and it took .01 seconds to read 
and apply the transform for "each" of those commands, you would take 0.6 
seconds to do it, while using a non-threaded script driven solution 
would produce 4 separate passes, one for each compound object, with all 
the same parameters, or 2.4 seconds. Please tell me again how this 
**isn't** significant, especially if you where dealing with the real 
numbers and you took into account a scene with, say, 90 compound 
objects, only two cores and even a .01% decrease in speed due to it 
being a script, instead of a compiled module.

And don't tell me my numbers are silly or irrelevant. At least I am 
trying to come up with some sort of means to compare. If I got them 
wrong by some order of magnitude, it still doesn't change the basic fact 
that more than one core, each processing the transforms for a different 
object, takes **less** time than a mono-threaded script. And most script 
systems don't support multiple threads/processors. It can be enough of a 
pain getting the "core" code to do that right, never mind letting some 
end user muck around with it.

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

Patrick Elliott <sel### [at] rraznet> wrote:
> Yes, we are talking about percentages here, but those can matter, 

  What's so hard to understand in the concept that applying transformations
to objects is in no way the slowest step in the parsing process? Using your
transformation tables will *not* speed up parsing, not in any relevant way.
Using speed as an argument to support your idea is simply flawed.

-- 
                                                          - Warp

Post a reply to this message

In article <4723f102@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Yes, we are talking about percentages here, but those can matter, 
> 
>   What's so hard to understand in the concept that applying transformatio
ns
> to objects is in no way the slowest step in the parsing process? Using yo
ur
> transformation tables will *not* speed up parsing, not in any relevant wa
y.
> Using speed as an argument to support your idea is simply flawed.
> 
And what part of, "Its not the applying of them that is the issue, its 
how you get the data read/parsed to do it.", are you missing?

And I am not using speed as support for my idea. I think the idea is 
still good on its own merits, since otherwise you have to write your own 
way to do it, and most of the people trying to do stuff in POVRay are 
***not*** going to be interested in reinventing this same wheel over and 
over again. Putting it in a plugin is possible, yes, but **only** if the 
framework is available to allow for it in the first place. A framework 
that only allows you to add new tokens, as it where, for new functions, 
but which can't handle something like this **won't** do it. 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 is 
imho damn stupid, if there is a better way.

I covered the point of if the idea was useful already, and whether you 
fracking agree or not, I instead opted to talk about the logistics of 
implementation and the likely issues that could pop up as a result of 
it. Your idea, that you explicitly tell it to apply a transform (or even 
a table of them) every damn time is programically complex, unnecessary 
if the framework exists to do it my way, and divorces the data from the 
object in a way I personally don't like much. Its not functionally 
equivalent, since yours is explicit, mine is implicit, even if on the 
deeper level some of the code is necessarily similar.

And again, the point is, how would you implement it. Which method 
**would** be faster, when you want to use predefined transforms, where 
you have no plans to change the number, type or any major features of 
those things. Whether or not you think its a good idea has jack to do 
with how you would implement it, if it was used, which is what nearly 
the entire prior post was about.

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

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

  I'm tired of repeating myself this is going nowhere.

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

  You seem to somehow think that running the same commands again and
again at each frame somehow adds to the complexity. Why you seem to
think like this, I don't know.

  Does a loop become more complex if it's run 10 times instead of 5?
Is it more difficult to write? Does it require more work to write?
Does it require more thinking?

  Basically what you are saying is exactly that: Since the loop is run
n times, it's more complicated to write and to understand.

  Moreover, your solution doesn't at all solve the problem of how to
apply transformations to sub-objects in an existing compound object.
The problem is still there regardless of your array solution. You have
to somehow be able to reference the subobject when you want to change
its transformations or apply new ones to it. There must still be a way
of saying "apply this transformation to this subobject" regardless of
any transformation arrays. Your arrays don't make this any easier.

  Your array solution is simply unnecessary. Given that you must be able
to change the transformations of any object at any frame, an array of
transformations doesn't bring any help implementing this. You must still
be able to run some commands which change those transformations.

  If you answer the question "how exactly would you change the
transformations of a specific object at each frame?" then the answer
to that question is exactly the reason why your arrays are unnecessary.

-- 
                                                          - Warp

Post a reply to this message

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

Patrick Elliott <sel### [at] rraznet> wrote:
> Your code, more or less:

> Frame 1:
> Define array1, array2, array3.

  That's not "my code". Its your idea of what "my code" is.

  Why are you so obsessed with the arrays? How many times do I have to
repeat that the arrays are not needed?

  Your array solution consists of two steps:

1) Initialize the arrays at the beginning.
2) Execute some code at each frame which modifies the arrays.

  The proper solution is:

1) Execute some code at each frame which transforms the objects.

  Basically your step 1 has been removed and only step 2 remains.
No arrays needed.

  Perhaps you are confused by "execute some code at each frame"? Do you
perhaps think that means that the user has to write some code for each
single frame in the animation? Maybe that's what you are not comfortable
with?

  No, the code is written just once. The SDL interpreter executes it at
each frame.
  It's the same idea as with loops (as I have mentioned before): Even though
the body of the loop is executed many times, the programmer only has to
write it once and that's it. The exact same idea with the transformations:
You write them once and the interpreter executes them at each frame.

  Your arrays wouldn't be of much help in this, but would add one layer
of complexity. Instead of having *one* piece of code which is executed at
each frame, you would need *two* pieces of code: One to initialize the
arrays and a second one to modify those arrays at each frame if needed.
  (Of course you can have two pieces of code like this if you want to,
but the idea is to not to force it.)

  Moreover, since the code which initializes your array is basically the
same code which applies the transformations, that makes the array itself
obsolete. The transformations can be applied to the object directly,
without the need to store them in an array.

> My code, more or less:

> Frame 1:
> Define table1.
> Frame 3:
> Change something in table1.

  That's exactly where the two steps are which you couldn't see.
You have to be somehow able to tell the interpreter "at frame 3 execute
these commands".

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

  The user applies the transformations to the objects in the exact same
way as they would apply those transformations to your arrays, but instead
of being applied to the useless arrays, they are applied to the objects
directly.

  It somehow seems that you have this concept that the user would have
to literally write n pieces of transformation code for an animation with
n frames. No, the user writes the transformations just once, and they
are executed at each frame.

-- 
                                                          - Warp

Post a reply to this message

In article <47287d49@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Your code, more or less:
> 
> > Frame 1:
> > Define array1, array2, array3.
> 
>   That's not "my code". Its your idea of what "my code" is.
> 
>   Why are you so obsessed with the arrays? How many times do I have to
> repeat that the arrays are not needed?
> 
>   Your array solution consists of two steps:
> 
> 1) Initialize the arrays at the beginning.
> 2) Execute some code at each frame which modifies the arrays.
> 
>   The proper solution is:
> 
> 1) Execute some code at each frame which transforms the objects.
> 
>   Basically your step 1 has been removed and only step 2 remains.
> No arrays needed.
> 
>   Perhaps you are confused by "execute some code at each frame"? Do you
> perhaps think that means that the user has to write some code for each
> single frame in the animation? Maybe that's what you are not comfortable
> with?
> 
>   No, the code is written just once. The SDL interpreter executes it at
> each frame.
>   It's the same idea as with loops (as I have mentioned before): Even tho
ugh
> the body of the loop is executed many times, the programmer only has to
> write it once and that's it. The exact same idea with the transformations
:
> You write them once and the interpreter executes them at each frame.
> 
>   Your arrays wouldn't be of much help in this, but would add one layer
> of complexity. Instead of having *one* piece of code which is executed at
> each frame, you would need *two* pieces of code: One to initialize the
> arrays and a second one to modify those arrays at each frame if needed.
>   (Of course you can have two pieces of code like this if you want to,
> but the idea is to not to force it.)
> 
>   Moreover, since the code which initializes your array is basically the
> same code which applies the transformations, that makes the array itself
> obsolete. The transformations can be applied to the object directly,
> without the need to store them in an array.
> 
> > My code, more or less:
> 
> > Frame 1:
> > Define table1.
> > Frame 3:
> > Change something in table1.
> 
>   That's exactly where the two steps are which you couldn't see.
> You have to be somehow able to tell the interpreter "at frame 3 execute
> these commands".
> 
> > Feel free to rant some more about it. But this time, please give a clea
r 
> > explanation for how you manage to do this *without* basically doing wha
t 
> > 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 (whic
h 
> > is imho damn silly, since it not only disassociates the data from the
 
> > object, it disassociates the data from other related data).
> 
>   The user applies the transformations to the objects in the exact same
> way as they would apply those transformations to your arrays, but instead
> of being applied to the useless arrays, they are applied to the objects
> directly.
> 
>   It somehow seems that you have this concept that the user would have
> to literally write n pieces of transformation code for an animation with
> n frames. No, the user writes the transformations just once, and they
> are executed at each frame.
> 

Sigh.. Ok, so your entire argument is that you don't comprehend how it 
might be useful to do such a thing. And last time, arrays are not the 
same things as tables. An array contains only data, a table has indexes, 
so you can look things up by the index (and no, I don't mean a 
*numerical* index). In a table, you can place everything for "leg" under 
an index of "leg", not as array(1,n).

Ok, for the sake of argument, yes, you could do it 100% without a table. 
The question then becomes not, "can you?", but, "are there circumstances 
where you don't want to have to do so?" For example, how about this 
code:

a = opendb("my_database")
' I have no damn idea how you plan to get around this one, short of hand 
coding *every* step, which isn't really conducive to loops.
for each object in (blah) {
  tr = a.read(object.name,frame)
  object.applytransforms(tr)
}

vs.:

a = opendb("my_database")
table = a.read(parent_object.name,frame)
object.autotransforms(table)

Yes, something still has to do the step through, to apply them all, but 
you only do *one* lookup in the database, to get the *entire* table, not 
one set of transforms *per* object, or worse (since you hate arrays for 
much), multiple reads, such as:

a = opendb("my_database")
' I have no damn idea how you plan to get around this one, short of hand 
coding *every* step, which isn't really conducive to loops.
index = 0
for each object in (blah) {
  tr = a.read(object.name,frame,index)
  if tr then {
    object.applytransform(tr)
    index++
  }
}

This presumes the database returns "false" if it runs out of things to 
read. This is what **your** way would require for transforms from a 
database, one separate read for *every single tranform* you want to 
apply. If you don't use an array, you have to do at least 3 (for 
animation) for every object x the number of objects. With arrays of 
transforms, you still have to do one read for every object. With a 
table, you, assuming the DB allows this, read **one** table, which means 
*one* read. Its pretty irrelevant if you use my implicit linking to the 
object, or you just do something like "object.ApplyTransTable(table)". 
Its still way fracking more reasonable to do that than what you suggest. 
And, if you allow such a syntax, then you still have to do something 
like "for each object in..." within the parser/post-parser/core to make 
it work.

And seriously.. Do you really #$@#@# think Pixar or anyone else hand 
codes a mess of scripts when defining the actions of their virtual 
characters, instead of, *at minimum*, storing them in a file, or more 
likely, using a database to store entire sets of data, for each 
character? I rather doubt they spend hours writing loops in script, so 
that you have to calculate the numbers, every damn time they generate a 
scene. It makes no sense to do it that way. And it makes no sense at all 
to not have some method to apply the *entire* set of actions for a frame 
to a set of connected objects (such as a character), instead of writing 
code to specifically apply them, one at a time, to each *individual* sub 
object.

Once again, you don't actually give an example of what you think would 
work better, but just complain about how I don't have a clue what I am 
talking about and you have some *better* solution. Its getting real old.

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