 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> 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).
A statement by which you just disqualified yourself ... a table in a
database has nothing to do with this argument. You are using terminology
from a completely different and unrelated field. A mathematical table is the
equivalent of an array in a programming language, which does fit the context
of this "discussion".
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sel### [at] rraz net> 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 does
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 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.
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 user
could change your magical tables at each frame.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <472983db$1@news.povray.org>, tho### [at] trfde says...
> Patrick Elliott wrote:
> > 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" unde
r
> > an index of "leg", not as array(1,n).
>
> A statement by which you just disqualified yourself ... a table in a
> database has nothing to do with this argument. You are using terminology
> from a completely different and unrelated field. A mathematical table is
the
> equivalent of an array in a programming language, which does fit the cont
ext
> of this "discussion".
>
> Thorsten
>
No, I am referring to tables in the sense that something like Lua uses
them. Its not a completely unrelated field, since I am talking about how
the data is stored and used, not **what** you do with it. A
mathematically array is **not** the only kind of table programming
languages support, and its hardly the most useful one, when dealing with
complex data types. Mind you, if the only kind of table you have used in
a programming language is a numerically indexed array, or mathematical
table, which is in fact what "most" of them support exclusively, its not
a surprise you think I am talking about something irrelevant to the
discussion.
--
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 wrote:
> Mind you, if the only kind of table you have used in
> a programming language is a numerically indexed array,
Actually, I have only ever used computers that support numerically indexed
arrays regardless of programming language. Everything else is superfluous
anyway.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <472a38dd@news.povray.org>, tho### [at] trfde says...
> Patrick Elliott wrote:
> > Mind you, if the only kind of table you have used in
> > a programming language is a numerically indexed array,
>
> Actually, I have only ever used computers that support numerically indexe
d
> arrays regardless of programming language. Everything else is superfluous
> anyway.
>
> Thorsten
>
Well, on a basic level this is the case, true, but high level tables
like Lua has allow you to index via both numerical and strings. They
also don't require that the indexes all have "equal" numbers of elements
for each level. Its more like a mixture of pointers and standard arrays,
so you can do stuff that, if you did it in some other language would
look more like:
type idx {
data as variant
link as pointer
}
dim myarray() as variant
dim index as idx
dim contents as idx
index.data = "Fred"
contents.data = 1
index.link = contents
myarray.add(index)
Or.. well something like that. Its not a strict array in the sense that
most languages handle it. Its actually a complex structure, which can
have different numbers at different layers, or even between different
indexes. Since the data types are all variant, you can have that contain
everything from a pointer to a new "array" for one index, or text for a
different on, or a numerical value for a third, even though the "index"
you are looking at is on the same "level" of the structure. Sort of if
you made "myarray()" above into:
dim myarray(3) as variant
myarray(1) = "Fred"
myarray(2) = 42
myarray(3) = newarray()
At least in theory. Its possible there are some constraints that require
the index to contain a similar data type or something, but just because
I haven't seen anyone use multiple index types doesn't mean it can't,
and there is no problem at all with having the "data" associated with an
index contain strings, numbers, objects, or even another table, as the
"data" in that element. Its sounds confusing as hell, but its very
flexible and you can do thing with it that are complicated and
irritating to manage in most other languages, where your arrays tend to
be one data type, and only one type, for the entire contents. Even ones
like VB, which use variants for most stuff, can have problems trying to
do this, since while you could define an array of variants, the commands
to handle the result are... not necessarily geared towards handling such
a structure.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
