In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> Patrick Elliott wrote:
> > In article <4709fb43@news.povray.org>, war### [at] tagpovrayorg says...
> >> Patrick Elliott <sel### [at] rraznet> wrote:
> >>> If you have something like:
> >>> #declare yy = clock
> >>> sphere {...
> >>>   translate <yy,35,61>
> >>>   texture { some_complex_texture translate 100*x}
> >>>   translate y*2}
> >>> Then you **must** reparse the object every single time, because once 
the 
> >>> object exists internally, it can't be changed.
> >>   Wrong.
> >>
> >>   The object has its own transformation matrix and the texture its own
.
> >> All transformations applied to the object go to its transformation mat
rix,
> >> and all transformations applied to the texture (be it directly in the
> >> texture block or indirectly in the object block) go to the transformat
ion
> >> matrix of the texture.
> >>   It would be perfectly possible to alter these two transformation mat
rices
> >> afterwards. It's simply a question of which transformations are applie
d to
> >> the object only, which ones to the texture only and which ones to both
.
> >>
> >>> The 
> >>> transforms you need to be able to change are "not" sitting convenient
ly 
> >>> as the last thing in the object, they are buried deep within the 
> >>> structure.
> >>   You seem to have this concept that the transformations are somehow
> >> stored in the definition of the object, and that this order must be
> >> preserved.
> >>
> >>   The individual transformations are not stored anywhere. Each transfo
rmation
> >> is simply a command (a kind of "function call" if you like) which modi
fies
> >> the internal transformation matrix of the object.
> >>
> >>   It would be perfectly possible, after the object has been created (w
ith
> >> the transformations and all), to reset its transformation matrix and t
hen
> >> apply the same transformations to it, resulting in the exact same end
> >> result. The only distinction you have to make is which transformations
> >> go to the object, which ones to the texture and which ones to both.
> >>
> >>> If we want to be able to animate, without a reparse, we need 
> >>> an internal representation that allows "each" transform, texture, 
> >>> object, etc. to exist as accessible elements, not as static 
> >>> declarations.
> >>   No we don't.
> >>
> >>> In other words, you need to make it "look" like:
> >>> yy = yy + 1
> >>> mysphere.translate(0)=yy,35,61
> >>> Even as the engine keeps track of "how" those things connect:
> >>> start->translate(0)->texture(0)->translate(1)->end
> >>   The engine doesn't need to keep track of that. You should acquaint
> >> yourself with transformation matrices and how they work.
> >>
> >>> How else do you both allow animation, without a reparse, but also 
> >>> maintain the capacity to place as many transforms, or other elements,
 
> >>> into the object as you can now?
> >>   You can write a thousands individual transformations into an object,
> >> yet none of them will be (individually) stored anywhere. They are all
> >> applied to one single 4x4 transformation matrix. POV-Ray doesn't need
> >> to keep track of the individual transformations nor store them anywher
e.
> >>
> >>   The only thing you need to specify is whether a certain transformati
on
> >> is applied to the object, to the texture, or both.
> >>
> >>> See what I am getting at? If you want to maintain the "existing" SDL,
 
> >>> you have to allow for this, or suffer the current consequence of havi
ng 
> >>> to reparse the "entire" SDL every frame.
> >>   That's just not true. The only thing you have to allow in the new SD
L
> >> is to be able to apply transformations to the object only, the texture
> >> only or both at the same time. This is very trivial to do.
> >>   It's perfectly possible to transform the object but not the texture
> >> even after the texture has been specified.
> >>
> >>
> > Sigh.. You are I think making an assumption that, when you do want to
 
> > change something, you would only want to change "one" transform. But,
 
> > maybe you have a dozen, each with does something specific to positionin
g 
> > the object, each of which is "also" effected by all of the prior 
> > transforms. Tell me, with a real example, not just some assertion that 
I 
> > am imagining a problem, how you do that. Yes, you can use some commands
 
> > that can revert the object to a known state, like at the origin, then
 
> > transform it, but that is useless if the transform you need is relative
 
> > to some arbitrary point, which is the result of 3-4 other prior 
> > transforms. How do you, if you are doing say 7 translates, for some odd
 
> > reason, revert back to the 3rd, change the 4th, then reapply the last 3
? 
> > You can't, without drastically altering how you handled those transform
s 
> > in the first place, and reducing them to a bare minimum number needed t
o 
> > do the task. Sure, it might be possible, but it still breaks, as near a
s 
> > I can tell, when you try to provide a post-creation transform on the 
> > object, to modify the prior result. Show me that I am wrong, don't just
 
