 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <471164bc@news.povray.org>, evi### [at] hotmail com
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Attwood <tim### [at] comcastnet> wrote:
> 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)
Not necessarily. A script-based solution may be equally easy to
understand, but much more flexible (because the implementation is
easy to change).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>
> Sigh.. Your just getting it at all. The ***existing*** SDL assumes that ...
"You really don't understand why the current one is the way it is, do you?"
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).
#macro applyTransforms(Object, Trans)
#local I=0;
object {
Object
#while (I<dimension_size(Trans,1))
transform { Trans[I] }
#local I=I+1;
#end
}
#end
Modify the Transforms array whenever you want to, then call
applyTransforms at the end of the script.
Usage:
#declare Transforms=array[4];
#declare Transforms[0] = transform { rotate x*20 };
//no reason to have a single transformation
#declare Transforms[1] = transform { translate <1,2,3> rotate y*45 };
#declare Transforms[2] = transform { scale 1.1 };
#declare Transforms[3] = transform { rotate y*20 };
...
//modify existing transformation
#declare Transforms[0] = transform { rotate x*21 };
Then call the macro and be done with it. We don't need any stinking
transformation array built-in (also, if POV did it automatically, it
would keep [1] as two entries).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
