Patrick Elliott <sel### [at] rraznet> wrote:
> 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.

  How are you going to tell it that regardless of the transformation array?

  The only "problem" your transformation array "solves" is that it makes
it possible to change individual transformations stored in that array.
However, that doesn't solve the issue of *how* you are going to change
those transformations in later frames. What kind of code will you write
in order to do that?

  And that's exactly why the transformation array is not needed: The exact
same code that can be used to change the array can also be used to apply
all the transformations (optionally modified from previous frames) to the
object.

  Besides, your array solution presents other problems which are not
problems in a "apply transformations with SDL code". For example, what
if you want to insert a new transformation somewhere in the series of
transformations? Or what if you want to remove some transformation?
What if you want an alternative series of transformations at different
frames?
  You would need to offer all kinds of functions to modify the array,
and the user needs to write some SDL code to call those modifications.

  However, with the same effort the user could simply call the functions
which apply transformations to the object directly. Adding or removing
transformations is simply a question of putting them in conditional
statements. Applying alternative series of transformations is simply a
question of if-else or switch blocks.

  There's no need for a transformation array.

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

  That's not a technical limitation. That's just a syntax limitation.

  It would be perfectly possible in the current POV-Ray to change the
transformation matrix of an existing object if someone simply added the
proper syntax for it. (And that's exactly one of the reasons why the
whole new SDL is being discussed. To add easy support for such things.)

> In an SDL that supports its own animation/render functions, you can't 
> have "static" objects.

  POV-Ray doesn't assume that objects are "static". It's just that there's
no syntax to change the transformation matrix of an existing object. Plain
and simple.

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

  Why do you have this obsession that individual transformations *must*
be stored somewhere?

  You *apply* transformations in the SDL code. You don't *store* them
(not as individual transformations anyways). That's because the individual
transformations are already "stored" in the SDL code itself. Why do you
need to store them in two places?

  At each frame you simply execute that SDL which applies the transformations
to the objects.
  You are going to have to execute some SDL at each frame anyways (to
change transformations). It's not any more difficult to simply execute
the SDL code which applies all the transformations.

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

  Let me see your suggestion about the new SDL code which modifies the
"transformation array" at each frame.
  My answer is that it's the exact same thing, but without the transformation
array. Simply apply all the transformations to the object at each frame.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> b) you 
> have to reset it back to the very first state it had **prior** to any 
> transforms, then reapply **all** of them.
> 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.

  Then the vast majority of renderers and rendering languages (eg. OpenGL)
are "absolutely stupid" because that's exactly what they do. That's exactly
what POV-Ray does currently as well.

  At each frame they reset the transformation matrix to the unit matrix
and then apply all the (possibly modified) transformations to it. That's
standard procedure, and it's by far the simplest and easiest way of
doing it. You don't necessarily need any data container to store all
the individual transformations because the individual transformations
are in the code you write (this is often the case eg. with OpenGL).

  (Sure, you can do it in other ways too in OpenGL, but resetting the
transformation matrix and applying all the transformations to it at
each frame is a common standard way of doing things. It's simple, easy
and fast, and it doesn't require any more memory than the code itself.)

  I simply can't understand why you think this is such a "stupid" idea.
It's a very simple and working idea. It keeps things simple, it doesn't
require any memory and it's easy to implement.

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

  No, it doesn't. Writing an OpenGL application doesn't require you to
"track" all the transformations you have applied to every single object.
When you want to render a new frame in OpenGL, you simply reset the
transformation matrix and apply the same transformations to it (with
possibly modified values). That's it.
  The new SDL doesn't need to be any different from this.

  You don't seem to grasp the idea that all the transformations are
already "stored" in the very code that applies those transformations.
You don't need to store them anywhere else. Simply re-apply the same
transformations at each frame, and there you are.

> 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

  The current POV-Ray manages to do it. Most OpenGL applications manage
to do it. Most other renderers manage to do it.

  Just because you can't understand how they manage to do it doesn't mean
it's not possible and easy.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott wrote:
> No semantic difference, just associative.

In other words, you don't like the syntax.

> And when you are dealing with 
> objects that is often more important than semantics. 

I'm not sure what's more important about a programming language than 
knowing what the constructs mean.

But given that, now we're just arguing over syntax. That makes things a 
lot more clear.

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

On the other hand, if you could do the latter and not the former, you'd 
have a much more limited language.

-- 
   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:
> the issue isn't semantic, its associative. 

I'm not sure what your level of experience with programming is, but such 
things stop being problematic after a while.

 > 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 if it's indexed by the object.

> ginger.copytransforms(fred)
> vs.
> ginger.applytrandforms(arbitrary_table)

Of course when you name one of them "fred" and the other 
"arbitrary_table", it's confusing. Don't do that.


I'm suggesting
   walking_transforms[ginger] = walking_transforms[fred].

Or even
   walking_transforms[ginger] = feminize(walking_transforms[fred])
or
   running_transforms[ginger] = walking_transforms[fred]

Then, eventually, you say
   ginger.apply(running_transforms[ginger])
   fred.apply(walking_transforms[fred])

If you have a set of global transforms (that always apply), you can
   extern function
     feminize(array of transforms) returns array of transforms;
   global_transforms[fred] = (....)
   global_transforms[ginger] = (....)
   frame_transforms[fred] = (clock*....)
   frame_transforms[ginger] = feminize(frame_transforms[fred])
   frame_transforms[freds_arm] = (rotate clock*y)
   ginger = object(...)
   fred = object(...)
   freds_arm = object(....)
   foreach object {ginger fred ...) {
     object.apply_transform(global_transforms[object])
     object.apply_transform(frame_transforms[object])
     object.render
   }
   freds_arm.apply_transform(global_transforms[fred])
   freds_arm.apply_transform(frame_transforms[fred])
   freds_arm.apply_transform(frame_transforms[freds_arm])


Maybe you should supply a similar bit of pseudo code showing a similar 
scene and show why your mechanism is more clear.

> The first one though is "associatively" clearer, even if its 
> semantically the same.

Except it only associates to the object. It doesn't "associate" what the 
*transform* is, only what object it applies to. Perhaps it's only clear 
to you.

Plus, if in your code, you have
   ginger.apply(walking_transforms[robot])
   fred.apply(walking_transforms[robot])
I think that's more clear than saying
   ginger.transforms = fred.transforms
because now you know they're both using the same
transforms and you know those transforms are
treating them both as robots.

 > And, even if you wanted to do that, there hasn't
> exactly been a discussion on how you a) structure such a table, 

