Patrick Elliott wrote:
> Why? Its going to cost you more memory to store 20 transforms for an IK 
> chain, and all changes needed for them, in separate arrays, than it will 
> to store 20 transforms in the object, then apply only 3-4 changes from 
> "your" array, which are needed to change the specific parts that are 
> needed.

Then store it as two arrays.

The only difference is whether one of the arrays is "in the object" 
being transformed or not.

What's the semantic difference between having an array pointer 
associated with each object to store transforms and having an array 
indexed by object whose values are arrays of transforms?

> One uses, lets say 20*5, just to pick an arbitrary number for 
> the storage needed, + 4*5*number of changes. Yours requires 20*5*number 
> of total changes you need.

You're trying to evaluate the efficiency of code that was thrown off as 
an exemplar of what I was expressing. That's rarely a productive analysis.

> Its only *equal* if every object has to have "every" 
> transform changed between frames, and thus all of them replayed into the 
> object.

And if not, then you code multiple arrays in SDL: One for the transforms 
that change, one for the transforms that don't.

Think about this before answering: What's the benefit of having one 
array of transforms assigned to every object, vs having arrays indexed 
by objects that can have arrays of transforms assigned as values?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

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.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Patrick Elliott wrote:
> and so that someone using a *new* SDL could be warned 
> that they forgot to actually render anything. 

Having used systems where the name under which they're invoked makes a 
difference between whether the interpret enters a GUI event loop or runs 
as a straight-through execution and exits, I can say that it's probably 
a mistake to do that. The maintainers of the interpreter feel the same 
way, and moved the event loop into a loadable package with the 
requirement you start it when you're ready.

Having said that, perhaps a command-line option that says "No, really, 
render whatever you have when you get to the end of the input" would be 
a good idea, for people who are building a library or something and want 
to see how it looks during development.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

In article <47109c94@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Why? Its going to cost you more memory to store 20 transforms for an IK
 
> > chain, and all changes needed for them, in separate arrays, than it wil
l 
> > to store 20 transforms in the object
> 
>   You don't get it, do you? Forcing a transformation array to exist in ev
ery
> single object increases memory consumption compared to objects not having
> such an array, and a separate SDL array being used only in objects which
> need it.
> 
See, I don't disagree with you about that at all. But it brings up a 
problem how how you "tell" the parser that the object you are defining 
is "supposed" to be changed later. It also doesn't address other issues.

>   If you have 10000 objects in your scene, 10 of which are IK'ed, forcing
> a transformation array to exist for every single one of the 10000 objects
> (even if those arrays are empty or contain just one transformation) is
> going to consume much more memory than if the array existed only for thos
e
> 10 IK'ed objects.
> 
>   Do you think having an empty array in an object takes no memory?
> 
>   Anyways, no array is needed, not even for IK'ed objects. How do you thi
nk
> the current POV-Ray manages without such arrays? And no, the answer is no
t
> "by reparsing every object each time".
> 
> > then apply only 3-4 changes from 
> > "your" array, which are needed to change the specific parts that are 
> > needed. One uses, lets say 20*5, just to pick an arbitrary number for
 
> > the storage needed, + 4*5*number of changes. Yours requires 20*5*number
 
> > of total changes you need. If the number of changes are say 10, then 
> > mine takes 20*5 + 4 * 5 * 10 = 300, yours takes 20*5*10 = 1,000.
> 
>   Those numbers don't make any sense.
> 
Why not? Its hardly helpful to just insist they don't make sense without 
saying why. Because they are not realistic? True, but its supposed to be 
an example of what happens if you had to store "all" transforms for an 
object externally, compared to only storing those you need to change in 
an external array, and patching them into the object. My point was that 
if you do the later, you use **more** room than if you had all of them 
stored on the object, when only stored, externally, those that you 
needed to make changes to.

