In article <4710ec81$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > Gah!! This is exactly what I am talking about. And everyone else is 
> > instead saying, "Gosh, this is silly, why not just store every single
 
> > transform some place else, so it takes up even more memory, then apply
 
> > them all over again anyway, not from the history, but from a bunch of
 
> > arrays?" Feel like I am talking to a wall here.
> 
> Honestly, you're not being very clear about why you think your method is
 
> superior.  You might have something, but without transferring the ideas
 
> from your head to the keyboard, it's difficult to see why your mechanism
 
> is better.
> 
Point taken. I hope the other posts I have made today clear some of it 
up. I don't think, strictly speaking, a history makes much sense myself, 
but its similar to what I have been saying. As Warp points out, what I 
am talking about is semantically no different than what he has said, in 
most cases, but as I said in those posts, the issue isn't semantic, its 
associative. Objects don't "usually", when they track some internal set 
of data, rely on purely external sources for storing it, simply because 
that disassociates the data from the object that uses it. Not a horrible 
problem, but its also not semantically different to have some method to 
"copy" the transforms from one object to another, if you wanted to. It 
probably won't make a lick of sense to do so, unless they are themselves 
just copies of the same object, but its hardly a huge difference between 
doing:

ginger.copytransforms(fred)

vs.

ginger.applytrandforms(arbitrary_table)

The first one though is "associatively" clearer, even if its 
semantically the same. And, even if you wanted to do that, there hasn't 
exactly been a discussion on how you a) structure such a table, or b) 
get one out of, or into, an POVRay object that has subobjects. Mostly, 
its fairly irrelevant, until you figure out what the heck the internals 
are going to look like, or even if there are going to be any, other than 
just a static matrices (its kind of hard to have a non-static one, since 
doing so puts you right back at recording no just "what" the result is, 
but how you got it, so you can backtrack to a prior state). The only 
point you can "revert" to, without knowing that, is the one that existed 
when you first did some_object(<location>,size(s)) Hardly helpful, if 
you are trying to avoid having to redundantly store "every" change 
needed to get from there to the final result.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <471### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> Patrick Elliott wrote:
> > In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
> > says...
> >> Patrick Elliott wrote:
> >>> In article <470### [at] hotmailcom>, a_l### [at] hotmailcom
 
> >>> says...
> >>>> What I was saying is that we should distinguish between the 'first
 
> >>>> creation' and the 'final creation'. Calling both simply 'creation' w
ill 
> >>>>   lead to confusion (as shown is this thread. Much of what you and
 
> >>>> Patrck are writing does not make sense to me, because for me 'creati
on' 
> >>>> is 'final creation').
> >>>>
> >>> How about "intermediary" creations then, just to confuse things more.
 
> >>> lol Technically, by your definition, the object is never "created" un
til 
> >>> the frame in rendered, at least in any system like we are talking abo
ut, 
> >>> where each "frame" is defined not by re-running the entire script, bu
t 
> >>> only via the command "in" the script.
> >>>
> >>> In other words, in the current model we do this:
> >>>
> >>> render("myfile")
> >>>
> >>> in a true animation system, we do this:
> >>>
> >>> 'Set up a bunch of objects.
> >>> ...
> >>> render
> >>> 'Change the objects some.
> >>> ...
> >>> render
> >>> 'Change them some more.
> >>> ...
> >>> render
> >>>
> >>> The "render" step is explicit in the script, since it only happens 
> >>> "when" all the changes are made, not an external process that just ru
ns 
> >>> an SDL through it, and recalcs the data for everything as it does it,
 
> >>> based on the existing clock scheme, which is kind of limited. Mind yo
u, 
> >>> making that change, depending on how it was done, could break existin
g 
> >>> SDL. Mind you, a command that "requests" the prior behavior could be
 
> >>> used to solve that. 
> >> You could also assume that a render command is implicit at the end of
 
> >> parsing if none is given.
> >>
> > Yes, I had considered that, but its better to have a compatibility flag
, 
> > both so that someone doesn't try to run an old SDL, then wonder why it
 
> > didn't work right, and so that someone using a *new* SDL could be warne
d 
> > that they forgot to actually render anything. Its kind of a toss up 
> > though.
> > 
> There could be a problem with a compatibility flag if someone is 
> including some old code. Then again the #version 3.6; compatibility flag
 
> never gave problems. Actually, as you might have noticed, I would prefer
 
> a 'camera(Scene)' kind of syntax in stead of a 'render' command for many
 
> reasons (some not even mentioned anywhere yet). Which points more to a 
> compatibility flag than an implicit 'render' command.
> 
Only problem I could see with that is that someone may want to use 
multiple cameras, like say... stereoscopic effects. I mean, its not 
totally absurd to consider someone wanting to either a) render bath eyes 
at the same time, if they have the speed and the language allowed it, or 
even doing something crazier, like having a camera that "looks" at some 
other location, which is used as part of the image some place else. A 
good example would be something like a security booth. You have a 
monitor on the desk, which shows a kind of post process "filtered" 
effect in black and white, of what is "seen" by a camera that is also 
*visible* in the larger scene, but in color, as is most of the rest of 
what is in the camera view.

Yeah, I know, you can do two renders, one from the camera view, then 
post process that, then use the result as an image map on the monitor, 
but is is just an example. Its possible that someone could have a scene 
where this was either seriously impractical, or completely impossible, 
unless the "camera view" was being produced in the same render as the 
final image. Then again, what do I know. lol

-- 
void main () {
  If Schrödingers_cat is alive  
    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:
> Only problem I could see with that is that someone may want to use 
> multiple cameras, like say... stereoscopic effects. I mean, its not 
> totally absurd to consider someone wanting to either a) render bath eyes 
> at the same time, if they have the speed and the language allowed it, or 
> even doing something crazier, like having a camera that "looks" at some 
> other location, which is used as part of the image some place else. A 
> good example would be something like a security booth. You have a 
> monitor on the desk, which shows a kind of post process "filtered" 
> effect in black and white, of what is "seen" by a camera that is also 
> *visible* in the larger scene, but in color, as is most of the rest of 
> what is in the camera view.
> 
> Yeah, I know, you can do two renders, one from the camera view, then 
> post process that, then use the result as an image map on the monitor, 
> but is is just an example. Its possible that someone could have a scene 
> where this was either seriously impractical, or completely impossible, 
> unless the "camera view" was being produced in the same render as the 
> final image. Then again, what do I know. lol

So which is better:

A) Letting the users simply render two sets of images, with one being 
used as a texture in another; this is very easy, requiring only two 
scenes that are almost identical (the camera is positioned differently 
in the camera view), or

B) Writing the renderer so that a texture can be based on the camera 
view (with rays being traced, anti-aliased, usw...) of another place in 
the scene.

We already have A up and running just fine.  I use it all the time. 
Leaving out the trouble of render-wrangling a second set of images 
(i.e., putting them in a different directory after rendering), A is no 
more work than B for the user; the camera still has to be positioned and 
test-rendered for either method.

B will require work from programmers who are already busy with stuff 
that can't be pushed off onto the user, or if they can be, only at the 
expense of significantly reducing the user's productivity.  It also 
increases the size of the renderer, in order to provide the extra feature.

Now if the memory situation is very tight, then method B does have the 
advantage that the texture does not need to be stored in memory; but in 
almost every case of this kind the video image occupies less than a 
quarter of the final view, which means that the texture requires only 
one-quarter of the memory of the rendered image.  If your memory 
situation is that tight, maybe you need to get some more RAM.

Regards,
John

Post a reply to this message

Alain wrote:

> Using an array of transforms would be wastefull. It would uselessly use 
> extra memory. It would make rendering slow as the whole array will need 
> to be computed for every ray that encounter the object, as well as any 
> CSG operation that use that object. That array will need to be dynamic 
> as you can never tell beforehand how many transforms will be applyed to 
> any particular object, adding some useless overhead, and requiring still 
> more memory.

One reason you would need more then one forward or reverse transform 
during rendering is if the renderer were to support motion blur.  One 
transform stipulates the start-of-frame positioning of the object, and 
the other stipulates the end-of-fram positioning (you could even have a 
spline of transforms if you didn't want to linearly interpolate between 
the start and end, but that may be too hairy to be worth the trouble).

