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

In article <471164bc@news.povray.org>, evi### [at] hotmailcom 
says...
> 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 eye
s 
> > at the same time, if they have the speed and the language allowed it, o
r 
> > 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
> 

(A) doesn't let you, that easily any way, place the camera where you are 
looking and it looking at its own result, which is looking at its own 
result, etc. Yeah, its still possible, but it usually requires feeding 
the same scene through multiple times. Its not **that** much different 
than using a reflective surface though, in terms of how it would work. 
You are just displacing the path of your ray to a new location, then 
continuing, until you reach your recursion limit. Would be fun to see 
how practical it was to do that at least, even if it proved too 
inconvenient to use.

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

I think this is getting to be how to implement something
vrs what would be a good language feature.

It might be nice to have better animation support in
the language itself, something like ...

#declare leg = MOB {
   skeleton {
      thigh connected_to knee
      knee connected_to shin
      shin connected_to foot
      thigh { length 1 elasticity 0 mass 1.5 }
      knee { length 0.1 elasticity 0 joint_spring 1 mass 0.1 rest_bend 
<0,0,0>}
      shin { length 1 elasticity 0 joint_spring 1 mass 0.75 rest_bend 
<30,0,0>}
      foot { length 0.3 elasticity 0.1 joint_spring 0.5 mass 0.2 rest_bend 
<90,0,0>}
   }
   skin {
      thigh looks_like {cylinder{..}}
      knee looks_like {sphere{..}}
      thigh looks_like {cylinder{..}}
      foot looks_like {box{...}}
   }
},

MOB {
   start_at_location <...> at_time 0
   waypoint <...> at_time 0.5
   end_at_location <...> at_time 1
   movement {bend knee <80,0,0> velocity 0.25} at_time 0.51
}
post_process {save_animation "leg.mpg"}

The end user probably doesn't care if the data is stored in memory,
or written to the disk, how the inverse kinematics is implemented.
just that there's an easy way to do things like knee-jerking,
and save and view the animations.

-----
500 Internal Server Error
A team of highly trained monkeys has been dispatched to deal with this 
situation. Please report this incident to customer service.
Also, please include the following information in your error report: BANANAS

Post a reply to this message

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

  How are you supposed to do step 3 without executing any code, like you
stated above?

  Even if it's done by executing some code, why would it be any more
difficult to apply a set of transformations to the object than it would
be to modify a set of transformations in the object? It's basically the
same thing (except that the former doesn't need to waste so much memory
needlessly).

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

  Again: Why do you think that the new SDL should have byte-compilation
and even JIT-compilation support?

  And also: How else are you supposed to change the object at each frame?

> You have to 
> have an already existing object, which you can make "some" adjustments 
> to.

  Without executing any code? How exactly?

  And again: Why would it be any easier to modify an array of transformations
than it would be to apply a set of transformations to the object?

> Macros don't do that. A Macro would **recreate** the entire object 
> each and every time.

  You are the only one talking about recreating objects here. I don't
understand why.

  I have been talking about applying sets of transformations to existing
objects.

  (And besides, it should be possible to create *new* objects and delete
existing ones at each frame, for memory optimization reasons.)

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

  No, the current SDL works like it works because of it's based on 10 years
old code. It's exactly why a rewriting is planned.

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

  By writing SDL code which applies transformations to it. In the exact
same way as your solution, but without the need for the useless arrays.

> I am willing to bet that if you **really** think about it, its not 
> possible.

  So in your opinion it is possible to change an array of transformations
at each frame, but it is not possible to apply a set of transformations at
each frame?

  So what is it that makes the difference?

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

  It wouldn't be very much different, and that's exactly my point.
The only difference is that your "transformation array" is useless and
completely unneeded for this.

> And why, again, does it 
> make sense to store "every" transforms in some array, to be applied all 
> at once

  Eh, that's exactly what I am asking you. There's no need for any array.

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

  There's no need to do it that way. That's only one possibility of doing
it. A possibility seldom needed or used. That's not how rendering works
in general out there.

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

  It's not "wasted code". Your solution is to first write code to initialize