This is irrelevant (if) you have some way to specify which transforms on 
an object "need to" support later changes. Though, I am not sure how the 
hell that fixes it, since you can't just substitute the rotation in an 
object, or a translations, and get the same result, if the rest of the 
transform is static. It means you break interdependence of those 
transforms. I am still waiting for an example of how you avoid that 
problem, instead of just a lot of hand waving about how it isn't one.

Example, you *need* to rotate an object to some position, then move it, 
then rotate it again. That one you "could" in theory keep track of the 
transform "prior" to the final rotation, since that is probably the one 
you will be changing, but you have to "at least" keep track of that 
matrix, because the result of the final rotation is ***not*** based on 
the origin, the original location of the object, or any other simple 
condition, its *dependent* on the two prior transforms. This only gets 
worse if you, say, want the robot to fall apart, since that means you 
are likely to be making changes to a) the original translation, b) the 
original rotation, c) the final rotation, and d) anything else you did 
to it. In other words, you are right back the where you where before, 
storing all of the transforms, so that you can change "only" the one 
needed for the frames before the falling apart, then later change "all" 
of them, when it is falling apart.

> > At least not unless you throw out the entire old SDL and force everyone
 
> > to use "your" solution to apply all the transforms all at once, every
 
> > frame, which means abandoning the original SDL, since it can't currentl
y 
> > work that way.
> 
>   What the heck are you talking about? Object-specific transformation arr
ays
> are needed to preserve the current SDL?
> 
>   The more you write, the weirder it gets.
> 
Sigh.. Your just getting it at all. The ***existing*** SDL assumes that 
each "frame" is "static", as so is the object. Its not possible in the 
current design to change the matrix for and object in "any" sense other 
than in the final object. In something like an IK chain, only the 
"main" object, which all others are a subset of, can be changed at the 
last minute, because its the only one that is "accessible", the rest are 
predetermined, having already been declared by that point, and you can't 
even do something like making a copy of the object and substituting a 
completely *different* matrix on part of it, unless you explicitly coded 
those transforms so that they are calculated, using variables, etc. And 
even then, if you made A = 10, then later A = 20, its **still** static,
 
with the value of 10, because the SDL isn't going to **go back** and 
replace 10 with 20 just before you render. Its going to use what ever 
value A had *when* it parses the object. Its *completely* static.

In an SDL that supports its own animation/render functions, you can't 
have "static" objects. They need to be changeable at any point, so that 
if you change the value of A, the new SDL can figure out that you 
**now** want the object to rotate or translate by 20, not 10. You can do 
this two ways. 1. Track the transforms for the object, then simply 
replace the one you need to change. 2. Generate a static object 
"anyway", then apply your own transform to its parts, to produce the 
result you want. Either way you are going to be using memory to do it.


But yeah, I see your point in having it static, then applying transforms 
"after" the fact. How about a sane compromise then.. Make the SDL so 
that its like:

#define fred = union{
  arm{rotate <1,2,3>
      translate <3,4,5>
      rotate <x,0,0>
      storetrans
  }
}

If you don't include the "storetrans" keyword the object is treated "as 
currently", and the result is a static object, which you "can't" 
transform anything on between frames. If you do use it, then those 
transforms are stored in an array and **only** applied just prior to the 
render step, so that you can substitute what ever changes you want, and 
**any** point in the matrix. That solves both problems. Objects that 
don't need to be animated, which hopefully is *most* of them, don't 
store anything but their static matrix, defined *when* the object is 
created. Objects that require animation will "delay" their matrix 
creation until expressly needed, so you can make any change you want to 
them. And you **still** only need to store, in your non-object linked 
array, the transform(s) you want changed, not all of them. Its a good 
compromise I think. Then again, this requires that I can first convince 
you that what I am talking about makes some sort of sense to start with. 
Again, your idea is fine, but this compromise would "still" reduce 
memory use, since for objects that require transforms to be applied 
"post initial creation" only the non-static matrices need be 
recalculated and your array only need to hold those changes "specific" 
to what you are trying to adjust, not every transform applied to the 
subobject.