It's structured the same way you'd structure yours, except it's a 
user-created object instead of a unique property defined by the 
renderer. This also has the advantage that you can (for example) pass it 
to user-defined functions without having to create an object just to 
carry it around.

> or b) get one out of, or into, an POVRay object that has subobjects. 

The same way you would.

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

I think if you want to argue that your syntax is superior to my syntax, 
while my syntax is more orthogonal and more flexible yet has similar 
semantics,

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

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

There have been a POV-Ray patch which allowed to do that, you could have
a "portal" object (which, when, who, and what is out of my memory).

So I guess it's not so hard to do.

Fabien.

Post a reply to this message

Patrick Elliott wrote:
> 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 
[snip]
> 
> Or do you want to beat the straw man some more?
> 
I am not familiar with that expression, but anyway here are my 2 cents.

What you deem necessary for animation is in my (and Warp's if I may 
speak for him) overkill. It may be handy for some situations but I think 
in the majority of cases I wouldn't use it. POV4, however, should make 
it possible and easy to use. So what this discussion should have been 
about is to what extend it has to be hardcoded in either the internal 
datastructures or in the syntax of the language. My (and presumably 
Warp's) opinion on this is that what you propose will be extremely easy 
to implement yourself within the new language for those cases where you 
need it. So it has no implication for the current POV4 discussion 
whatsoever. You are free to continue this discussion with warp of 
course, but it will be like talking to a wall, without being able to 
study the delicate texture of the stones.
The opinion that it is not needed is based on knowledge on how the 
current implementation works and some safe assumptions on what POV4 will 
allow at the minimum. However, you should watch the development closely 
that indeed these minimum requirements will be met. Or even better: 
create a list with those minimum requirements on the new wiki.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> My (and presumably 
> Warp's) opinion on this is that what you propose will be extremely easy 
> to implement yourself within the new language for those cases where you 
> need it.

  There could even be a library for that exact purpose, which could
perhaps more or less transparently add support for the feature he wants
(on a per-object basis).

  However, hard-coding it in the core code is a bad idea. The solution
must be more generic than that.

-- 
                                                          - Warp

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> 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.

  Optimally this would not be a core feature but more or less easily
implementable as a shader, assuming the new shader language has enough
expressive power. A pre-made such shader could be provided in a standard
library for convenience.

  (The big advantage of it being a shader is that it makes it easy for
the user to change it if he needs a slightly different effect.)

-- 
                                                          - Warp

Post a reply to this message

In article <4711cecb@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > 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
.
> 
>   How are you going to tell it that regardless of the transformation arra
y?
> 
>   The only "problem" your transformation array "solves" is that it makes
> it possible to change individual transformations stored in that array.
> However, that doesn't solve the issue of *how* you are going to change
> those transformations in later frames. What kind of code will you write
> in order to do that?
> 
>   And that's exactly why the transformation array is not needed: The exac
t
> same code that can be used to change the array can also be used to apply
> all the transformations (optionally modified from previous frames) to the
> object.
> 
>   Besides, your array solution presents other problems which are not
> problems in a "apply transformations with SDL code". For example, what
> if you want to insert a new transformation somewhere in the series of
> transformations? Or what if you want to remove some transformation?
> What if you want an alternative series of transformations at different
> frames?
>   You would need to offer all kinds of functions to modify the array,
> and the user needs to write some SDL code to call those modifications.
> 
>   However, with the same effort the user could simply call the functions
> which apply transformations to the object directly. Adding or removing
> transformations is simply a question of putting them in conditional
> statements. Applying alternative series of transformations is simply a
> question of if-else or switch blocks.
> 
Huh? How? Your missing the point. The initial structure of the object 
**must** be static. Why? Because if it isn't, then you have to reparse 
the entire structure. Currently you can't tell something that you want 
to add transforms to the 6th nested object in some complex series of 
unions, nor can you "change" those. Its just not possible to do at all. 
The object, once it exists, is static on "all" levels other than the 
base union. All subobjects are inaccessible. That only gets worse when 
dealing with a change to the SDL that allows it to run like a program, 
instead of as a one pass, then reparse for the next frame, system, like 
we have now. If-else blocks won't work because by the time you get to 
the next frame all of the "code" that contains them will have already 
executed, and isn't reparsed, so those statements are **never** checked 
to determine what the new result will be. Instead you have to disconnect 
the object definition, the if-else statements and the execution, so that 
you 1) create an object with some static and some non-static transforms, 
2) render the first version, then 3) access those transforms you need to 
change. Yes, you could do that, sort of, now, but only via something 
like macros, and that won't work in this case, since you can't simply 
throw out the prior frames version, then reparse the macro. You have to 
have an already existing object, which you can make "some" adjustments 
to. Macros don't do that. A Macro would **recreate** the entire object 
each and every time. **Every** method that currently exists in the SDL 
works the way it does *precisely* because the assumption is that you 
won't be changing and *existing* object, but creating a **new** one, 
every single frame. The two implimentations are fundamentally different.

