In article <4729cc2c@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > 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?
> 
>   Do you have some concrete reference which indicates that what Pixar doe
s
> has something to do with your solution?
> 
> > 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.
> 
>   They don't use your solution either. What they have are expensive
> graphical modellers where they can record things like skeletal
> animations etc. with the mouse and with things like spinbuttons (and,
> I assume, sometimes even writing some scripts too).
> 
>   We don't have such a high-end modeller, so we have to do it basically
> the same thing as OpenGL does: By coding.
>   What I don't understand is how your "solution" saves any writing.
> You have to write all the transformations at some point. Your tables
> do not change this fact.
> 
> > And it makes no sense at all 
> > to not have some method to apply the *entire* set of actions for a fram
e 
> > 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* su
b 
> > object.
> 
>   Your tables somehow magically remove the need to specify which
> transformations are applied to which objects. I suppose that the renderer
> will have a magical algorithm which reads your mind and uses that to
> distribute the transformations among the objects.
> 
> > 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
.
> 
>   And you refuse to give me a concrete example of how you suggest the use
r
> could change your magical tables at each frame.
> 
> 
Sigh.. Ok, first off, lets cover the Pixar issue. I know damn well they 
have complex modelers. Its also probably likely that they feed the data 
to the render engine for each frame, based off the stored data. Part of 
the point of what I am talking about is to allow the script system 
access to the *storage* from such a modeler, so you don't have to keep 
feeding the stuff in via coding. In other words, you could either use 
such a modeler to derive a set of actions to be applied, and store those 
in a file/database, then instead of having to have the modeler call the 
engine for each frame, and animate that way, which undermines the point 
of doing the animation "in" your script system in the first place, you 
read the pre-generated actions *in* the script.

Second issue. Which transforms to apply to which objects. This is where 
the definition of "tables" differs from most languages, where they are 
just arrays, to ones that allow different types of indexing, or 
structures. An array is just x dimensions, by y dimensions, by z 
dimensions, etc. This means you use the same amount of memory, even if 
you only use "one" transforms in a set. I.e., if you have three objects, 
and most use three transforms, you get an array like: a(3,3), Which 
means that if object #2 only uses one transform, you still have two 
unused fields, which still have to exist. With something like Lua tables 
it gets a bit different, you can do something like:

table-lleg-knee-array(3)
     |    \ankle-array(2)
     |    \toes-array(1)
     \rleg-...

There is no mandate that the table contain *exactly* a specific number 
of elements, or that they be numbered. You can use numbers, you can use 
the way they are nested, and you can even make an array that contains 
multiple data types, including other arrays. A "mathematical" table, 
such as Thorsten seems to think is the only kind of "table" supported by 
programming languages obviously can't do that. As to the specifics, 
since I spent so damn much time arguing for the basic idea, I hadn't 
gotten to thinking of the logistics of that. There are two solutions 
though. One is naming, but that adds extra data to the compound object, 
which may be Ok, if you only need to have the table deal with "some" 
parts of the entire collection. But, you can get away from that by 
tieing the structure of the table to the structure of the object. I.e., 
as you traverse the tree like structure of the compound object, you also 
traverse the structure of the table. Unless you change the structure of 
the original compound object, thus requiring changes to the structure of 
the table, you don't have a problem. Further more, you can avoid that 
problem too, but having a command like:

mytable = Createfromobject(myobject)

Basically, have the parser traverse the structure of the object and 
create a "table" containing the same layout.

As for changing the data "in" it, its likely easier with a named system, 
but a) you don't need that if the object and table is defined by a 
modeler, and the database you feed it with is generated by the same, and 
b) as long as you know the structure yourself, it shouldn't be 
impossible to do mytable.lleg.knee(3) = "blah" or even 
mytable.lleg.knee.append("blah"), or mytable.lleg.knee.delete(2), or 
anything else that a Lua like table allows.

And again, since the point of this is to streamline "static" data, 
possibly from a database, into an animation, you are not **forced** to 
use it in your own code, nor do you have to deal with the complexity if 
you don't want to. For that matter, allowing naming on some level, even 
if its something like:

#define toe = ...
#define foot = union {toe ...}
... etc.

You already have names, presuming they where carried over into the 
object level, which is kind of needed to object oriented access to 
elements anyway. Any object oriented system is probably to require some 
sort of naming for each "level" of a structure, even if all it amounts 
to is "fred.ginger.union1.torus". So, there is no reason to not have 
some traversal system that lets you walk through the structure of a 
compound object, or some way to link a structured table, with the same 
basic layout as the object itself, to that object. Once you have that, 
there is no reason you can't quickly load data from an external file or 
database "into" such a table, thus bypassing the need to read every 
transform independently and apply to each distinct object, union, etc.

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