In article <4713433c@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > 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.
> 
>   I didn't understand that.
> 
> > Currently you can't tell something that you want 
> > to add transforms to the 6th nested object in some complex series of 
> > unions
> 
>   That's a syntax limitation in the current SDL, not a technical one.
> 
> > nor can you "change" those.
> 
>   It would be possible to change them if the proper syntax would be added
.
> 
> > The object, once it exists, is static on "all" levels other than the 
> > base union.
> 
>   It just looks like it for the simple reason that the current SDL has no
> syntax for modifying it. AFAIK there isn't any technical limitation to th
is,
> just that the SDL hasn't been enhanced to do this.
> 
> > That only gets worse when 
> > dealing with a change to the SDL that allows it to run like a program,
 
> 
>   You mean the current SDL is not "run like a program"? How so?
> 
> > 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
> 
>   1) If code is not executed at each frame at all, by which method are
> you suggesting the user could change some transformations at each frame?
> 
>   2) Why do you think the new SDL should have byte-compilation and even
> JIT-compilation support? Just for fun? No, for the precise reason that
> it doesn't need to be *parsed* again and again, just parsed once and then
> executed as many times as necessary.
> 
> > so those statements are **never** checked 
> > to determine what the new result will be.
> 
>   Why have such a stupid limitation? There's no reason nor need to.
> 
> > Instead you have to disconnect 
> > the object definition, the if-else statements and the execution, so tha
t 
> > 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 t
o 
> > change.
> 
>   How are you supposed to do step 3 without executing any code, like you
> stated above?
> 
.... Ok, read this far and you keep repeating the same assertion that I 
said the "new" SDL wouldn't execute any code, which is only "partly" 
true. Sure, it would have to execute some code to change the data being 
used, and a "render" command, but it wouldn't have to execute 
instruction for every single sub-object in the main object to do so. 
That would happen implicitly. I am sorry I wasn't clear about that 
point. And it was in no way meant to imply that more direct methods 
wouldn't be available. But, its a mute point, since in this same post I 
admit some of the concept was badly considered anyway.

> ...
Ok, lets continue from here, since this is where I admit that I might 
have been arguing something that... well, while it would have worked, a 
better compromise exists, which does the things I intended, without the 
things I am more than willing to admit I hadn't thought out well.

> > So, OK, I admit, what I 
> > propose may not be strictly necessary, it might be useful some times,
 
> 
>   That's exactly the point: *Sometimes*
> 
>   The thing is, if *sometimes* you would need such an array, you can
> create one. There could even be some kind of library to aid you doing
> this. But the point is that this specific solution should not be forced
> on the user since it's not necessary.
> 
>   This kind of specific solution should not be something done in the
> core code. The core code should have a more generic solution.
> 
> > >   Let me see your suggestion about the new SDL code which modifies th
e
> > > "transformation array" at each frame.
> > >   My answer is that it's the exact same thing, but without the transf
ormation
> > > array. Simply apply all the transformations to the object at each fra
me.
> > > 
> > 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."
> 
>   There's nothing stopping you from automatically applying transforms
> to the object from some data. Your "array" solution makes absolutely
> no difference in this.
> 
No it doesn't. And, as I post in a later sub thread, there is a solution 
to that, which does what you want, and what I want. Which is to have the 
"array" or "table" used be linked to the object only through an 
associative pointer. The trick being that you could, as I describe 
there, implicitly have the table of transforms applied at the render 
step, saving the need to explicitly apply them, while "still" allowing 
for direct application in cases where you need to calculate those 
changes on the fly. Basically, if you know that object X is already 
following a "precise" set of predetermined actions, and you have no need 
to change them programically, put them in a table, link the table, then 
have the parser/post parser/engine, or what ever apply them via that 
mechanism, instead of "requiring" them to be applied implicitly. This 
both a) allows such tables of actions to be automated and b) maintains 
the "associative" connection I was looking for in such cases, making it 
easier to keep track of just "which" object the table belongs to.

Mind you, I fully expect you to argue that this is just as silly and 
useless. 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