Look, if you still think I am full of it, then why not agree on some 
example concept, with a specific number of parts, etc. Then each of us 
can give a psuedocode example of what the hell we are talking about, 
because I am not entirely sure I am not missing something you are trying 
to get across too.

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

In article <4710eb4d$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > Why? Its going to cost you more memory to store 20 transforms for an IK
 
> > chain, and all changes needed for them, in separate arrays, than it wil
l 
> > to store 20 transforms in the object, then apply only 3-4 changes from
 
> > "your" array, which are needed to change the specific parts that are 
> > needed.
> 
> Then store it as two arrays.
> 
> The only difference is whether one of the arrays is "in the object" 
> being transformed or not.
> 
> What's the semantic difference between having an array pointer 
> associated with each object to store transforms and having an array 
> indexed by object whose values are arrays of transforms?
> 

No semantic difference, just associative. And when you are dealing with 
objects that is often more important than semantics. Its why you don't 
usually find most OOP languages placing the arrays of icons/objects or 
enumerations that *belong* to them in separate arrays and "force" the 
coder to add code like:

ondraw() {
  for each icon in some_external_array
    draw(icon);
}

instead of:

ondraw() {
  for each icon in self.icon_array
    draw(icon);
}

Semantically they are **identical**, associatively they are 
**completely** different.

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

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

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

In article <471### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> Patrick Elliott wrote:
> > In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
> > says...
> >> Patrick Elliott wrote:
> >>> In article <470### [at] hotmailcom>, a_l### [at] hotmailcom
 
> >>> says...
> >>>> What I was saying is that we should distinguish between the 'first
 
> >>>> creation' and the 'final creation'. Calling both simply 'creation' w
ill 
> >>>>   lead to confusion (as shown is this thread. Much of what you and
 
> >>>> Patrck are writing does not make sense to me, because for me 'creati
on' 
> >>>> is 'final creation').
> >>>>
> >>> How about "intermediary" creations then, just to confuse things more.
 
> >>> lol Technically, by your definition, the object is never "created" un
til 
> >>> the frame in rendered, at least in any system like we are talking abo
ut, 
> >>> where each "frame" is defined not by re-running the entire script, bu
t 
> >>> only via the command "in" the script.
> >>>
> >>> In other words, in the current model we do this:
> >>>
> >>> render("myfile")
> >>>
> >>> in a true animation system, we do this:
> >>>
> >>> 'Set up a bunch of objects.
> >>> ...
> >>> render
> >>> 'Change the objects some.
> >>> ...
> >>> render
> >>> 'Change them some more.
> >>> ...
> >>> render
> >>>
> >>> The "render" step is explicit in the script, since it only happens 
> >>> "when" all the changes are made, not an external process that just ru
ns 
> >>> an SDL through it, and recalcs the data for everything as it does it,
 
> >>> based on the existing clock scheme, which is kind of limited. Mind yo
u, 
> >>> making that change, depending on how it was done, could break existin
g 
> >>> SDL. Mind you, a command that "requests" the prior behavior could be
 
> >>> used to solve that. 
> >> You could also assume that a render command is implicit at the end of
 
> >> parsing if none is given.
> >>
> > Yes, I had considered that, but its better to have a compatibility flag
, 
> > both so that someone doesn't try to run an old SDL, then wonder why it
 
> > didn't work right, and so that someone using a *new* SDL could be warne
d 
> > that they forgot to actually render anything. Its kind of a toss up 
> > though.
> > 
> There could be a problem with a compatibility flag if someone is 
> including some old code. Then again the #version 3.6; compatibility flag
 
> never gave problems. Actually, as you might have noticed, I would prefer
 
> a 'camera(Scene)' kind of syntax in stead of a 'render' command for many
 