> > tell me I am.
> > 
> I don't want interfere in your personal fight, but I think this is what
 
> is going to happen:
> - POV4 transformations will be implemented the same as in current POV, 
> one transformation matrix per object, texture.
> - The language will be enhanced and the processing of it changed in such
 
> a way that retransforming one or more specific elements will become an 
> issue. e.g. in generating the next frame of a complicated object without
 
> reparsing the lot.
> - it'll be up to the user to implement a stack of transformations if he
 
> thinks he needs one. Reverting to a marked state and replaying the 
> changed set of transformations from that point.
> - luckily the language will be enhanced in such a way that such an 
> implementation is easy.
> 
> Also before fighting on, you should first define what you mean by 
> creation/post creation etc. I think you have a different view on when an
 
> object is actually created. Is that e.g at the end of the union defining
 
> it (Patrick?) or at the end of parsing (warp?).
> If you assume the latter (which happens to be my point of view) post 
> creation transforms do not exist, by definition. BTW I think the time of
 
> definition of the shape also needs a name (birth? though you will be 
> able to clone after birth... conception?), because it is a significant 
> moment in the life of that object. I predict that it'll come up in 
> discussions about POV4 frequently.
> 
Well, in any language that would allow parsing, then animation 
"internally", without a reparse, its *both*. I.e., you instance a 
complete object on the first "pass" if you will, much as you would 
compile a language. Once this is done, code execution, and any changes 
to the object "allowed" in that context, can still happen, but the 
"objects" are now static in all other respects. In other words, you 
never really stop parsing, in the sense of executing branching, loops or 
other commands that have an affect on the objects, but you also 
*don't/can't* do the equivalent of arbitrarily changing the parameters 
of an object that has already been created, any more than you can do the 
following in any compiled/JIT type language:

sub blah(a, b, c)
  'do stuff
end sub

sub blah(a)
  'do something completely different.
end sub

call blah(1, 2, 3)

At best, you are going to get an error just trying to redefine the same 
function, at worst, if the language allowed it, you would redefine it to 
the later version, and you would get an error due to the parameters 
being wrong. You are thus **not** generally allowed to do that. Same 
with an object. So, what I am looking at is something like a JIT compile 
of the script. Objects get defined *once*, then from then on you make 
changes to *that* object. No reparsing happens, because the *script* 
executes like any other JIT. You can change variables, etc., within 
limits, or even attributes of the object **if** some method exists for 
getting at them, but you can't reparse the object all over again to 
remake it for the next frame, you have to take what *exists* and change 
what parameters are "allowed" at that point. The problem is, if getting 
it to that point requires 5-6 interlocked transforms *before* the one 
you plan to make changes to in the next frame, you need some way to make 
sure it is in that state "before" making that transform, then you also 
have to make sure any additional transforms that happen "after" that 
point also take place, and in the right order. The alternative is to do 
them all after the fact, which shoots huge holes in any attempt to make 
it object oriented, or you have to deny the ability to make multiple 
transforms on objects or their sub-objects, as you are currently able 
to.

The only other solution I could see would be the "mark" the transforms 
you "want" to be able to change later, then only allow access to those. 
So, in that case, every transform up to that point becomes the objects 
"default" state, to which your change is applied. That still doesn't 
solve the problem, because then it also has to remember and reapply any 
additional state changes that need to happen "after" that as well. All 
you end up doing is decreasing the number of state changes you have to 
track, without actually changing the problem.

Finally, if you do keep an array of all the transforms applied to a 
specific object, to be replayed, then why not keep them in a list *on* 
the object, where it makes sense, instead of in a separate array/table, 
which has no obvious connection to the original object at all? And 
then.. I am not sure what POVRay does in such cases, but what happens if 
you do something like:

union {
  object1
  object2
  scale .5
  object3
}

Does it transform all three, or the first two, *then* union the third? 
If the later, then you have a huge problem because no list of transforms 
"can" produce the same result, unless you also replay the exact process 
of instancing the objects in the union as well. I would hope that it 
deals with it as one complete object, instead of changing the size of 
the first two, then adding the third. That would make is possible to 
simply apply a list of transforms. If it doesn't work that way though, 
then the objects themselves become strongly dependent on the order of 
operations as well.

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