POV-Ray : Newsgroups : povray.general : Status of Moray? : Re: New SDL for POVRay Server Time
4 Jul 2025 23:00:07 EDT (-0400)
  Re: New SDL for POVRay  
From: Patrick Elliott
Date: 13 Oct 2007 18:52:29
Message: <MPG.217af66b43f79a598a04d@news.povray.org>
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 
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.