In article <4709033b@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >> Another is "changing a 
> >> previously-defined translate" (that's not currently possible in SDL, a
nd 
> >> it's a bad idea anyway).
> > 
> >   Somehow I feel you are a bit talking about apples and oranges here.
> > 
> >   Of course there's no way of "changing a previously defined translate"
> > because there's no such thing as a "previously defined translate". As I
> > said in the other post, a translation is not a property of the object,
> > it's an operation applied to the object (in other words, in object-orie
nted
> > terms, a translation is not a member variable of the object, it's a mem
ber
> > function). You either apply it (so that it has some effect) or you don'
t.
> > You can't go "back in time" and apply it in a different way once you ha
ve
> > applied it already.
> > 
> >   (Technically speaking you can later apply a new set of transformation
s
> > which cancel out the earlier translation, so the effect is the same as 
if
> > the earlier translation had not been performed at all, but this is a
> > rather different thing at a basic conceptual level.)
> > 
> >   I can't really see what is the problem people are seeing here. I don'
t
> > see any problem in objects in the new SDL having transformation functio
ns
> > which work in the same way as in the current SDL.
> > 
> 
> I was just commenting on Patrick's examples which showed changing 
> individual transformations, stored in some sort of array. So we are 
> agreeing. The way transformations should work is the way they currently d
o.
> 
And I don't think you have *at all* addressed what I was getting at. How 
do you do something like IK, without either a) allowing an object like 
reference system *which keeps track of* which order the transforms took 
place in, such that if you move something, then rotate it, you don't 
want to later just rotate it, and assume its going to produce the same 
result, or b) limiting the types of transforms that *are* possible to an 
already parsed object, or c) reparsing every damn thing in the script, 
so you can recalculate just what the heck the object is described doing 
*in that frame*? I would be 100% fine with an explanation for how to 
keep things as they are, or provide those transforms in a way that still 
allows handling the objects in a way that lets you make adjustments 
between frames, without having the reparse the entire file (which can 
sometimes take up 100 times as much time as producing the final image). 
I just don't see how you do that. The existing system parses the objects 
into a *static* internal layout, which you can't change anything on. Any 
changes have to be done "during" the parsing. Once the object exists, 
the only thing you can do is dump it from memory, and start over, by 
reparsing the entire thing again, with new data. That you can calculate 
what that data is in the SDL, doesn't change the basic nature of what 
you end up with. And that is **not** something useful, or practical, for 
anything but single frames.

So, what is the answer? Just figure that speed for the parser is 
impossible to solve, so who gives a frack, lets just leave it slow and 
reparse 100% of the file every frame? Or do we get our heads out of the 
sand and either realize that there is no solution that works in the 
"existing" framework, which can allow this, or that, if we do find a 
way, we need to provide a sane and flexible way to solve it, not some 
method that basically does nothing but impose the "same" problems on the 
new system as we have already? It just doesn't make sense to me to have 
transforms work the same as now, when the reason they are a problem 
*now* isn't going to change if you plan to speed up parsing, or improve 
the ability to animate through the SDL.

I am even more bloody confused by the fact that I stated a clear 
alternative. Allow the internal representation work **exactly** as it 
does now, at least in terms of how such objects are handled in each 
frame, but parsing it from a *binary* representation, not the original 
text. Create the original using text, sure, but keep it internally as 
binary, so you can change it between frames, without the cost of having 
to reparse the entire damn file. Then **allow** someone that wants to 
access, through a more object oriented system, to change anything they 
like in that "binary" copy. Don't reparse 10,000 lines of code if the 
**only** thing you need to do is change one bloody transform in an 
already parsed object.

And more to the point, please, give me some good idea how the hell you 
allow that, in any way that doesn't require a 10,000 line reparse, 
without resorting to something at least "similar" to what I suggested?

Sorry for being a bit snippy, but bloody hell, why are we even 
discussing how the SDL works and what problems it currently has, (which 
can make it so damn slow in some cases), if all we are going to do is 
go, "Ah, well... I don't like how that might change the syntax, so lets 
just pretend keeping things as is isn't going to be (or perpetuate) any 
kind of problems/limitations."

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message