Regards,
John

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> See, I don't disagree with you about that at all. But it brings up a 
> problem how how you "tell" the parser that the object you are defining 
> is "supposed" to be changed later. It also doesn't address other issues.

  How are you going to tell it that regardless of the transformation array?

  The only "problem" your transformation array "solves" is that it makes
it possible to change individual transformations stored in that array.
However, that doesn't solve the issue of *how* you are going to change
those transformations in later frames. What kind of code will you write
in order to do that?

  And that's exactly why the transformation array is not needed: The exact
same code that can be used to change the array can also be used to apply
all the transformations (optionally modified from previous frames) to the
object.

  Besides, your array solution presents other problems which are not
problems in a "apply transformations with SDL code". For example, what
if you want to insert a new transformation somewhere in the series of
transformations? Or what if you want to remove some transformation?
What if you want an alternative series of transformations at different
frames?
  You would need to offer all kinds of functions to modify the array,
and the user needs to write some SDL code to call those modifications.

  However, with the same effort the user could simply call the functions
which apply transformations to the object directly. Adding or removing
transformations is simply a question of putting them in conditional
statements. Applying alternative series of transformations is simply a
question of if-else or switch blocks.

  There's no need for a transformation array.

> Sigh.. Your just getting it at all. The ***existing*** SDL assumes that 
> each "frame" is "static", as so is the object. Its not possible in the 
> current design to change the matrix for and object in "any" sense other 
> than in the final object.

  That's not a technical limitation. That's just a syntax limitation.

  It would be perfectly possible in the current POV-Ray to change the
transformation matrix of an existing object if someone simply added the
proper syntax for it. (And that's exactly one of the reasons why the
whole new SDL is being discussed. To add easy support for such things.)

> In an SDL that supports its own animation/render functions, you can't 
> have "static" objects.

  POV-Ray doesn't assume that objects are "static". It's just that there's
no syntax to change the transformation matrix of an existing object. Plain
and simple.

> 1. Track the transforms for the object, then simply 
> replace the one you need to change. 2. Generate a static object 
> "anyway", then apply your own transform to its parts, to produce the 
> result you want. Either way you are going to be using memory to do it.

  Why do you have this obsession that individual transformations *must*
be stored somewhere?

  You *apply* transformations in the SDL code. You don't *store* them
(not as individual transformations anyways). That's because the individual
transformations are already "stored" in the SDL code itself. Why do you
need to store them in two places?

  At each frame you simply execute that SDL which applies the transformations
to the objects.
  You are going to have to execute some SDL at each frame anyways (to
change transformations). It's not any more difficult to simply execute
the SDL code which applies all the transformations.

> Look, if you still think I am full of it, then why not agree on some 
> example concept, with a specific number of parts, etc. Then each of us 
> can give a psuedocode example of what the hell we are talking about, 
> because I am not entirely sure I am not missing something you are trying 
> to get across too.

  Let me see your suggestion about the new SDL code which modifies the
"transformation array" at each frame.
  My answer is that it's the exact same thing, but without the transformation
array. Simply apply all the transformations to the object at each frame.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> b) you 
> have to reset it back to the very first state it had **prior** to any 
> transforms, then reapply **all** of them.
> the later is just 
> absolutely stupid, since you might as well not even bother applying any 
> transforms to the original object(s), until you need, just before you 
> render it.

  Then the vast majority of renderers and rendering languages (eg. OpenGL)
are "absolutely stupid" because that's exactly what they do. That's exactly
what POV-Ray does currently as well.

  At each frame they reset the transformation matrix to the unit matrix
and then apply all the (possibly modified) transformations to it. That's
standard procedure, and it's by far the simplest and easiest way of
doing it. You don't necessarily need any data container to store all
the individual transformations because the individual transformations
are in the code you write (this is often the case eg. with OpenGL).

  (Sure, you can do it in other ways too in OpenGL, but resetting the
transformation matrix and applying all the transformations to it at
each frame is a common standard way of doing things. It's simple, easy
and fast, and it doesn't require any more memory than the code itself.)

  I simply can't understand why you think this is such a "stupid" idea.
It's a very simple and working idea. It keeps things simple, it doesn't
require any memory and it's easy to implement.

> Neither of them help your case, since they both require 
> somehow "tracking" what you did to the original, or storing all your 
> transforms, including the first state, in some other array.

  No, it doesn't. Writing an OpenGL application doesn't require you to
"track" all the transformations you have applied to every single object.
When you want to render a new frame in OpenGL, you simply reset the
transformation matrix and apply the same transformations to it (with
possibly modified values). That's it.
  The new SDL doesn't need to be any different from this.

  You don't seem to grasp the idea that all the transformations are
already "stored" in the very code that applies those transformations.
You don't need to store them anywhere else. Simply re-apply the same
transformations at each frame, and there you are.

> That just leaves the absurd claim that you can somehow 
> reset a matrix to a usable state without keeping a big array with "all" 
> of the transforms in it

  The current POV-Ray manages to do it. Most OpenGL applications manage
to do it. Most other renderers manage to do it.

  Just because you can't understand how they manage to do it doesn't mean
it's not possible and easy.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott wrote:
> No semantic difference, just associative.

In other words, you don't like the syntax.

> And when you are dealing with 
> objects that is often more important than semantics. 

I'm not sure what's more important about a programming language than 
knowing what the constructs mean.

But given that, now we're just arguing over syntax. That makes things a 
lot more clear.

> Semantically they are **identical**, associatively they are 
> **completely** different.

On the other hand, if you could do the latter and not the former, you'd 
have a much more limited language.

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

Patrick Elliott wrote:
> the issue isn't semantic, its associative. 

I'm not sure what your level of experience with programming is, but such 
things stop being problematic after a while.

 > Objects don't "usually", when they track some internal set
> of data, rely on purely external sources for storing it, simply because 
> that disassociates the data from the object that uses it.

Not if it's indexed by the object.

> ginger.copytransforms(fred)
> vs.
> ginger.applytrandforms(arbitrary_table)

Of course when you name one of them "fred" and the other 
"arbitrary_table", it's confusing. Don't do that.


I'm suggesting
   walking_transforms[ginger] = walking_transforms[fred].

Or even
   walking_transforms[ginger] = feminize(walking_transforms[fred])
or
   running_transforms[ginger] = walking_transforms[fred]

Then, eventually, you say
   ginger.apply(running_transforms[ginger])
   fred.apply(walking_transforms[fred])

If you have a set of global transforms (that always apply), you can
   extern function
     feminize(array of transforms) returns array of transforms;
   global_transforms[fred] = (....)
   global_transforms[ginger] = (....)
   frame_transforms[fred] = (clock*....)
   frame_transforms[ginger] = feminize(frame_transforms[fred])
   frame_transforms[freds_arm] = (rotate clock*y)
   ginger = object(...)
   fred = object(...)
   freds_arm = object(....)
   foreach object {ginger fred ...) {
     object.apply_transform(global_transforms[object])
     object.apply_transform(frame_transforms[object])
     object.render
   }
   freds_arm.apply_transform(global_transforms[fred])
   freds_arm.apply_transform(frame_transforms[fred])
   freds_arm.apply_transform(frame_transforms[freds_arm])


Maybe you should supply a similar bit of pseudo code showing a similar 
scene and show why your mechanism is more clear.

> The first one though is "associatively" clearer, even if its 
> semantically the same.

Except it only associates to the object. It doesn't "associate" what the 
*transform* is, only what object it applies to. Perhaps it's only clear 
to you.

Plus, if in your code, you have
   ginger.apply(walking_transforms[robot])
   fred.apply(walking_transforms[robot])
I think that's more clear than saying
   ginger.transforms = fred.transforms
because now you know they're both using the same
transforms and you know those transforms are
treating them both as robots.

 > And, even if you wanted to do that, there hasn't
> exactly been a discussion on how you a) structure such a table, 

It's structured the same way you'd structure yours, except it's a 
user-created object instead of a unique property defined by the 
renderer. This also has the advantage that you can (for example) pass it 
to user-defined functions without having to create an object just to 
carry it around.

