|
 |
In article <47109fba@news.povray.org>, war### [at] tag povray org says...
> Patrick Elliott <sel### [at] rraz net> 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
today, so I am not going to bother with most of it. I will once again
mention this one... There are only **two** ways I can see of doing that,
either a) you have to do the **opposite** set of transforms to get it
back to the state you want to start from, which **may not** be the
original blank state that the object had when first instanced, or b) you
have to reset it back to the very first state it had **prior** to any
transforms, then reapply **all** of them. The first you can't do unless
you keep track of what they where, which doesn't make much more sense
than what you are already complaining about, and 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. 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.
Hopefully, the hybrid concept I posted about earlier "fixes" the issue
you are rambling about vis a vie the memory usage on objects that don't
need the array. 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, which is semantically the same damn thing I
suggested, or if you keep all of the transforms on the object, so that
you only have to, at the last minute, change the *specific* transform(s)
needed for that frame, which would both save more space than your
version, and is "associatively" more reasonable.
I know damn well what "reseting" the matrix means. It doesn't change a
damn thing with respect to either of our positions, all it does is bring
up a useless straw man. Unless of course you know some magic formula for
"resetting" it to a prior state, without resetting to all the way back
to the "initial" state, without any way to tell how the hell it got to
that state, or what is needed to reset it. Objects are, once instanced,
basically black boxes. They have a static state, with no memory of how
*they* got there. The only way to correct that is to delay the creation
of that state until you are ready to render. Then the problems are a)
are some states "static" in the sense we don't need an array at all, b)
for the ones that are not static, can we 1) revert to some state that
"isn't" completely blank before applying a change (I say no, since the
parser doesn't have any better idea than we do how it got to that point,
given that all you have at that point is the "final" matrix), 2) delay
creation of the matrix until needed, so we don't have to revert it, but
apply "all" transforms via an external source, or 3) delay creation of
the matrix until needed, so we don't have to revert it, keeping a *copy*
of the transforms from the last frame on the object, so you only need to
adjust the *specific* ones needed for this frame from an external
source, instead of *all of them*.
Or do you want to beat the straw man some more?
--
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
|
 |