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