> or b) get one out of, or into, an POVRay object that has subobjects. 

The same way you would.

> when you first did some_object(<location>,size(s)) Hardly helpful, if 
> you are trying to avoid having to redundantly store "every" change 
> needed to get from there to the final result.

I think if you want to argue that your syntax is superior to my syntax, 
while my syntax is more orthogonal and more flexible yet has similar 
semantics,

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

John VanSickle a écrit :

> B) Writing the renderer so that a texture can be based on the camera 
> view (with rays being traced, anti-aliased, usw...) of another place in 
> the scene.

There have been a POV-Ray patch which allowed to do that, you could have
a "portal" object (which, when, who, and what is out of my memory).

So I guess it's not so hard to do.

Fabien.

Post a reply to this message

Patrick Elliott wrote:
> In article <47109fba@news.povray.org>, war### [at] tagpovrayorg says...
>> Patrick Elliott <sel### [at] rraznet> wrote:
>>> You keep claiming that you can just somehow "untransform" 
>>> the matrix
>>   Do you understand the concept of resetting a transformation matrix?
>> Or is that concept way too difficult for you to comprehend?
>>
> Think I have already addressed most of this in the other post I made 
[snip]
> 
> Or do you want to beat the straw man some more?
> 
I am not familiar with that expression, but anyway here are my 2 cents.

What you deem necessary for animation is in my (and Warp's if I may 
speak for him) overkill. It may be handy for some situations but I think 
in the majority of cases I wouldn't use it. POV4, however, should make 
it possible and easy to use. So what this discussion should have been 
about is to what extend it has to be hardcoded in either the internal 
datastructures or in the syntax of the language. My (and presumably 
Warp's) opinion on this is that what you propose will be extremely easy 
to implement yourself within the new language for those cases where you 
need it. So it has no implication for the current POV4 discussion 
whatsoever. You are free to continue this discussion with warp of 
course, but it will be like talking to a wall, without being able to 
study the delicate texture of the stones.
The opinion that it is not needed is based on knowledge on how the 
current implementation works and some safe assumptions on what POV4 will 
allow at the minimum. However, you should watch the development closely 
that indeed these minimum requirements will be met. Or even better: 
create a list with those minimum requirements on the new wiki.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> My (and presumably 
> Warp's) opinion on this is that what you propose will be extremely easy 
> to implement yourself within the new language for those cases where you 
> need it.

  There could even be a library for that exact purpose, which could
perhaps more or less transparently add support for the feature he wants
(on a per-object basis).

  However, hard-coding it in the core code is a bad idea. The solution
must be more generic than that.

-- 
                                                          - Warp

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> B) Writing the renderer so that a texture can be based on the camera 
> view (with rays being traced, anti-aliased, usw...) of another place in 
> the scene.

  Optimally this would not be a core feature but more or less easily
implementable as a shader, assuming the new shader language has enough
expressive power. A pre-made such shader could be provided in a standard
library for convenience.

  (The big advantage of it being a shader is that it makes it easy for
the user to change it if he needs a slightly different effect.)

-- 
                                                          - Warp

Post a reply to this message

In article <4711cecb@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > See, I don't disagree with you about that at all. But it brings up a 
> > problem how how you "tell" the parser that the object you are defining
 
> > is "supposed" to be changed later. It also doesn't address other issues
.
> 
>   How are you going to tell it that regardless of the transformation arra
y?
> 
>   The only "problem" your transformation array "solves" is that it makes
> it possible to change individual transformations stored in that array.
> However, that doesn't solve the issue of *how* you are going to change
> those transformations in later frames. What kind of code will you write
> in order to do that?
> 
>   And that's exactly why the transformation array is not needed: The exac
t
> same code that can be used to change the array can also be used to apply
> all the transformations (optionally modified from previous frames) to the
> object.
> 
>   Besides, your array solution presents other problems which are not
> problems in a "apply transformations with SDL code". For example, what
> if you want to insert a new transformation somewhere in the series of
> transformations? Or what if you want to remove some transformation?
> What if you want an alternative series of transformations at different
> frames?
>   You would need to offer all kinds of functions to modify the array,
> and the user needs to write some SDL code to call those modifications.
> 
>   However, with the same effort the user could simply call the functions
> which apply transformations to the object directly. Adding or removing
> transformations is simply a question of putting them in conditional
> statements. Applying alternative series of transformations is simply a
> question of if-else or switch blocks.
> 
Huh? How? Your missing the point. The initial structure of the object 
**must** be static. Why? Because if it isn't, then you have to reparse 
the entire structure. Currently you can't tell something that you want 
to add transforms to the 6th nested object in some complex series of 
unions, nor can you "change" those. Its just not possible to do at all. 
The object, once it exists, is static on "all" levels other than the 
base union. All subobjects are inaccessible. That only gets worse when 
dealing with a change to the SDL that allows it to run like a program, 
instead of as a one pass, then reparse for the next frame, system, like 
we have now. If-else blocks won't work because by the time you get to 
the next frame all of the "code" that contains them will have already 
executed, and isn't reparsed, so those statements are **never** checked 
to determine what the new result will be. Instead you have to disconnect 
the object definition, the if-else statements and the execution, so that 
you 1) create an object with some static and some non-static transforms, 
2) render the first version, then 3) access those transforms you need to 
change. Yes, you could do that, sort of, now, but only via something 
like macros, and that won't work in this case, since you can't simply 
throw out the prior frames version, then reparse the macro. You have to 
have an already existing object, which you can make "some" adjustments 
to. Macros don't do that. A Macro would **recreate** the entire object 
each and every time. **Every** method that currently exists in the SDL 
works the way it does *precisely* because the assumption is that you 
won't be changing and *existing* object, but creating a **new** one, 
every single frame. The two implimentations are fundamentally different.

If not, then please, explain to me how I am wrong here. Tell me how, 
with something like an IK chain, you can **change** an object in the 
sub-chain **after** it has already been calculated and added to a union. 
I am willing to bet that if you **really** think about it, its not 
possible. It needs to be possible if you are running a script, instead 
of just parsing a single frame.

> > Sigh.. Your just getting it at all. The ***existing*** SDL assumes that
 
> > each "frame" is "static", as so is the object. Its not possible in the
 
> > current design to change the matrix for and object in "any" sense other
 
> > than in the final object.
> 
>   That's not a technical limitation. That's just a syntax limitation.
> 
>   It would be perfectly possible in the current POV-Ray to change the
> transformation matrix of an existing object if someone simply added the
> proper syntax for it. (And that's exactly one of the reasons why the
> whole new SDL is being discussed. To add easy support for such things.)
> 
Ok, fine. But how do you do that, without adding something that is at 
least semantically the same as what I propose? And why, again, does it 
make sense to store "every" transforms in some array, to be applied all 
at once, instead of maintaining an array of "existing" transforms 
applied the the object, then only adding to, changing or deleting the 
specific on you need to?

> > In an SDL that supports its own animation/render functions, you can't
 
> > have "static" objects.
> 
>   POV-Ray doesn't assume that objects are "static". It's just that there'
s
> no syntax to change the transformation matrix of an existing object. Plai
n
> and simple.
> 
> > 1. Track the transforms for the object, then simply 
> > replace the one you need to change. 2. Generate a static object 
> > "anyway", then apply your own transform to its parts, to produce the 
> > result you want. Either way you are going to be using memory to do it.
> 
>   Why do you have this obsession that individual transformations *must*
> be stored somewhere?
> 
>   You *apply* transformations in the SDL code. You don't *store* them
> (not as individual transformations anyways). That's because the individua
l
> transformations are already "stored" in the SDL code itself. Why do you
> need to store them in two places?
> 
Yes, they don't have to be. The can be calculated as you go, but they 
still have to then be **applied** individually, regardless of if you 
plan to repeated apply the same initial translate, then a changing 
rotate, then another translate, or something. It might not be "stored" 
any place, but you are still wasting code to do something that is 
functionally the same thing. But yes, if you want to do it that way, you 
could. I suppose, in that sense my idea just means that you have access 
to what ever "initial" state you started with, in a way that is more 
accessible than just returning the matrix and then wondering how the 
hell you got to there (since you can't exactly ask the code itself what 
transforms where needed to get to that point). So, OK, I admit, what I 
propose may not be strictly necessary, it might be useful some times, 
and its a little nicer to have such data "on" the object it effects, 
instead of seperate from it, when you do need it.

