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 () {

    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