> reasons (some not even mentioned anywhere yet). Which points more to a 
> compatibility flag than an implicit 'render' command.
> 
Only problem I could see with that is that someone may want to use 
multiple cameras, like say... stereoscopic effects. I mean, its not 
totally absurd to consider someone wanting to either a) render bath eyes 
at the same time, if they have the speed and the language allowed it, or 
even doing something crazier, like having a camera that "looks" at some 
other location, which is used as part of the image some place else. A 
good example would be something like a security booth. You have a 
monitor on the desk, which shows a kind of post process "filtered" 
effect in black and white, of what is "seen" by a camera that is also 
*visible* in the larger scene, but in color, as is most of the rest of 
what is in the camera view.

Yeah, I know, you can do two renders, one from the camera view, then 
post process that, then use the result as an image map on the monitor, 
but is is just an example. Its possible that someone could have a scene 
where this was either seriously impractical, or completely impossible, 
unless the "camera view" was being produced in the same render as the 
final image. Then again, what do I know. lol

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

Patrick Elliott wrote:
> Only problem I could see with that is that someone may want to use 
> multiple cameras, like say... stereoscopic effects. I mean, its not 
> totally absurd to consider someone wanting to either a) render bath eyes 
> at the same time, if they have the speed and the language allowed it, or 
> even doing something crazier, like having a camera that "looks" at some 
> other location, which is used as part of the image some place else. A 
> good example would be something like a security booth. You have a 
> monitor on the desk, which shows a kind of post process "filtered" 
> effect in black and white, of what is "seen" by a camera that is also 
> *visible* in the larger scene, but in color, as is most of the rest of 
> what is in the camera view.
> 
> Yeah, I know, you can do two renders, one from the camera view, then 
> post process that, then use the result as an image map on the monitor, 
> but is is just an example. Its possible that someone could have a scene 
> where this was either seriously impractical, or completely impossible, 
> unless the "camera view" was being produced in the same render as the 
> final image. Then again, what do I know. lol

So which is better:

A) Letting the users simply render two sets of images, with one being 
used as a texture in another; this is very easy, requiring only two 
scenes that are almost identical (the camera is positioned differently 
in the camera view), or

B) Writing the renderer so that a texture can be based on the camera 
view (with rays being traced, anti-aliased, usw...) of another place in 
the scene.

We already have A up and running just fine.  I use it all the time. 
Leaving out the trouble of render-wrangling a second set of images 
(i.e., putting them in a different directory after rendering), A is no 
more work than B for the user; the camera still has to be positioned and 
test-rendered for either method.

B will require work from programmers who are already busy with stuff 
that can't be pushed off onto the user, or if they can be, only at the 
expense of significantly reducing the user's productivity.  It also 
increases the size of the renderer, in order to provide the extra feature.

Now if the memory situation is very tight, then method B does have the 
advantage that the texture does not need to be stored in memory; but in 
almost every case of this kind the video image occupies less than a 
quarter of the final view, which means that the texture requires only 
one-quarter of the memory of the rendered image.  If your memory 
situation is that tight, maybe you need to get some more RAM.

Regards,
John

Post a reply to this message

Alain wrote:

> Using an array of transforms would be wastefull. It would uselessly use 
> extra memory. It would make rendering slow as the whole array will need 
> to be computed for every ray that encounter the object, as well as any 
> CSG operation that use that object. That array will need to be dynamic 
> as you can never tell beforehand how many transforms will be applyed to 
> any particular object, adding some useless overhead, and requiring still 
> more memory.

One reason you would need more then one forward or reverse transform 
during rendering is if the renderer were to support motion blur.  One 
transform stipulates the start-of-frame positioning of the object, and 
the other stipulates the end-of-fram positioning (you could even have a 
spline of transforms if you didn't want to linearly interpolate between 
the start and end, but that may be too hairy to be worth the trouble).

Regards,
John

Post a reply to this message