>   At each frame you simply execute that SDL which applies the transformat
ions
> to the objects.
>   You are going to have to execute some SDL at each frame anyways (to
> change transformations). It's not any more difficult to simply execute
> the SDL code which applies all the transformations.
> 
> > Look, if you still think I am full of it, then why not agree on some 
> > example concept, with a specific number of parts, etc. Then each of us
 
> > can give a psuedocode example of what the hell we are talking about, 
> > because I am not entirely sure I am not missing something you are tryin
g 
> > to get across too.
> 
>   Let me see your suggestion about the new SDL code which modifies the
> "transformation array" at each frame.
>   My answer is that it's the exact same thing, but without the transforma
tion
> array. Simply apply all the transformations to the object at each frame.
> 
Well, I think I am thinking more in terms of the data end, rather than 
the program end. I am thinking in terms of, "Automatic application of 
known transforms.", you are thinking more in terms of, "Manual 
application of any needed transforms." Both work. Your would use far 
less memory than mine, but it slightly obfuscates how the data is 
associated with the object, which is what I was thinking about when I 
got the idea. I wouldn't mind, on after thought, making the array itself 
even more option, so that objects where it could be easier to keep track 
of things with my method could use it. Basically, if you are going to 
use pre-calced arrays of actions, you could either apply them from a 
non-linked version, which would require "manual" application, or you 
could put the array on the object itself, and have to implicitly 
applied.

That might be a better idea anyway. For those cases where you are only 
dealing with "one" compound object, and you are not going to apply the 
transforms to anything else, being able to just define them once, then 
have the system auto-apply them, could help keep the code cleaner, and 
since in "that" case, you are using such an array anyway, having it 
associatively connected to the object itself, as least as far as the 
code is concerned, won't change how much memory is/isn't used. It just 
removes the need, in those cases, of having to remember to manually 
apply the transforms.

This means it wouldn't use the same syntax though. It would be something 
like:

fred.autotransforms = mytable

Where mytable would be the same array you use to do:

fred.applytransforms = mytable.main(1)

Presuming that the number in () was a frame number. A table could thus 
define a range of frames for a set of transforms, or even contain a 
structure for the entire object. The "array" would be seperate, as you 
suggest, but you could access it, "a = fred.autotransforms.main(0)" and
 
you get the benefit that you don't have to use the "applytransforms" 
command **ever** unless you are programatically calculating the results 
(instead of using a list).

You get what I intended, what you think would be better, and the *cost* 
in memory doesn't change by anything other than the pointer needed to 
link the "object" to the "array/table" used to store the transforms for 
each frame.

I admit, this makes more sense than what I was thinking, while still 
providing both the contextual associations I thought would be useful 
"and" the auto-application which imho, makes way more sense than having 
to write hundred of lines of nothing but object.applythis(blah), to get 
the same results, especially in cases where that isn't even necessary 
(like when using "pre-calced" transforms from a database or file).

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <471### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> Patrick Elliott wrote:
> > In article <47109fba@news.povray.org>, war### [at] tagpovrayorg says...
> >> Patrick Elliott <sel### [at] rraznet> wrote:
> >>> You keep claiming that you can just somehow "untransform" 
> >>> the matrix
> >>   Do you understand the concept of resetting a transformation matrix?
> >> Or is that concept way too difficult for you to comprehend?
> >>
> > Think I have already addressed most of this in the other post I made 
> [snip]
> > 
> > Or do you want to beat the straw man some more?
> > 
> I am not familiar with that expression, but anyway here are my 2 cents.
> 
> What you deem necessary for animation is in my (and Warp's if I may 
> speak for him) overkill. It may be handy for some situations but I think
 
> in the majority of cases I wouldn't use it. POV4, however, should make 
> it possible and easy to use. So what this discussion should have been 
> about is to what extend it has to be hardcoded in either the internal 
> datastructures or in the syntax of the language. My (and presumably 
> Warp's) opinion on this is that what you propose will be extremely easy
 
> to implement yourself within the new language for those cases where you
 
> need it. So it has no implication for the current POV4 discussion 
> whatsoever. You are free to continue this discussion with warp of 
> course, but it will be like talking to a wall, without being able to 
> study the delicate texture of the stones.
> The opinion that it is not needed is based on knowledge on how the 
> current implementation works and some safe assumptions on what POV4 will
 
> allow at the minimum. However, you should watch the development closely
 
> that indeed these minimum requirements will be met. Or even better: 
> create a list with those minimum requirements on the new wiki.
> 
Well, I have, in another post today, reversed my position somewhat. I 
still think an associative connection is useful, but that the method I 
suggested "is" a bit overkill and probably not strictly necessary. The 
modified concept allows for:

1. Associative connections between an array with the transforms needed, 
(which may include for multiple frames.), when needed.

2. Auto-magical application of those, instead of having the explicitly 
apply them.

3. No storage of anything "on" the object itself.

This loses the ability to track the "initial" state though.

But, one thing I do still think needs to remain is the idea that if you 
don't "explicitly" change a matrix, either via the automatic system or 
the manual code based one, it doesn't make sense to "reset" everything 
to the base state, then reapply things. Not sure how you work that 
though, since a change to a foot might have "its" matrix effected by 
transforms on the lower leg, upper leg, and even the full object. Do you 
just "save" the matrix for each object/union level, then reapply those 
transforms that effect them? If you reset them completely, then you are 
re-applying possibly hundreds of transforms, which you *must* store some 
how, when you might only be changing "one" in the entire chain. Its 
probably more cost effective to store all matrices at each level (i.e. 
the "default" state for that object/union), then only recalc those 
"specifically" effected by any change you later make. Hmm..

Oh, and "straw man" refers to side tracking an issue into something 
either not directly related to, or completely unrelated to, the main 
issue being discussed, usually, though not always, to avoid talking 
about the original subject. Its similar to "tilting at windmills".

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <471164bc@news.povray.org>, evi### [at] hotmailcom 
says...
> Patrick Elliott wrote:
> > Only problem I could see with that is that someone may want to use 
> > multiple cameras, like say... stereoscopic effects. I mean, its not 
> > totally absurd to consider someone wanting to either a) render bath eye
s 
> > at the same time, if they have the speed and the language allowed it, o
r 
> > even doing something crazier, like having a camera that "looks" at some
 
> > other location, which is used as part of the image some place else. A
 
> > good example would be something like a security booth. You have a 
> > monitor on the desk, which shows a kind of post process "filtered" 
> > effect in black and white, of what is "seen" by a camera that is also
 
> > *visible* in the larger scene, but in color, as is most of the rest of
 
> > what is in the camera view.
> > 
> > Yeah, I know, you can do two renders, one from the camera view, then 
> > post process that, then use the result as an image map on the monitor,
 
> > but is is just an example. Its possible that someone could have a scene
 
> > where this was either seriously impractical, or completely impossible,
 
> > unless the "camera view" was being produced in the same render as the
 
> > final image. Then again, what do I know. lol
> 
> So which is better:
> 
> A) Letting the users simply render two sets of images, with one being 
> used as a texture in another; this is very easy, requiring only two 
> scenes that are almost identical (the camera is positioned differently 
> in the camera view), or
> 
> B) Writing the renderer so that a texture can be based on the camera 
> view (with rays being traced, anti-aliased, usw...) of another place in
 
> the scene.
> 
> We already have A up and running just fine.  I use it all the time. 
> Leaving out the trouble of render-wrangling a second set of images 
> (i.e., putting them in a different directory after rendering), A is no 
> more work than B for the user; the camera still has to be positioned and
 
> test-rendered for either method.
> 
> B will require work from programmers who are already busy with stuff 
> that can't be pushed off onto the user, or if they can be, only at the 
> expense of significantly reducing the user's productivity.  It also 
> increases the size of the renderer, in order to provide the extra feature
.
> 
> Now if the memory situation is very tight, then method B does have the 
> advantage that the texture does not need to be stored in memory; but in
 