the array for the first time and then at each frame run some other code
which modifies the array.
  The general solution (used often eg. in OpenGL) is to write just one
routine which applies the transformations (possibly depending on some
variables, etc) at each frame. This can actually save coding because
basically you are only doing the initialization step. (If the object
is not modified between frames then running this code can be skipped,
of course.)

  (Of course if you really *want* to have an array which you modify and
then apply, you can. However, you are not forced to use one.)

> 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

  The problem with your solution is that it hard-codes one data container
which is not very flexible. And what makes it worse is that there just
isn't need for such a data container.

> in a way that is more 
> accessible than just returning the matrix and then wondering how the 
> hell you got to there

  You don't read a transformation matrix and try to modify it. You reset
the transformation matrix and apply the transformations to it. That's
standard procedure.
  The chain of transformations is already "stored" in the very code
which applies those transformations. In your proposed solution this
chain of transformations would be located at two places: In the array
and the code which initializes the array. This is redundant and unneeded.

  (Besides, related to the earlier discussion in this post, even having
such arrays doesn't at all solve the problem of how to transform sub-objects
in a deeply-nested union.)

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

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> It might be nice to have better animation support in
> the language itself, something like ...

  IMO it would be better if things like skeletal animation would be
a library instead of being a core feature of the scripting language.

  Being a library makes it more flexible and easier to modify. Being
a hard-coded inner feature makes it rigid and hard to modify.

-- 
                                                          - Warp

Post a reply to this message

>> It might be nice to have better animation support in
>> the language itself, something like ...
>
>  IMO it would be better if things like skeletal animation would be
> a library instead of being a core feature of the scripting language.
>
>  Being a library makes it more flexible and easier to modify. Being
> a hard-coded inner feature makes it rigid and hard to modify.

Perhaps more flexible, but a language syntax for animation
that is designed  to be human readable would be easier to
modify the scenes.
(by definition, since it would be designed that way)

Are we going to put language re-write rules into the SDL?
If so then an #include "animation.inc" could make such
syntax as the previous example optional and easily modified.
Something like the following, which is perty verbose and ugly,
(and incomplete) but only needs to be included by the average
user...

#define MOB {
   #require MOB_IDENTIFIER | MOB_ITEMS
   MOB_ITEMS {
      #require skeleton {SKELETON_ITEMS}
      #require skin {SKIN_ITEMS}
   }
   SKELETON_ITEMS {
      #require [BONE_IDENTIFIER {}]
      #optional [BONE_IDENTIFIER_1 conected_to
                      BONE_IDENTIFIER_2] {
         #local BONE_IDENTIFIER_2_LOCATION =
                   BONE_IDENTIFIER_1_LOCATION + transforms..
     }
   }
   SKIN_ITEMS {
      #require [BONE_IDENTIFIER looks_like {OBJECT_IDENTIFIER}]
   }
   #optional start_at_location VECTOR at_time FLOAT {
      #if (clock = FLOAT) #local LOCATION = FLOAT; #end
   }
   #optional end_at_location VECTOR at_time FLOAT {
      #if (clock = FLOAT) #local LOCATION = FLOAT; #end
   }
}

Post a reply to this message

Patrick Elliott wrote:

> (A) doesn't let you, that easily any way, place the camera where you are 
> looking and it looking at its own result, which is looking at its own 
> result, etc. Yeah, its still possible, but it usually requires feeding 
> the same scene through multiple times. Its not **that** much different 
> than using a reflective surface though, in terms of how it would work. 
> You are just displacing the path of your ray to a new location, then 
> continuing, until you reach your recursion limit. Would be fun to see 
> how practical it was to do that at least, even if it proved too 
> inconvenient to use.

This is precisely what occurred to me as I was writing the stuff above; 
the texture is really a kind of reflection/refraction that displaces the 
eye of the new ray in addition to changing the direction, so it would 
certainly be very simple to implement.

BUT

I'm not so sure that it's a great priority.

Regards,
John

Post a reply to this message