This is Interesting: Free Magazines for Graphics designers and webmasters  


Home > Archive > VRML > February 2004 > Speed camera in VRML?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Speed camera in VRML?
Jane Williams

2004-02-07, 6:28 am

I'm coming back to VRML coding after a long break, and finding I'm
more rusty than I'd hoped :(

I'm trying to measure the speed at whch the avatar is moving through
my world, and link it to a visual indicator (the transparency of an
object, should that matter).

Is there a nice convenient Property somewhere I can link to?

Or do I have to set up sensors and timers and do Sums? (And if so, any
hints on how?)

Yes, the reply-to email has been slightly munged.
Turn words to numbers where obvious
Muaddib

2004-02-07, 8:29 am

Jane,
I don't know any ready made protos or Properties for doing what you
are trying to do. Here is how I would go about it:
Set up a proximity sensor that encompases the entire area in which
you wish to test for user's speed. Route the position_changed events to
a script that always records the last position it received. Handle
the position_changed event in the script by adding to a sum, the
magnitude of the difference between the new position and the old. Every
event is also accomponied by a firing time. Use the old and new firing
times for the time difference. Divide and route out your speed. This
might be too quick, you might want to skip a couple events.

I guess this could be the proto you are looking for:
PROTO SpeedCalculator [
eventIn SFVec3f currentPosition
eventOut SFFloat32 speed
] { ... }
ROUTE proximitySensor.position_changed TO speedCalculator.currentPosition

As far as using this info for transparency, if you imagine a "max speed"
then you could send out instead a number between 0 and 1 by dividing and
route this to the transparency field. I would suggest instead a
function like this for transparency = speed / ( speed + c ). Here if
speed = c, then transparency = 1/2, if it is twice, then tran = 2/3, etc...

Muaddib


--
-------------------------------------------------------
VRSpace - An open source, 3D, modular, cross-platform,
multi-user system with persistent shared objects.
Check out a demo at http://www.vrspace.org/demo.htm
-------------------------------------------------------

Jane Williams

2004-02-07, 3:30 pm

On Sat, 07 Feb 2004 06:25:09 -0500, Muaddib <rob_nospam@vrspace.org>
wrote:

> I don't know any ready made protos or Properties for doing what you
>are trying to do.


(sigh) I was afraid of that.

> Set up a proximity sensor that encompases the entire area in which
>you wish to test for user's speed. Route the position_changed events to
> a script that always records the last position it received. Handle
>the position_changed event in the script by adding to a sum, the
>magnitude of the difference between the new position and the old. Every
>event is also accomponied by a firing time. Use the old and new firing
>times for the time difference. Divide and route out your speed.


Thanks, that was roughly what I had in mind. Glad to know I wasn't too
far out.

> This might be too quick, you might want to skip a couple events.


And that I *hadn't* thought of. Good idea.

>I guess this could be the proto you are looking for:
>PROTO SpeedCalculator [
> eventIn SFVec3f currentPosition
> eventOut SFFloat32 speed
>] { ... }
>ROUTE proximitySensor.position_changed TO speedCalculator.currentPosition


Looks like the one: thanks!

>As far as using this info for transparency, if you imagine a "max speed"
>then you could send out instead a number between 0 and 1 by dividing and
>route this to the transparency field. I would suggest instead a
>function like this for transparency = speed / ( speed + c ). Here if
>speed = c, then transparency = 1/2, if it is twice, then tran = 2/3, etc...


Hmm, good point. I've got no way of predicting a maximum speed, have
I? I'll have to take a look at that sort of algorithm.

The idea is that they're travelling down a tunnel. When they're
stationary, it's opaque. As they speed up, the walls become more and
more transparent and they can see the scenery flashing past. But when
they slow down for a better look, it opaques again. (Yes, there is
good reason for this, but I'd have to tell you pages of role-playing
history to explain it.)

Yes, the reply-to email has been slightly munged.
Turn words to numbers where obvious
Sponsored Links


Copyright 2003 - 2008 forum4designers.com  Software forum  Computer Hardware reviews