> almost every case of this kind the video image occupies less than a 
> quarter of the final view, which means that the texture requires only 
> one-quarter of the memory of the rendered image.  If your memory 
> situation is that tight, maybe you need to get some more RAM.
> 
> Regards,
> John
> 

(A) doesn't let you, that easily any way, place the camera where you are 
looking and it looking at its own result, which is looking at its own 
result, etc. Yeah, its still possible, but it usually requires feeding 
the same scene through multiple times. Its not **that** much different 
than using a reflective surface though, in terms of how it would work. 
You are just displacing the path of your ray to a new location, then 
continuing, until you reach your recursion limit. Would be fun to see 
how practical it was to do that at least, even if it proved too 
inconvenient to use.

-- 
void main () {
  If Schrödingers_cat is alive  
    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

I think this is getting to be how to implement something
vrs what would be a good language feature.

It might be nice to have better animation support in
the language itself, something like ...

#declare leg = MOB {
   skeleton {
      thigh connected_to knee
      knee connected_to shin
      shin connected_to foot
      thigh { length 1 elasticity 0 mass 1.5 }
      knee { length 0.1 elasticity 0 joint_spring 1 mass 0.1 rest_bend 
<0,0,0>}
      shin { length 1 elasticity 0 joint_spring 1 mass 0.75 rest_bend 
<30,0,0>}
      foot { length 0.3 elasticity 0.1 joint_spring 0.5 mass 0.2 rest_bend 
<90,0,0>}
   }
   skin {
      thigh looks_like {cylinder{..}}
      knee looks_like {sphere{..}}
      thigh looks_like {cylinder{..}}
      foot looks_like {box{...}}
   }
},

MOB {
   start_at_location <...> at_time 0
   waypoint <...> at_time 0.5
   end_at_location <...> at_time 1
   movement {bend knee <80,0,0> velocity 0.25} at_time 0.51
}
post_process {save_animation "leg.mpg"}

The end user probably doesn't care if the data is stored in memory,
or written to the disk, how the inverse kinematics is implemented.
just that there's an easy way to do things like knee-jerking,
and save and view the animations.

-----
500 Internal Server Error
A team of highly trained monkeys has been dispatched to deal with this 
situation. Please report this incident to customer service.
Also, please include the following information in your error report: BANANAS

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> Huh? How? Your missing the point. The initial structure of the object 
> **must** be static. Why? Because if it isn't, then you have to reparse 
> the entire structure.

  I didn't understand that.

> Currently you can't tell something that you want 
> to add transforms to the 6th nested object in some complex series of 
> unions

  That's a syntax limitation in the current SDL, not a technical one.

> nor can you "change" those.

  It would be possible to change them if the proper syntax would be added.

> The object, once it exists, is static on "all" levels other than the 
> base union.

  It just looks like it for the simple reason that the current SDL has no
syntax for modifying it. AFAIK there isn't any technical limitation to this,
just that the SDL hasn't been enhanced to do this.

> That only gets worse when 
> dealing with a change to the SDL that allows it to run like a program, 

  You mean the current SDL is not "run like a program"? How so?

> If-else blocks won't work because by the time you get to 
> the next frame all of the "code" that contains them will have already 
> executed, and isn't reparsed

  1) If code is not executed at each frame at all, by which method are
you suggesting the user could change some transformations at each frame?

  2) Why do you think the new SDL should have byte-compilation and even
JIT-compilation support? Just for fun? No, for the precise reason that
it doesn't need to be *parsed* again and again, just parsed once and then
executed as many times as necessary.

> so those statements are **never** checked 
> to determine what the new result will be.

  Why have such a stupid limitation? There's no reason nor need to.

> Instead you have to disconnect 
> the object definition, the if-else statements and the execution, so that 
> you 1) create an object with some static and some non-static transforms, 
> 2) render the first version, then 3) access those transforms you need to 
> change.

  How are you supposed to do step 3 without executing any code, like you
stated above?

  Even if it's done by executing some code, why would it be any more
difficult to apply a set of transformations to the object than it would
be to modify a set of transformations in the object? It's basically the
same thing (except that the former doesn't need to waste so much memory
needlessly).

> Yes, you could do that, sort of, now, but only via something 
> like macros, and that won't work in this case, since you can't simply 
> throw out the prior frames version, then reparse the macro.

  Again: Why do you think that the new SDL should have byte-compilation
and even JIT-compilation support?

  And also: How else are you supposed to change the object at each frame?

> You have to 
> have an already existing object, which you can make "some" adjustments 
> to.

  Without executing any code? How exactly?

  And again: Why would it be any easier to modify an array of transformations
than it would be to apply a set of transformations to the object?

> Macros don't do that. A Macro would **recreate** the entire object 
> each and every time.

  You are the only one talking about recreating objects here. I don't
understand why.

  I have been talking about applying sets of transformations to existing
objects.

  (And besides, it should be possible to create *new* objects and delete
existing ones at each frame, for memory optimization reasons.)

> **Every** method that currently exists in the SDL 
> works the way it does *precisely* because the assumption is that you 
> won't be changing and *existing* object, but creating a **new** one, 
> every single frame. The two implimentations are fundamentally different.

  No, the current SDL works like it works because of it's based on 10 years
old code. It's exactly why a rewriting is planned.

> If not, then please, explain to me how I am wrong here. Tell me how, 
> with something like an IK chain, you can **change** an object in the 
> sub-chain **after** it has already been calculated and added to a union. 

  By writing SDL code which applies transformations to it. In the exact
same way as your solution, but without the need for the useless arrays.

> I am willing to bet that if you **really** think about it, its not 
> possible.

  So in your opinion it is possible to change an array of transformations
at each frame, but it is not possible to apply a set of transformations at
each frame?

  So what is it that makes the difference?

> >   It would be perfectly possible in the current POV-Ray to change the
> > transformation matrix of an existing object if someone simply added the
> > proper syntax for it. (And that's exactly one of the reasons why the
> > whole new SDL is being discussed. To add easy support for such things.)
> > 
> Ok, fine. But how do you do that, without adding something that is at 
> least semantically the same as what I propose?

  It wouldn't be very much different, and that's exactly my point.
The only difference is that your "transformation array" is useless and
completely unneeded for this.

> And why, again, does it 
> make sense to store "every" transforms in some array, to be applied all 
> at once

  Eh, that's exactly what I am asking you. There's no need for any array.

>, instead of maintaining an array of "existing" transforms 
> applied the the object, then only adding to, changing or deleting the 
> specific on you need to?

  There's no need to do it that way. That's only one possibility of doing
it. A possibility seldom needed or used. That's not how rendering works
in general out there.

> >   You *apply* transformations in the SDL code. You don't *store* them
> > (not as individual transformations anyways). That's because the individual
> > transformations are already "stored" in the SDL code itself. Why do you
> > need to store them in two places?
> > 
> Yes, they don't have to be. The can be calculated as you go, but they 
> still have to then be **applied** individually, regardless of if you 
> plan to repeated apply the same initial translate, then a changing 
> rotate, then another translate, or something. It might not be "stored" 
> any place, but you are still wasting code to do something that is 
> functionally the same thing.

  It's not "wasted code". Your solution is to first write code to initialize
the array for the first time and then at each frame run some other code
which modifies the array.
  The general solution (used often eg. in OpenGL) is to write just one
routine which applies the transformations (possibly depending on some
variables, etc) at each frame. This can actually save coding because
basically you are only doing the initialization step. (If the object
is not modified between frames then running this code can be skipped,
of course.)

  (Of course if you really *want* to have an array which you modify and
then apply, you can. However, you are not forced to use one.)

> But yes, if you want to do it that way, you 
> could. I suppose, in that sense my idea just means that you have access 
> to what ever "initial" state you started with

  The problem with your solution is that it hard-codes one data container
which is not very flexible. And what makes it worse is that there just
isn't need for such a data container.

> in a way that is more 
> accessible than just returning the matrix and then wondering how the 
> hell you got to there

  You don't read a transformation matrix and try to modify it. You reset
the transformation matrix and apply the transformations to it. That's
standard procedure.
  The chain of transformations is already "stored" in the very code
