 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] san rrcom> wrote:
>>> It would make rendering slow as the whole array will need
>>> to be computed for every ray that encounter the object,
>
>> Nonesense. Once the tracing starts, you compute the final transformation
>> matrix, just like you do now when there are multiple transforms.
>
> It's not a question of efficiency, it's a question of not hard-coding
> one specific solution where no such hard-coding is necessary at all.
Sure. I'm not the one advocating that every object gets such an array.
:-) I'm just pointing out that some of the objections are mistaken.
Arrays you can index by objects and into which you can store anything
(including transformations) would seem to be the obvious way to go.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <470dbc43$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > Umm. Because it doesn't make much sense? Seriously, any such transforms
> > are going to be "very" specific to the IK chain of the particular objec
t
> > you are working with. There is no point in making an array called
> > "walk", which contains the needed transforms, instead of making it part
> > of the object, because logically it can't be applied to any "other"
> > objects.
>
> Errr, well, have you used Hash Animation Master? As long as you name the
> bones the same there, you can apply the "walk" to anything you want.
>
> However, you missed my point, which was that if the array is separate
> from the object, you can have multiple arrays and hence multiple sets of
> transformations that apply to the object at different times in the
> animation. If the character walks a while, then runs a while, do you
> put the walk transformations or the run transformations in the object?
> If the array can be indexed by the object itself, then there's no
> question in the code of the transformation being "off separate"
> somewhere that's hard to find.
>
But, nothing is stopping you from trading out the arrays, like you would
with any other similar case. And yeah, I covered the issue with applying
the "same" walk to anything you want. 1) it wouldn't really work, unless
it had identical parts, and 2) for realistic animation of anything other
than marching robots, its not applicable, since you never want two
objects behaving 100% identically to each other.
Ok, lets get at a practical example. Lets say all you have is a sphere
and torus. The torus is rotated a bit out of the plane of rotation. The
initial design would look like (not checking the code, so I hope it
comes out close. lol):
#define wobble = union{
sphere {<0,0,0>, 1}
torus {<0,0,0>, .5, 2> rotate <.1,0,0>
texture{blah}
rotate <0,clock,0>
translate <56,43,12>
}
This makes an object that, from the code perspective, looks like:
wobble
\-sphere
\-location
\-size
\-torus
\-location
\-size
\-transforms
\-[0] rotate <.1,0,0>
\-texture
\-...
\-transforms
[0] rotate <0, clock, 0>
[1] translate <56,43,12>
This "continues" to be the way it works for 10 frames. Then you "keep"
the rotation, but also change the angle of the torus (over 10 more
frames).
toruschange[0] = "rotate <.1 * (20-10/10),0,0>"
toruschange[0] = "rotate <0,0,0>"
wobble.torus.transforms[0] = toruschange[0]
Then at frame 21 you "stop" both the rotation and the change to the
torus, but send the object zipping down some 3D path:
z = clock //Lets say its now also 21.
main_trans[0] = "rotate <0,z,0>"
main_trans[1] = "translate GetLocation()"
wobble.torus.transforms[0] = toruschange[1]
wobble.transforms = main_trans
In this case z, unless you change it, will "remain" 21, so from then on
you don't need to update anything in the object, and "GetLocation"
returns a "path" that the object is going to follow, so that is
automatically recalculated each frame, before the render happens.
You saving memory this way, because you **don't** have to change any
transforms that you don't have to, while your way requires they all be
stored, even the ones that don't change. Further, the "initial" state is
"stored" in the object, so if instead you wanted wobble to do nothing
but sit in one place through the entire animation, without ever changing
its behavior, you don't ever have to do anything more than set use the
SDL to tell it to use the clock value the determining how much to rotate
it each frame.
Note, it might be useful to allow the "clock" to return both an integer
of all "seconds" that have passed, as well as things like clock.seconds,
clock.minutes, etc. Just for the sake of only having to do, "rotate <0,
clock.seconds * 6, 0>", instead of something like "rotate <0, mod(clock
/ 60) * 60, 0>". Mind, that isn't that bad, but a more direct way to get
the number might be nice anyway, especially if you are incrementing the
time by a large factor, like for time lapse or something.
--
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 <470dec42@news.povray.org>, war### [at] tagpovrayorg says...
> Darren New <dne### [at] sanrrcom> wrote:
> > > It would make rendering slow as the whole array will need
> > > to be computed for every ray that encounter the object,
>
> > Nonesense. Once the tracing starts, you compute the final transformatio
n
> > matrix, just like you do now when there are multiple transforms.
>
> It's not a question of efficiency, it's a question of not hard-coding
> one specific solution where no such hard-coding is necessary at all.
>
> (Besides, it *is* a question of efficiency too: Those arrays will
> consume extra memory which is not necessary to be consumed. This may
> become an issue with millions of objects.)
>
Your solution **still** requires extra arrays, or code, or **some** way
to get the changing data "to" the object to transform it. If anything,
as I try to explain in another post, your method is actually **more** of
a memory hog. You keep claiming that you can just somehow "untransform"
the matrix, or change it later, even when doing something like
translate->rotate->translate irrevocably creates conditions where its no
longer as simple as just adding one new rotation. Some how you have to
both save memory "and" provide a way to change interdependent
transforms, which, unless you are a fracking mathmatician, isn't going
to be practical. any solution you come up with, at minimum, is going to
require some transforms to be user changable, after the fact, and
keeping **all** of them in an array, to be applied later, is **worse**
that keeping all the of the initial states on the object, then just
changing the one you actually need to.
I haven't seen any argument from you that does a thing to truly address
that issue.
--
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 <470ec586$1@news.povray.org>, dne### [at] sanrrcom says...
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >>> It would make rendering slow as the whole array will need
> >>> to be computed for every ray that encounter the object,
> >
> >> Nonesense. Once the tracing starts, you compute the final transformati
on
> >> matrix, just like you do now when there are multiple transforms.
> >
> > It's not a question of efficiency, it's a question of not hard-coding
> > one specific solution where no such hard-coding is necessary at all.
>
> Sure. I'm not the one advocating that every object gets such an array.
> :-) I'm just pointing out that some of the objections are mistaken.
> Arrays you can index by objects and into which you can store anything
> (including transformations) would seem to be the obvious way to go.
>
Why? Its going to cost you more memory to store 20 transforms for an IK
chain, and all changes needed for them, in separate arrays, than it will
to store 20 transforms in the object, then apply only 3-4 changes from
"your" array, which are needed to change the specific parts that are
needed. One uses, lets say 20*5, just to pick an arbitrary number for
the storage needed, + 4*5*number of changes. Yours requires 20*5*number
of total changes you need. If the number of changes are say 10, then
mine takes 20*5 + 4 * 5 * 10 = 300, yours takes 20*5*10 = 1,000. How th
e
heck is that "better"? Mind you, this is a "simple" example. It only
gets worse if it something that has 10 IK change points, and 90 objects.
In that case its 90 * 5 * 10, or 4500 for you, and 90 * 5 + 10 * 5 * 10,
or 950 for mine. Its only *equal* if every object has to have "every"
transform changed between frames, and thus all of them replayed into the
object. The more objects that are part of the IK design, the more insane
your number gets, while mine only grows depending on the number of
"specific" transforms you need to change during animation, plus the
total number of original transforms.
Yes, it would be nice to have a solution that doesn't require any such
thing to start with, and you can get by with that, to some extent, by
having a function call to something that determines the next change,
instead of a straight change. I have not however seen anything to
convince me that "some" sort of solution similar to this isn't needed.
At least not unless you throw out the entire old SDL and force everyone
to use "your" solution to apply all the transforms all at once, every
frame, which means abandoning the original SDL, since it can't currently
work that way.
--
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 <470df2c7$1@news.povray.org>,
fab### [at] yourshoesskynetbe says...
> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >> But this could be handled in SDL, no ?
> >
> > The main problem is that this "store all transformations in an array
> > inside the object" is a hard-coded solution which makes no sense. It
> > needlessly fixes this "problem" (which really isn't a problem at all,
> > which is something they just cannot seem to comprehend) with one single
> > hard-coded solution. If someone would like to use a different approach
> > then the internal array would be a completely useless waste of memory.
> >
> > Let's assume someone is implementing something where he really wants,
> > for whatever reason, to store all the individual transformations in a
> > data structure (instead of simply executing a series of commands which
> > will accumulate the transformations into a single transformation matrix
).
> > What happens if the data structure he wants to use is a list? What if h
e
> > wants to have *several* data structures containing alternative sets of
> > transformations? What if he wants the transformations in a binary tree?
> > He will have to implement these solutions in SDL, and the transformatio
n
> > array inside the object will be a useless waste of memory.
>
> That's what I meant : implement the "transformation history" using SDL.
>
> If the SDL is powerful enough, it could even be automatic : each time
> something tranforms an object, an "event" mechanism adds the transform
> to the history.
>
Gah!! This is exactly what I am talking about. And everyone else is
instead saying, "Gosh, this is silly, why not just store every single
transform some place else, so it takes up even more memory, then apply
them all over again anyway, not from the history, but from a bunch of
arrays?" Feel like I am talking to a wall here.
> Objects could even have some kind of "extended data" that could be attach
ed
> to them, and be used as the user wishes. (it would help things like
> parent-chlid relations between objects)
>
> > If someone really wants to use an array to store individual transform
ations
> > then he can do so. However, most importantly, he is not *forced* to do
so
> > if he doesn't want to.
>
> Yep.
>
> Fabien.
>
Look, the only reason I am suggesting it is so that when you create an
object the current "history" or "state" is accessible, so you can look
at it, or change it. Sigh.. I have a feeling people are just so stuck on
the idea of how they do things "now" that they just don't get why the
solutions being proposed are either a) worse than mine, or b) make no
sense in an SDL that doesn't work *exactly* like the way it does now.
--
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 <470### [at] hotmailcom>, a_l### [at] hotmailcom
says...
> Patrick Elliott wrote:
> > In article <470### [at] hotmailcom>, a_l### [at] hotmailcom
> > says...
> >> What I was saying is that we should distinguish between the 'first
> >> creation' and the 'final creation'. Calling both simply 'creation' wil
l
> >> lead to confusion (as shown is this thread. Much of what you and
> >> Patrck are writing does not make sense to me, because for me 'creation
'
> >> is 'final creation').
> >>
> > How about "intermediary" creations then, just to confuse things more.
> > lol Technically, by your definition, the object is never "created" unti
l
> > the frame in rendered, at least in any system like we are talking about
,
> > where each "frame" is defined not by re-running the entire script, but
> > only via the command "in" the script.
> >
> > In other words, in the current model we do this:
> >
> > render("myfile")
> >
> > in a true animation system, we do this:
> >
> > 'Set up a bunch of objects.
> > ...
> > render
> > 'Change the objects some.
> > ...
> > render
> > 'Change them some more.
> > ...
> > render
> >
> > The "render" step is explicit in the script, since it only happens
> > "when" all the changes are made, not an external process that just runs
> > an SDL through it, and recalcs the data for everything as it does it,
> > based on the existing clock scheme, which is kind of limited. Mind you,
> > making that change, depending on how it was done, could break existing
> > SDL. Mind you, a command that "requests" the prior behavior could be
> > used to solve that.
>
> You could also assume that a render command is implicit at the end of
> parsing if none is given.
>
Yes, I had considered that, but its better to have a compatibility flag,
both so that someone doesn't try to run an old SDL, then wonder why it
didn't work right, and so that someone using a *new* SDL could be warned
that they forgot to actually render anything. Its kind of a toss up
though.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Gah!! This is exactly what I am talking about. And everyone else is
> instead saying, "Gosh, this is silly, why not just store every single
> transform some place else, so it takes up even more memory, then apply
> them all over again anyway, not from the history, but from a bunch of
> arrays?" Feel like I am talking to a wall here.
You are talking to a Warp.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sel### [at] rraznet> wrote:
> Why? Its going to cost you more memory to store 20 transforms for an IK
> chain, and all changes needed for them, in separate arrays, than it will
> to store 20 transforms in the object
You don't get it, do you? Forcing a transformation array to exist in every
single object increases memory consumption compared to objects not having
such an array, and a separate SDL array being used only in objects which
need it.
If you have 10000 objects in your scene, 10 of which are IK'ed, forcing
a transformation array to exist for every single one of the 10000 objects
(even if those arrays are empty or contain just one transformation) is
going to consume much more memory than if the array existed only for those
10 IK'ed objects.
Do you think having an empty array in an object takes no memory?
Anyways, no array is needed, not even for IK'ed objects. How do you think
the current POV-Ray manages without such arrays? And no, the answer is not
"by reparsing every object each time".
> then apply only 3-4 changes from
> "your" array, which are needed to change the specific parts that are
> needed. One uses, lets say 20*5, just to pick an arbitrary number for
> the storage needed, + 4*5*number of changes. Yours requires 20*5*number
> of total changes you need. If the number of changes are say 10, then
> mine takes 20*5 + 4 * 5 * 10 = 300, yours takes 20*5*10 = 1,000.
Those numbers don't make any sense.
> At least not unless you throw out the entire old SDL and force everyone
> to use "your" solution to apply all the transforms all at once, every
> frame, which means abandoning the original SDL, since it can't currently
> work that way.
What the heck are you talking about? Object-specific transformation arrays
are needed to preserve the current SDL?
The more you write, the weirder it gets.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sel### [at] rraznet> wrote:
> Your solution **still** requires extra arrays, or code, or **some** way
> to get the changing data "to" the object to transform it.
Well, you have to define the objects somehow. You could as well
define them so that the transformations can be executed at each frame,
at *no additional cost*. The transformation code must exist in one form
or another.
> 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?
>, or change it later, even when doing something like
> translate->rotate->translate irrevocably creates conditions where its no
> longer as simple as just adding one new rotation.
I don't think you even understand how transformation matrices work.
If you really think that an individual transformation couldn't be removed
from a transformation matrix even after several other transformations
have been applied to it, then you should *really* acquaint yourself with
transformation matrices and the math involved.
In all these posts I haven't even been talking about removing/changing
one single transformation from the transformation matrix, but even that
is certainly possible to do to a transformation matrix, if you really
wanted to do so. (No, it's not possible to retrieve every individual
transformation which has been applied to a transformation matrix, but
if you already know which transformations has been applied to it, it is
possible to undo one of them. Anyways, that's not very relevant.)
> Some how you have to
> both save memory "and" provide a way to change interdependent
> transforms
You don't understand this either, do you? The memory wasting comes in
your solution in that *every* object will have a useless array, wasting
memory, when none is needed.
In other words, in your "solution" every object has a transformation
array *and* there exists SDL code which writes values to that array.
In the correct solution there's no such array and only the code exists.
Do you understand now how there's less memory requirements in this way?
>, which, unless you are a fracking mathmatician, isn't going
> to be practical.
You don't need to be a mathematician to apply a series of transformations
to an object. It's just a question of syntax.
> any solution you come up with, at minimum, is going to
> require some transforms to be user changable
How does the current SDL handle transformations which change from one
frame to the other? Why should the new SDL be any different (except that
re-parsing the object itself can be skipped)?
> after the fact, and
> keeping **all** of them in an array, to be applied later, is **worse**
> that keeping all the of the initial states on the object, then just
> changing the one you actually need to.
Why is it worse?
The only thing which is worse is your solution: You are hard-coding one
specific solution, and you are wasting memory by having a useless array
in each single object.
> I haven't seen any argument from you that does a thing to truly address
> that issue.
That's because you have a misunderstanding about how transformations work.
Answer me this: Why the current POV-Ray doesn't need object-specific
transformation arrays?
The answer is not "because it re-parses the objects at each frame".
That re-parsing could perfectly be skipped with the proper syntax changes.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sel### [at] rraznet> wrote:
> > If the SDL is powerful enough, it could even be automatic : each time
> > something tranforms an object, an "event" mechanism adds the transform
> > to the history.
> >
> Gah!! This is exactly what I am talking about. And everyone else is
> instead saying, "Gosh, this is silly, why not just store every single
> transform some place else, so it takes up even more memory, then apply
> them all over again anyway, not from the history, but from a bunch of
> arrays?" Feel like I am talking to a wall here.
What the heck do you need a "transformation history" for? You don't need
it currently, nor you need it in the future SDL either. Why would it be
any useful?
The "transformation history" is in the SDL code you write. Why do you
need to store it somewhere else as well? That's just a completely useless
waste of memory.
> Look, the only reason I am suggesting it is so that when you create an
> object the current "history" or "state" is accessible, so you can look
> at it, or change it.
Why do you need to "look at it" and "change it"? The transformations
are already in the SDL code you write. Just write them so that they
change appropriately at each frame. I just can't see what the heck is
the problem.
> Sigh.. I have a feeling people are just so stuck on
> the idea of how they do things "now" that they just don't get why the
> solutions being proposed are either a) worse than mine, or b) make no
> sense in an SDL that doesn't work *exactly* like the way it does now.
There's a reason why there are no "transformation arrays" in the current
SDL. The reason is that they are not needed. They would only be a completely
useless waste of space.
And once again, you would be hard-coding one specific solution. That is
not the way to go. Hard-coding solutions is bad programming.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
