I've got following problem:
For an algorithm to behave realistic, I need to know
the speed an object has. Problem is, I only have the
boundary-box accessible, and this one may change
its size. The object is macro driven and may suddenly
become something different, or just grow at certain
places.

Thinking about it, there is no error-proof method of
getting the speed from that, is there?

Hm. Perhaps I'll need to seperate object and its
transformation, and just apply the transformation to
a position. This'll give me the possibility of generating
the speed...

Any other ideas?

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message

In article <3e8d43ea@news.povray.org>,
 "Tim Nikias v2.0" <tim### [at] gmxde> wrote:

> Thinking about it, there is no error-proof method of
> getting the speed from that, is there?

POV objects do not have speed or motion. You are going to have to keep 
track of these values yourself.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Perhaps you misunderstood what I was saying (or
I said it wrong, it depends... :-)

If I've got a macro which returns me an object, which is
based upon the float X, which itself may range from
0 to 1, then I've got something like an animated object,
right? At least, if I'm changing X according to some clock.

So, if I can check object at X=0 and at X=.1, I've possibly
got two different positions for the object, but there might
as well be two different objects, if the macro switches
between objects according to the X-Value.

I was sort of thinking of some "Radar" Script which will
ping the two different positions and return me the distance
covered in relation to difference in the X Values.

But I can't do that, already figured that out. Solved it like
you mentioned: some other macro which is used for
placing the object. If I transform a vector with it, I can
see where the vector was at transform with X=0 and
with X=.1, I can calculate the distance etc etc.

I was thinking about "pinging" the boundary box, but that
doesn't work when the object changes, and you're comment
was right anyway, but just wasn't what I asked for.

Now, now, don't start crying! :-)


--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>
> > Thinking about it, there is no error-proof method of
> > getting the speed from that, is there?
>
> POV objects do not have speed or motion. You are going to have to keep
> track of these values yourself.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Post a reply to this message

In article <3e8da2c3$1@news.povray.org>,
 "Tim Nikias v2.0" <tim### [at] gmxde> wrote:

> So, if I can check object at X=0 and at X=.1, I've possibly
> got two different positions for the object, but there might
> as well be two different objects, if the macro switches
> between objects according to the X-Value.

It *is* two different objects. An object only has current state, no 
information about past or future state. X is just a parameter for 
generating the object. The clock value only has any meaning to the code 
that generates the objects for the current frame. For each frame, it is 
just a number.
Did you think an object with a transform based on clock was actually 
moving? It's not, it is just a series of stills. There is no motion 
information to retrieve, you have to handle it yourself.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

We're talking about the same thing. Yes, I'd have to
generate the speed myself, from two different stills.
My problem was, how I could do that, if all that I've
got is one Macro, which returns me the different
stills, and all I can actually get from there is a boundary
box: Having several stills of boxes which may or may
not be the same size, not to mention will never rotate,
won't give me the possibility to calculate the speed.

I'm not a total newbie, there is some stuff I do know. :-)

Anyways, you and I were saying exactly the same thing,
just that you have been commenting from the side of
"you need to handle and generate speed yourself, you
can't retrieve it somehow from POV" and I was asking
just that. To me, it seems like we're trying to argue the
same point.

But I think we're behaving well, aren't we? :-)

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>
> > So, if I can check object at X=0 and at X=.1, I've possibly
> > got two different positions for the object, but there might
> > as well be two different objects, if the macro switches
> > between objects according to the X-Value.
>
> It *is* two different objects. An object only has current state, no
> information about past or future state. X is just a parameter for
> generating the object. The clock value only has any meaning to the code
> that generates the objects for the current frame. For each frame, it is
> just a number.
> Did you think an object with a transform based on clock was actually
> moving? It's not, it is just a series of stills. There is no motion
> information to retrieve, you have to handle it yourself.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Post a reply to this message

"Tim Nikias v2.0" <tim### [at] gmxde> wrote in 
news:3e8e209c@news.povray.org

> not be the same size, not to mention will never rotate,
> won't give me the possibility to calculate the speed.

vlength(newPos - oldPos) / clock_delta

where newPos and oldPos is one of box corners ?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

My only thought is to calculate the center of gravity of the object (I know
probably very difficult to do).  Since the object is changing throughout the
animation, the bounding box measurement method won't likely produce a
realistic result.
A quick way is to find the center of the bounding box (easier, but probably
still inaccurate)
How sure are you that the object when transformed will have the center of
gravity along a continuous path?
That would be important for a realistic animation.

well, that's my 2 cents on the problem.

Kruger