which applies those transformations. In your proposed solution this
chain of transformations would be located at two places: In the array
and the code which initializes the array. This is redundant and unneeded.

  (Besides, related to the earlier discussion in this post, even having
such arrays doesn't at all solve the problem of how to transform sub-objects
in a deeply-nested union.)

> So, OK, I admit, what I 
> propose may not be strictly necessary, it might be useful some times, 

  That's exactly the point: *Sometimes*

  The thing is, if *sometimes* you would need such an array, you can
create one. There could even be some kind of library to aid you doing
this. But the point is that this specific solution should not be forced
on the user since it's not necessary.

  This kind of specific solution should not be something done in the
core code. The core code should have a more generic solution.

> >   Let me see your suggestion about the new SDL code which modifies the
> > "transformation array" at each frame.
> >   My answer is that it's the exact same thing, but without the transformation
> > array. Simply apply all the transformations to the object at each frame.
> > 
> Well, I think I am thinking more in terms of the data end, rather than 
> the program end. I am thinking in terms of, "Automatic application of 
> known transforms.", you are thinking more in terms of, "Manual 
> application of any needed transforms."

  There's nothing stopping you from automatically applying transforms
to the object from some data. Your "array" solution makes absolutely
no difference in this.

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> It might be nice to have better animation support in
> the language itself, something like ...

  IMO it would be better if things like skeletal animation would be
a library instead of being a core feature of the scripting language.

  Being a library makes it more flexible and easier to modify. Being
a hard-coded inner feature makes it rigid and hard to modify.

-- 
                                                          - Warp

Post a reply to this message

>> It might be nice to have better animation support in
>> the language itself, something like ...
>
>  IMO it would be better if things like skeletal animation would be
> a library instead of being a core feature of the scripting language.
>
>  Being a library makes it more flexible and easier to modify. Being
> a hard-coded inner feature makes it rigid and hard to modify.

Perhaps more flexible, but a language syntax for animation
that is designed  to be human readable would be easier to
modify the scenes.
(by definition, since it would be designed that way)

Are we going to put language re-write rules into the SDL?
If so then an #include "animation.inc" could make such
syntax as the previous example optional and easily modified.
Something like the following, which is perty verbose and ugly,
(and incomplete) but only needs to be included by the average
user...

#define MOB {
   #require MOB_IDENTIFIER | MOB_ITEMS
   MOB_ITEMS {
      #require skeleton {SKELETON_ITEMS}
      #require skin {SKIN_ITEMS}
   }
   SKELETON_ITEMS {
      #require [BONE_IDENTIFIER {}]
      #optional [BONE_IDENTIFIER_1 conected_to
                      BONE_IDENTIFIER_2] {
         #local BONE_IDENTIFIER_2_LOCATION =
                   BONE_IDENTIFIER_1_LOCATION + transforms..
     }
   }
   SKIN_ITEMS {
      #require [BONE_IDENTIFIER looks_like {OBJECT_IDENTIFIER}]
   }
   #optional start_at_location VECTOR at_time FLOAT {
      #if (clock = FLOAT) #local LOCATION = FLOAT; #end
   }
   #optional end_at_location VECTOR at_time FLOAT {
      #if (clock = FLOAT) #local LOCATION = FLOAT; #end
   }
}

Post a reply to this message

Patrick Elliott wrote:

> (A) doesn't let you, that easily any way, place the camera where you are 
> looking and it looking at its own result, which is looking at its own 
> result, etc. Yeah, its still possible, but it usually requires feeding 
> the same scene through multiple times. Its not **that** much different 
> than using a reflective surface though, in terms of how it would work. 
> You are just displacing the path of your ray to a new location, then 
> continuing, until you reach your recursion limit. Would be fun to see 
> how practical it was to do that at least, even if it proved too 
> inconvenient to use.

This is precisely what occurred to me as I was writing the stuff above; 
the texture is really a kind of reflection/refraction that displaces the 
eye of the new ray in addition to changing the direction, so it would 
certainly be very simple to implement.

BUT

I'm not so sure that it's a great priority.

Regards,
John

Post a reply to this message

In article <4713433c@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Huh? How? Your missing the point. The initial structure of the object
 
> > **must** be static. Why? Because if it isn't, then you have to reparse
 
> > the entire structure.
> 
>   I didn't understand that.
> 
> > Currently you can't tell something that you want 
> > to add transforms to the 6th nested object in some complex series of 
> > unions
> 
>   That's a syntax limitation in the current SDL, not a technical one.
> 
> > nor can you "change" those.
> 
>   It would be possible to change them if the proper syntax would be added
.
> 
> > The object, once it exists, is static on "all" levels other than the 
> > base union.
> 
>   It just looks like it for the simple reason that the current SDL has no
> syntax for modifying it. AFAIK there isn't any technical limitation to th
is,
> just that the SDL hasn't been enhanced to do this.
> 
> > That only gets worse when 
> > dealing with a change to the SDL that allows it to run like a program,
 
> 
>   You mean the current SDL is not "run like a program"? How so?
> 
> > If-else blocks won't work because by the time you get to 
> > the next frame all of the "code" that contains them will have already
 
> > executed, and isn't reparsed
> 
>   1) If code is not executed at each frame at all, by which method are
> you suggesting the user could change some transformations at each frame?
> 
>   2) Why do you think the new SDL should have byte-compilation and even
> JIT-compilation support? Just for fun? No, for the precise reason that
> it doesn't need to be *parsed* again and again, just parsed once and then
> executed as many times as necessary.
> 
> > so those statements are **never** checked 
> > to determine what the new result will be.
> 
>   Why have such a stupid limitation? There's no reason nor need to.
> 
> > Instead you have to disconnect 
> > the object definition, the if-else statements and the execution, so tha
t 
> > you 1) create an object with some static and some non-static transforms
, 
> > 2) render the first version, then 3) access those transforms you need t
o 
> > change.
> 
>   How are you supposed to do step 3 without executing any code, like you
> stated above?
> 
.... Ok, read this far and you keep repeating the same assertion that I 
said the "new" SDL wouldn't execute any code, which is only "partly" 
true. Sure, it would have to execute some code to change the data being 
used, and a "render" command, but it wouldn't have to execute 
instruction for every single sub-object in the main object to do so. 
That would happen implicitly. I am sorry I wasn't clear about that 
point. And it was in no way meant to imply that more direct methods 
wouldn't be available. But, its a mute point, since in this same post I 
admit some of the concept was badly considered anyway.

> ...
Ok, lets continue from here, since this is where I admit that I might 
have been arguing something that... well, while it would have worked, a 
better compromise exists, which does the things I intended, without the 
things I am more than willing to admit I hadn't thought out well.

> > So, OK, I admit, what I 
> > propose may not be strictly necessary, it might be useful some times,
 
> 
>   That's exactly the point: *Sometimes*
> 
>   The thing is, if *sometimes* you would need such an array, you can
> create one. There could even be some kind of library to aid you doing
> this. But the point is that this specific solution should not be forced
> on the user since it's not necessary.
> 
>   This kind of specific solution should not be something done in the
> core code. The core code should have a more generic solution.
> 
> > >   Let me see your suggestion about the new SDL code which modifies th
e
> > > "transformation array" at each frame.
> > >   My answer is that it's the exact same thing, but without the transf
ormation
> > > array. Simply apply all the transformations to the object at each fra
me.
> > > 
> > Well, I think I am thinking more in terms of the data end, rather than
 
> > the program end. I am thinking in terms of, "Automatic application of
 
> > known transforms.", you are thinking more in terms of, "Manual 
> > application of any needed transforms."
> 
>   There's nothing stopping you from automatically applying transforms
> to the object from some data. Your "array" solution makes absolutely
> no difference in this.
> 
No it doesn't. And, as I post in a later sub thread, there is a solution 
to that, which does what you want, and what I want. Which is to have the 
"array" or "table" used be linked to the object only through an 
associative pointer. The trick being that you could, as I describe 
there, implicitly have the table of transforms applied at the render 
step, saving the need to explicitly apply them, while "still" allowing 
for direct application in cases where you need to calculate those 
changes on the fly. Basically, if you know that object X is already 
following a "precise" set of predetermined actions, and you have no need 
to change them programically, put them in a table, link the table, then 
have the parser/post parser/engine, or what ever apply them via that 
mechanism, instead of "requiring" them to be applied implicitly. This 
both a) allows such tables of actions to be automated and b) maintains 
the "associative" connection I was looking for in such cases, making it 
easier to keep track of just "which" object the table belongs to.