If not, then please, explain to me how I am wrong here. Tell me how, 
with something like an IK chain, you can **change** an object in the 
sub-chain **after** it has already been calculated and added to a union. 
I am willing to bet that if you **really** think about it, its not 
possible. It needs to be possible if you are running a script, instead 
of just parsing a single frame.

> > 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.
> 
>   That's not a technical limitation. That's just a syntax limitation.
> 
>   It would be perfectly possible in the current POV-Ray to change the
> transformation matrix of an existing object if someone simply added the
> proper syntax for it. (And that's exactly one of the reasons why the
> whole new SDL is being discussed. To add easy support for such things.)
> 
Ok, fine. But how do you do that, without adding something that is at 
least semantically the same as what I propose? And why, again, does it 
make sense to store "every" transforms in some array, to be applied all 
at once, instead of maintaining an array of "existing" transforms 
applied the the object, then only adding to, changing or deleting the 
specific on you need to?

> > In an SDL that supports its own animation/render functions, you can't
 
> > have "static" objects.
> 
>   POV-Ray doesn't assume that objects are "static". It's just that there'
s
> no syntax to change the transformation matrix of an existing object. Plai
n
> and simple.
> 
> > 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.
> 
>   Why do you have this obsession that individual transformations *must*
> be stored somewhere?
> 
>   You *apply* transformations in the SDL code. You don't *store* them
> (not as individual transformations anyways). That's because the individua
l
> transformations are already "stored" in the SDL code itself. Why do you
> need to store them in two places?
> 
Yes, they don't have to be. The can be calculated as you go, but they 
still have to then be **applied** individually, regardless of if you 
plan to repeated apply the same initial translate, then a changing 
rotate, then another translate, or something. It might not be "stored" 
any place, but you are still wasting code to do something that is 
functionally the same thing. But yes, if you want to do it that way, you 
could. I suppose, in that sense my idea just means that you have access 
to what ever "initial" state you started with, in a way that is more 
accessible than just returning the matrix and then wondering how the 
hell you got to there (since you can't exactly ask the code itself what 
transforms where needed to get to that point). So, OK, I admit, what I 
propose may not be strictly necessary, it might be useful some times, 
and its a little nicer to have such data "on" the object it effects, 
instead of seperate from it, when you do need it.

