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
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|