Mind you, I fully expect you to argue that this is just as silly and 
useless. lol

-- 
void main () {
  If Schrödingers_cat is alive  
    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

Tim Attwood <tim### [at] comcastnet> wrote:
> Perhaps more flexible, but a language syntax for animation
> that is designed  to be human readable would be easier to
> modify the scenes.
> (by definition, since it would be designed that way)

  Not necessarily. A script-based solution may be equally easy to
understand, but much more flexible (because the implementation is
easy to change).

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott escribió:
>>
> Sigh.. Your just getting it at all. The ***existing*** SDL assumes that ...

"You really don't understand why the current one is the way it is, do you?"

Post a reply to this message

Warp escribió:
> andrel <a_l### [at] hotmailcom> wrote:
>> My (and presumably 
>> Warp's) opinion on this is that what you propose will be extremely easy 
>> to implement yourself within the new language for those cases where you 
>> need it.
> 
>   There could even be a library for that exact purpose, which could
> perhaps more or less transparently add support for the feature he wants
> (on a per-object basis).

#macro applyTransforms(Object, Trans)
     #local I=0;
     object {
     Object
     #while (I<dimension_size(Trans,1))
         transform { Trans[I] }
         #local I=I+1;
     #end
     }
#end

Modify the Transforms array whenever you want to, then call 
applyTransforms at the end of the script.

Usage:
#declare Transforms=array[4];
#declare Transforms[0] = transform { rotate x*20 };
//no reason to have a single transformation
#declare Transforms[1] = transform { translate <1,2,3> rotate y*45 };
#declare Transforms[2] = transform { scale 1.1 };
#declare Transforms[3] = transform { rotate y*20 };
...
//modify existing transformation
#declare Transforms[0] = transform { rotate x*21 };

Then call the macro and be done with it. We don't need any stinking 
transformation array built-in (also, if POV did it automatically, it 
would keep [1] as two entries).

Post a reply to this message

In article <471d231d$1@news.povray.org>, 
nic### [at] gmailisthebestcom says...
> Patrick Elliott escribió:
> >>
> > Sigh.. Your just getting it at all. The ***existing*** SDL assumes that
 ...
> 
> "You really don't understand why the current one is the way it is, do you
?"
> 
Umm. There hasn't been a single post on this subject for some time. And 
yes, I know damn well why its the way it is *now*, its based on DKBTrace 
from ages ago, has maintained compatibility clear back that far (more or 
less) and **never** was designed to be used to do complex animations, 
without external methods to run them. No one ever built in a language 
flexible enough to bypass the need for dozens of external applications, 
to do all the stuff it can't.

What exactly is the point of harping on a few sentences out of dozens of 
things I have posted on this, ***after*** I already admitted, had you 
bothered to read anything other than this post, that my idea was flawed, 
you could still get what I was looking for in a way that isn't too 
dissimilar from what Warp was suggesting instead and that the other 
people had a point about storing the stuff the way I suggested being a 
bad idea? Other than, that is, to be a bigger ass than I made myself 
look with the comment you are quoting?

Besides, we are not discussing why the holy book of POVRay demands that 
all things continue to work as they do, we are talking about what 
changes *may* be useful to make it easier to do things, and having 
better object handling, and a better script system, is a major 
improvement over the mess we have now, where the internals are hard to 
add to, the script language barely qualifies as a script, the import 
features only handle bitmaps and comma deliminated text (which nothing 
in **any** other application that produces text data uses), and where 
we, more often than not, have to rely on some third parties closed 
source application to *partly* convert from A to B, so that we can use a 
plugin for that, also closed source, which hasn't changed since POVRay 
1.0, to *export* the now binary format back into a text format POVRay 
can use, only it can't, since its missing 50% of everything that wasn't 
possible to export to POVRay 1.0, along with things it exported wrong, 
and things that can't be exported at all, in that way, because they 
don't work the same way any more (triangles in a mesh, for example, 
which overlap, so the *current* versions delete as deleterious to the 
object, even though it leaves huge holes in it without them).

The point is to talk about how to improve this, not what reasons there 
are/where for why it works as it does now. Even if I could quote the 
entire code base for the engine layer by rote it wouldn't change the 
basic fact that we need to adjust how some things in it work, if we want 
to be taken seriously, instead of looked at as a bunch of fools that 
still sit in their basement, doing the equivalent of making the first 
8080 based computer play Jingle Bells, by flipping mechanical switches 
to program it.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 know damn well why its the way it is *now*

  Once again you do a pretty good job at hiding it.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott escribió:
> What exactly is the point of harping on a few sentences out of dozens of 
> things I have posted on this, ***after*** I already admitted, had you 
> bothered to read anything other than this post, that my idea was flawed, 
> you could still get what I was looking for in a way that isn't too 
> dissimilar from what Warp was suggesting instead and that the other 
> people had a point about storing the stuff the way I suggested being a 
> bad idea? Other than, that is, to be a bigger ass than I made myself 
> look with the comment you are quoting?

Sorry, I'm still catching up with posts (in chronological order, at 
least within threads), and I usually reply them as I read them, not 
after reading the whole thread. Bad habit, maybe.

Post a reply to this message

In article <471f19ab@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > I know damn well why its the way it is *now*
> 
>   Once again you do a pretty good job at hiding it.
> 
Snort. How so. I am just repeating what someone else said, that most of 
why it works as it does is a relic of how it evolved, not an intended 
design choice, which was either the best option for how to do it, or the 
best way to do it in a new design. While I might not know a lot of 
specifics, I don't notice you continuing to complain about my idea, 
after I acknowledged that you could get the two things I thought would 
be useful **without** the concept I originally suggested. I presumed the 
complete lack of any response meant that yeah, it would be OK to have 
some automated matrix creation, when direct control isn't needed, and 
that linking that via an associative pointer on the object (which if 
null would assume you plan to make the transforms yourself later), 
instead of having to explicitly tell it to use table X for frame 1-10, 
table Y for frame 11-50, etc. You just tell it, "Use this table until I 
tell you otherwise.", and no more memory gets used that with your idea 
(well, except for a few pointers to the date, but geeze...)

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <471fc224@news.povray.org>, 
nic### [at] gmailisthebestcom says...
> Patrick Elliott escribió:
> > What exactly is the point of harping on a few sentences out of dozens o
f 
> > things I have posted on this, ***after*** I already admitted, had you
 
> > bothered to read anything other than this post, that my idea was flawed
, 
> > you could still get what I was looking for in a way that isn't too 
> > dissimilar from what Warp was suggesting instead and that the other 
> > people had a point about storing the stuff the way I suggested being a
 
> > bad idea? Other than, that is, to be a bigger ass than I made myself 
> > look with the comment you are quoting?
> 
> Sorry, I'm still catching up with posts (in chronological order, at 
> least within threads), and I usually reply them as I read them, not 
> after reading the whole thread. Bad habit, maybe.
> 
That's OK. I kind of over reacted. It was like 3 days since anyone 
bothered to post anything about it, and the first thing someone did was 
a rant about my behavior, which I admit wasn't too congenial at that 
point in the conversation thread. :p But, I have some times done the 
same thing myself, when dropping in to the middle of a long series of 
posts, so...

