VRML - want to slow rotation speed in EXAMINE mode

Author

want to slow rotation speed in EXAMINE mode

John Andrews

2006-02-07, 11:41 pm

'morning,

You gotta admit: CosmoPlayer is an excellent piece of work. I've
been testing my work on the three C's (cosmo, contact, cortona) and
cosmo--5+ years old?--is still, hands down, my far-and-away
favorite. for my stuff, anyhow. Easier navigation, much crisper
textured images over surfaces, don't have to futz with graphics settings
after installing.

I do have the following problem with Cosmo, however- rotation
speeds. The software was written for slower clock speeds, i guess, so
when i pull up a model--large ones, with 200,000+ polygons--the thing
often spins out of control if i'm not careful. In fact, when i rotate
or translate a model, i have to be careful to hold it steady for a split
second before releasing the mouse button, otherwise it will spin, and
very, very fast.

How can i change this/slow it down? ("speed" in the NavigationInfo
node only affects zooming (and maybe translation, i forget) but
definitely not rotation). Any suggestions welcome.

see

http://www.beg.XXXXXX.edu/coastal/wrl/w2005.htm

for an index of example. I've got some really cool HUD and widget
stuff, by the way.

john

Russ

2006-02-07, 11:41 pm

hi John,
Instead of using "examine", what about trying a SphereSensor to rotate
the geometry with a button to enable it off and on?
Btw your example works fine in my five year old system.

>The software was written for slower clock speeds
Old WorldView has the same problem on my much older system.
"slow" speed is equivalent to "very fast"
tc
Russ

John Andrews

2006-02-07, 11:41 pm

Russ wrote:

> hi John,
> Instead of using "examine", what about trying a SphereSensor to rotate
> the geometry with a button to enable it off and on?
> Btw your example works fine in my five year old system.
>
> Old WorldView has the same problem on my much older system.
> "slow" speed is equivalent to "very fast"
> tc
> Russ

thanks for the suggestion, Russ. I'd thought of this, but I don't think
it's an option: I've as many as 100 separate data layers in some of my
projects, and attaching SphereSensors to all of these layers (each layer
an individual EPROTOs) wouldn't be practical. Besides, many of the
layers already have other Sensors attached, so I think I'd start running
into sensor-heirarchy issues. ...oh, wait- you're probably thinking
of having a single, large (all-encompassing) object that when rotated
would send its rotation info to all of the objects. OK, i see- then be
able to turn it off to access the other layers' Sensors. Well, i guess
this would work, but it's kinda cumbersome- having to turn the thing
on/off, plus I'd hafta go back and edit all the EPROTOs to be able to
accept the SphereSensor eventOuts, plus re-do all my Viewpoints (instead
of camera moving, the objects would move/rotate). Perhaps this is how i
should have done it from the get-go, but to do so now would involve alot
of backtrack...

Other ideas?

Russ

2006-02-07, 11:41 pm

er- simple. One Transform Node around everything -all Proto instances,
Viewpoints and Geometry.
Anything you want to rotate. Thinking about it, besides the button to
turn the SphereSensor on and off,
it might be good to have a reset button back to 0 1 0 0.
If you want the user to be able to do any exploring, it might be
necessary to put the Navigation at "FLY"
"WALK" from the rotated viewpoints may wreck havoc with Cosmo's sense
of gravity.

# VRML V2.0 utf8
# First list all ExternalPrototypes you want to reference.

# Then your HUD
# Now the main world
Group {
children [
DEF Sphs SphereSensor {}
DEF Tr Transform {
children[
# All your Viewpoints, Geometry, ExternalProto instances go here
]}
]}
ROUTE Sphs.rotation_changed TO Tr.set_rotation

John Andrews

2006-02-07, 11:41 pm

Russ wrote:

> er- simple. One Transform Node around everything -all Proto instances,
> Viewpoints and Geometry.
> Anything you want to rotate. Thinking about it, besides the button to
> turn the SphereSensor on and off,
> it might be good to have a reset button back to 0 1 0 0.
> If you want the user to be able to do any exploring, it might be
> necessary to put the Navigation at "FLY"
> "WALK" from the rotated viewpoints may wreck havoc with Cosmo's sense
> of gravity.
>
> # VRML V2.0 utf8
> # First list all ExternalPrototypes you want to reference.
>
> # Then your HUD
> # Now the main world
> Group {
> children [
> DEF Sphs SphereSensor {}
> DEF Tr Transform {
> children[
> # All your Viewpoints, Geometry, ExternalProto instances go here
> ]}
> ]}
> ROUTE Sphs.rotation_changed TO Tr.set_rotation

well, there you go, Russ- making a molehill out of a mountain. heh,
yeah, i guess I was over-complicating the task at hand a bit. sorry you
had to spell it out for me.

I still don't think, however, this method will work for me (as before,
please correct me if I'm wrong or missing something here.) First- with
the Sphere Sensor, there's no way to zoom into or translate the models.
and Second- the issue of having to de-activate/activate the SphereSensor
to access lower-level Sensors is a bit cumbersome. I could look over
#2, however, especially if there was some way to control the
SphereSensor's rotation axis.

What I'm thinking here: instead of having 2 modes (SphereSensor either
on/off), I could have 3:

-SphereSensor on, TS off
-TouchSensor on, SS off
-neither on

so, I could add a TouchSensor at the same level of the SphereSensor.
When the TouchSensor is turned on, its hitPoint_changed eventOut sends
(on mouseOver) the coordinates of the mouse to a Text node to report
coordinates (just for the heck of it/nice feature); with a leftClick,
however, the hitPoint_changed coordinates are then stored in a field.
When the SphereSensor is re-activated (and TouchSensor turned off), the
rotation axis coordinates of the SphereSensor would become the
coordinates stored in the field by the TouchSensor. That would be cool.
[and there'd still be the option of turning off *both* sensors to access
the lower level sensors.) All this is predicated on 2 things, though:

1. can you somehow designate the rotation axis coordinates of a
SphereSensor? (i don't see it listed as an evenIn) ...or maybe these
hitPoint_changed coordinates would be fed into the Tranform node the
SphereSensor is acting on?
2. oh, and then my original complaint: in SphereSensor mode, do you
simply have to live with the fact that you cannot zoom and translate? I
think this would be a deal killer: with no zoom/translate in
SphereSensor mode, i just don't see this working.

sorry this is so long. thanks to Russ and al. for considering it.

john