>   At each frame you simply execute that SDL which applies the transformat
ions
> to the objects.
>   You are going to have to execute some SDL at each frame anyways (to
> change transformations). It's not any more difficult to simply execute
> the SDL code which applies all the transformations.
> 
> > 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 tryin
g 
> > to get across too.
> 
>   Let me see your suggestion about the new SDL code which modifies the
> "transformation array" at each frame.
>   My answer is that it's the exact same thing, but without the transforma
tion
> array. Simply apply all the transformations to the object at each frame.
> 
Well, I think I am thinking more in terms of the data end, rather than 
the program end. I am thinking in terms of, "Automatic application of 
known transforms.", you are thinking more in terms of, "Manual 
application of any needed transforms." Both work. Your would use far 
less memory than mine, but it slightly obfuscates how the data is 
associated with the object, which is what I was thinking about when I 
got the idea. I wouldn't mind, on after thought, making the array itself 
even more option, so that objects where it could be easier to keep track 
of things with my method could use it. Basically, if you are going to 
use pre-calced arrays of actions, you could either apply them from a 
non-linked version, which would require "manual" application, or you 
could put the array on the object itself, and have to implicitly 
applied.

That might be a better idea anyway. For those cases where you are only 
dealing with "one" compound object, and you are not going to apply the 
transforms to anything else, being able to just define them once, then 
have the system auto-apply them, could help keep the code cleaner, and 
since in "that" case, you are using such an array anyway, having it 
associatively connected to the object itself, as least as far as the 
code is concerned, won't change how much memory is/isn't used. It just 
removes the need, in those cases, of having to remember to manually 
apply the transforms.

This means it wouldn't use the same syntax though. It would be something 
like:

fred.autotransforms = mytable

Where mytable would be the same array you use to do:

fred.applytransforms = mytable.main(1)

Presuming that the number in () was a frame number. A table could thus 
define a range of frames for a set of transforms, or even contain a 
structure for the entire object. The "array" would be seperate, as you 
suggest, but you could access it, "a = fred.autotransforms.main(0)" and
 
you get the benefit that you don't have to use the "applytransforms" 
command **ever** unless you are programatically calculating the results 
(instead of using a list).

You get what I intended, what you think would be better, and the *cost* 
in memory doesn't change by anything other than the pointer needed to 
link the "object" to the "array/table" used to store the transforms for 
each frame.

I admit, this makes more sense than what I was thinking, while still 
providing both the contextual associations I thought would be useful 
"and" the auto-application which imho, makes way more sense than having 
to write hundred of lines of nothing but object.applythis(blah), to get 
the same results, especially in cases where that isn't even necessary 
(like when using "pre-calced" transforms from a database or file).

-- 
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 <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 
> [snip]
> > 
> > Or do you want to beat the straw man some more?
> > 
> I am not familiar with that expression, but anyway here are my 2 cents.
> 
> What you deem necessary for animation is in my (and Warp's if I may 
> speak for him) overkill. It may be handy for some situations but I think
 
> in the majority of cases I wouldn't use it. POV4, however, should make 
> it possible and easy to use. So what this discussion should have been 
> about is to what extend it has to be hardcoded in either the internal 
> datastructures or in the syntax of the language. My (and presumably 
> Warp's) opinion on this is that what you propose will be extremely easy
 
> to implement yourself within the new language for those cases where you
 
> need it. So it has no implication for the current POV4 discussion 
> whatsoever. You are free to continue this discussion with warp of 
> course, but it will be like talking to a wall, without being able to 
> study the delicate texture of the stones.
> The opinion that it is not needed is based on knowledge on how the 
> current implementation works and some safe assumptions on what POV4 will
 
> allow at the minimum. However, you should watch the development closely
 
> that indeed these minimum requirements will be met. Or even better: 
> create a list with those minimum requirements on the new wiki.
> 
Well, I have, in another post today, reversed my position somewhat. I 
still think an associative connection is useful, but that the method I 
suggested "is" a bit overkill and probably not strictly necessary. The 
modified concept allows for:

1. Associative connections between an array with the transforms needed, 
(which may include for multiple frames.), when needed.

2. Auto-magical application of those, instead of having the explicitly 
apply them.

3. No storage of anything "on" the object itself.

This loses the ability to track the "initial" state though.

But, one thing I do still think needs to remain is the idea that if you 
don't "explicitly" change a matrix, either via the automatic system or 
the manual code based one, it doesn't make sense to "reset" everything 
to the base state, then reapply things. Not sure how you work that 
though, since a change to a foot might have "its" matrix effected by 
transforms on the lower leg, upper leg, and even the full object. Do you 
just "save" the matrix for each object/union level, then reapply those 
transforms that effect them? If you reset them completely, then you are 
re-applying possibly hundreds of transforms, which you *must* store some 
how, when you might only be changing "one" in the entire chain. Its 
probably more cost effective to store all matrices at each level (i.e. 
the "default" state for that object/union), then only recalc those 
"specifically" effected by any change you later make. Hmm..

Oh, and "straw man" refers to side tracking an issue into something 
either not directly related to, or completely unrelated to, the main 
issue being discussed, usually, though not always, to avoid talking 
about the original subject. Its similar to "tilting at windmills".

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