-- 
void main () {
  If Schrödingers_cat is alive  
    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 presumed the 
> complete lack of any response meant that yeah, it would be OK to have 
> some automated matrix creation, when direct control isn't needed, and 
> that linking that via an associative pointer on the object (which if 
> null would assume you plan to make the transforms yourself later), 
> instead of having to explicitly tell it to use table X for frame 1-10, 
> table Y for frame 11-50, etc. You just tell it, "Use this table until I 
> tell you otherwise.", and no more memory gets used that with your idea 

  What I want to see is a generic solution. Your propositions just sound
like you are suggesting that the core code has to support the notion of
"transformation arrays" specifically. Such a transformation array does
not actually solve any relevant problem, but it only introduces one
possible (and seldom used) way of applying several consecutive transformations
to the object.

  It would be much better if the core code would simply have a more
generic "engine" so that you can easily write your own preferred solutions
to whatever problem you are having (not just transformations, but
everything else too), and maybe write a library with these solutions.
Transformation arrays are not something to be put into the core code,
but into a library, if anywhere.

  Also, being able to say "use this until X" is a specific solution,
and should not be a property of the core engine. Again, this should be
something you can implement yourself, and perhaps create a library
from it.

  Hard-coding specific solutions makes the core code monolithic, rigid
and hard to extend. It only adds a bunch of specific solutions which
are not needed to be there.

  IMO the core engine should only contain the fundamental features of the
raytracer which must be there either because they simply cannot be
implemented with scripting or implementing them in scripting would be very
inefficient or cumbersome.
  Certainly solutions on how to individually store series of transformations
is not such a thing.

  The more that can be removed from the core engine and implemented with
scripting, the better. This makes it easier to enhance the renderer and
implement new algorithms.

  For example, one thing I envision and hope could be removed from the
core engine and into a scripting shader is surface reflection. After all,
reflection is nothing more than calculating the direction of the reflected
ray from the direction of the incoming ray and the normal vector, and then
tracing a new ray towards that direction, and mixing the returned color
with the current one. This could be an ideal thing for a shader to do.
My hope is that the shaders in the new scripting language will be efficient
enough so that this will not slow down the rendering measurably, and thus
it will be possible to implement it as shaders instead of being a core
engine feature.

  If this is possible, then it becomes possible to change the way reflection
is calculated by writing your own reflection shaders.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott escribió:
> In article <471fc224@news.povray.org>, 
> nic### [at] gmailisthebestcom says...
>> Patrick Elliott escribió:
>>> What exactly is the point of harping on a few sentences out of dozens of 
>>> things I have posted on this, ***after*** I already admitted, had you 
>>> bothered to read anything other than this post, that my idea was flawed, 
>>> you could still get what I was looking for in a way that isn't too 
>>> dissimilar from what Warp was suggesting instead and that the other 
>>> people had a point about storing the stuff the way I suggested being a 
>>> bad idea? Other than, that is, to be a bigger ass than I made myself 
>>> look with the comment you are quoting?
>> Sorry, I'm still catching up with posts (in chronological order, at 
>> least within threads), and I usually reply them as I read them, not 
>> after reading the whole thread. Bad habit, maybe.
>>
> That's OK. I kind of over reacted. It was like 3 days since anyone 
> bothered to post anything about it, and the first thing someone did was 
> a rant about my behavior, which I admit wasn't too congenial at that 
> point in the conversation thread. :p But, I have some times done the 
> same thing myself, when dropping in to the middle of a long series of 
> posts, so...
> 

I have once replied to year-old threads without checking the date first...

Post a reply to this message

Nicolas Alvarez nous apporta ses lumieres en ce 2007/10/25 14:08:
> Patrick Elliott escribió:
>> In article <471fc224@news.povray.org>, 
>> nic### [at] gmailisthebestcom says...
>>> Patrick Elliott escribió:
>>>> What exactly is the point of harping on a few sentences out of 
>>>> dozens of things I have posted on this, ***after*** I already 
>>>> admitted, had you bothered to read anything other than this post, 
>>>> that my idea was flawed, you could still get what I was looking for 
>>>> in a way that isn't too dissimilar from what Warp was suggesting 
>>>> instead and that the other people had a point about storing the 
>>>> stuff the way I suggested being a bad idea? Other than, that is, to 
>>>> be a bigger ass than I made myself look with the comment you are 
>>>> quoting?
>>> Sorry, I'm still catching up with posts (in chronological order, at 
>>> least within threads), and I usually reply them as I read them, not 
>>> after reading the whole thread. Bad habit, maybe.
>>>
>> That's OK. I kind of over reacted. It was like 3 days since anyone 
>> bothered to post anything about it, and the first thing someone did 
>> was a rant about my behavior, which I admit wasn't too congenial at 
>> that point in the conversation thread. :p But, I have some times done 
>> the same thing myself, when dropping in to the middle of a long series 
>> of posts, so...
>>
> 
> I have once replied to year-old threads without checking the date first...
Done the same, several times. Now, I double-check to try to not reply to threads 
older than a month.

-- 
Alain
-------------------------------------------------
Please hassle me, I thrive on stress.

Post a reply to this message

In article <472079f9@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > I presumed the 
> > complete lack of any response meant that yeah, it would be OK to have
 
> > some automated matrix creation, when direct control isn't needed, and
 
> > that linking that via an associative pointer on the object (which if 
> > null would assume you plan to make the transforms yourself later), 
> > instead of having to explicitly tell it to use table X for frame 1-10,
 
> > table Y for frame 11-50, etc. You just tell it, "Use this table until I
 
> > tell you otherwise.", and no more memory gets used that with your idea
 
> 
>   What I want to see is a generic solution. Your propositions just sound
> like you are suggesting that the core code has to support the notion of
> "transformation arrays" specifically. Such a transformation array does
> not actually solve any relevant problem, but it only introduces one
> possible (and seldom used) way of applying several consecutive transforma
tions
> to the object.
> 
>   It would be much better if the core code would simply have a more
> generic "engine" so that you can easily write your own preferred solution
s
> to whatever problem you are having (not just transformations, but
> everything else too), and maybe write a library with these solutions.
> Transformation arrays are not something to be put into the core code,
> but into a library, if anywhere.
> 
>   Also, being able to say "use this until X" is a specific solution,
> and should not be a property of the core engine. Again, this should be
> something you can implement yourself, and perhaps create a library
> from it.
> 
>   Hard-coding specific solutions makes the core code monolithic, rigid
> and hard to extend. It only adds a bunch of specific solutions which
> are not needed to be there.
> 
>   IMO the core engine should only contain the fundamental features of the
> raytracer which must be there either because they simply cannot be
> implemented with scripting or implementing them in scripting would be ver
y
> inefficient or cumbersome.
>   Certainly solutions on how to individually store series of transformati
ons
> is not such a thing.
> 
>   The more that can be removed from the core engine and implemented with
> scripting, the better. This makes it easier to enhance the renderer and
> implement new algorithms.
> 
>   For example, one thing I envision and hope could be removed from the
> core engine and into a scripting shader is surface reflection. After all,
> reflection is nothing more than calculating the direction of the reflecte
d
> ray from the direction of the incoming ray and the normal vector, and the
n
> tracing a new ray towards that direction, and mixing the returned color
> with the current one. This could be an ideal thing for a shader to do.
> My hope is that the shaders in the new scripting language will be efficie
nt
> enough so that this will not slow down the rendering measurably, and thus
> it will be possible to implement it as shaders instead of being a core
> engine feature.
> 
>   If this is possible, then it becomes possible to change the way reflect
ion
> is calculated by writing your own reflection shaders.
> 
> 
Ok.. But then the question is, why would pulling some things out of the 
core be "more efficient". But yeah, presuming you can add plugins that 
are compiled somehow, so as to speed up operation, instead of doing 
***all of it*** in SDL, then you could tokenize the feature as a core 
attribute of "POV_Object", which would then be directly inherited by all 
other object types:

sphere{ <...>, ...
  autotransforms{[table]}
}

Much nicer, since you can then use it "in" the existing SDL format, 
while ignoring it if not needed. The alternative is to extend every 
object you personally need to have do it, like:

mysphere extends sphere{
  Add data_type autotransforms as pointer
  event self.transform("mytransforms")}
mysphere {<...>, ...
  autotranforms ...

function mytransforms(object) {
  if exist object.autotransforms then {
    ... do the stuff to apply them.
  else
    post_error "Object does not contain this data type."
    stop
  }
}

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, compared to putting the same functionality into a 
compiled addon, then linking it to the "main" POV_Object as a direct 
extension of it, and all inheriting objects.

Again, its, "At what level do you add a feature, to make it fast 
enough?"

-- 
void main () {
  If Schrödingers_cat is alive  
    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:
> 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.

-- 
                                                          - Warp

Post a reply to this message

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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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