"Tim Nikias v2.0" <tim### [at] gmxde> wrote in message
news:3e8d43ea@news.povray.org...
> I've got following problem:
> For an algorithm to behave realistic, I need to know
> the speed an object has. Problem is, I only have the
> boundary-box accessible, and this one may change
> its size. The object is macro driven and may suddenly
> become something different, or just grow at certain
> places.
>
> Thinking about it, there is no error-proof method of
> getting the speed from that, is there?
>
> Hm. Perhaps I'll need to seperate object and its
> transformation, and just apply the transformation to
> a position. This'll give me the possibility of generating
> the speed...
>
> Any other ideas?
>
> --
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
> Email: Tim### [at] gmxde
>
>

Post a reply to this message

Tim Nikias v2.0 wrote:
> I've got following problem:
> For an algorithm to behave realistic, I need to know
> the speed an object has. Problem is, I only have the
> boundary-box accessible, and this one may change
> its size. The object is macro driven and may suddenly
> become something different, or just grow at certain
> places.
> 
> Thinking about it, there is no error-proof method of
> getting the speed from that, is there?
> 
> Hm. Perhaps I'll need to seperate object and its
> transformation, and just apply the transformation to
> a position. This'll give me the possibility of generating
> the speed...

If the object rotates, changes size or grows at certain points then 
different parts of it will be moving at different speeds, which point do 
you want to measure the speed of?

I assume from what you've written that there is some nominal 'centre' of 
the object which is being translated by different amounts in different 
frames, but that due to the structure of your code this translation 
calculation and its results are inaccessable to your speed calculation. 
Without seeing any code it is difficult to see what the problem is, but 
it sounds as though the calculation that produces the transformation is 
bundled up inside a whole lot of other code in a macro that generates 
the object and positions it. In that case your last paragraph would seem 
to be bang on target, your code is not modular enough, and needs to be 
broken up into smaller logical units. Write a separate macro that does 
nothing but spit out a vector describing the translation of the object 
at a given moment, then call it from both the object generation code and 
the speed calculation.

Post a reply to this message

It is like this:
I'm writing a Water-Surface-Simulation, you might have
noticed the animations and some images I've posted
recently.
The only thing missing for that was the ability to have
ANY object interact with it, especially when this object
is animated and moves around in the water.
Since I can't predict which kind of object a User might
want to drop into the water, and since my system
somehow needs to derive the position/speed in order
to calculate the interaction I've come up with this:

One Macro shall describe the object.
A second describes the transformations.

As you've pointed out, I can't get rotations from
that. But I didn't want the User to describe some
Multi-Section Macro for his object, this might be
over the head of some (probably even for me :-)

So, if someone would want to have something like a
watermill, he'd have to cut the pieces interacting with
the water into several parts, which will thus gain their
own speed/position calculations. This'll surely raise the
parsing time, but it seems more intuitive to me, than
some complicated macro.

And how does my system recognize the macros?
Well, the object-macro has a name, like "Object_1"
The respetive transform-macro should thus be
"Object_1" + "_Transform" = Object_1_Transform.
Using File-I/O, I parse the strings into a single Macro,
which my System will then use for its calculations.



--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

> Tim Nikias v2.0 wrote:
> > I've got following problem:
> > For an algorithm to behave realistic, I need to know
> > the speed an object has. Problem is, I only have the
> > boundary-box accessible, and this one may change
> > its size. The object is macro driven and may suddenly
> > become something different, or just grow at certain
> > places.
> >
> > Thinking about it, there is no error-proof method of
> > getting the speed from that, is there?
> >
> > Hm. Perhaps I'll need to seperate object and its
> > transformation, and just apply the transformation to
> > a position. This'll give me the possibility of generating
> > the speed...
>
> If the object rotates, changes size or grows at certain points then
> different parts of it will be moving at different speeds, which point do
> you want to measure the speed of?
>
> I assume from what you've written that there is some nominal 'centre' of
> the object which is being translated by different amounts in different
> frames, but that due to the structure of your code this translation
> calculation and its results are inaccessable to your speed calculation.
> Without seeing any code it is difficult to see what the problem is, but
> it sounds as though the calculation that produces the transformation is
> bundled up inside a whole lot of other code in a macro that generates
> the object and positions it. In that case your last paragraph would seem
> to be bang on target, your code is not modular enough, and needs to be
> broken up into smaller logical units. Write a separate macro that does
> nothing but spit out a vector describing the translation of the object
> at a given moment, then call it from both the object generation code and
> the speed calculation.
>

Post a reply to this message

On Fri, 4 Apr 2003 10:32:21 +0200, "Tim Nikias v2.0"
<tim### [at] gmxde> wrote:

>Any other ideas?

About the only thing I can think of is to supply the macro with the
definition of a mesh (not a mesh object, rather an array of vertices
and maybe an array of vertex indices) that will approximate the object
shape for simulation's sake. Providing said mesh definition should be
left as an exercise to the user.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message