dnavigation.cpp File Reference


Classes
struct	playback_t
Defines
#define	MAX_ROTATE_RATE f64(360.0)
#define	MAX_OBJS 10000
#define	LINUX_SCHED_NAV
Functions
	PCENUM_DEFINE (extern, TYPE(InteractionMode),)
void	testRayIntersection2 (void)
	This is just code for testing terrain interaction stuff.
void	nav_init (void)
	Initialize navigation configuration and install Navigation EventQueue handlers (which runs in the EventQueue thread).
channel_t *	navigationOverlay (void)
	XCC_STATIC_C (EHReturn, client_nav_event_handler(const VGIS_Event event, int mouse[2], vgis_boolean_t alreadyHandled, void callback_data))
	This is effectively the main loop of the navigation code when the VGIS application is running as a view client or overview.
	XCC_STATIC_C (EHReturn, server_nav_event_handler(const VGIS_Event event0, int mouse[2], vgis_boolean_t alreadyHandled, void callback_data))
	This is effectively the event handler that implements navigation code when VGIS is running as a view server or as a stand alone view.
	XCC_STATIC_C (EHReturn, server_nav_event_handler_finish(const VGIS_Event event, int mouse[2], vgis_boolean_t alreadyHandled, void callback_data))
void	normalize_weights ()
void	modify_layer (int layer, int multiplier)
Variables
vgis_boolean_t	_logViewPosition = 0
vgis_boolean_t	_logViewPositionOnce = 0
f64_t	flyingTime
volatile int	flyingEnabled
f64_t	flyingSpeed = 1000
vector3d_t	flyingSpeedTrans
vector3d_t	flyingSpeedRot
InteractionMode	interactionMode = ORBIT_MODE
int	_debugMinLevel = 0
vector4d_t	intersection0
vector4d_t	intersection1
volatile char	_debugRayIntersection = 0
volatile char	_debugAdjustDistance = 0
volatile char	_debugUseAdjustDistance = TRUE
volatile char	_debugSkipWOMode = FALSE
char	freeHold = 0
int	markertype = -1
char	texturefile [256]
char	texturepathfile [256]
channel_t *	navigationChannel = NULL
channel_t *	_navigationOverlay = NULL

Detailed Description

Author:: Zachary Wartell

This code handles navigation and some miscellaneous interactions. Unfortunately, due to prior lack of source version control there is some redundancy between the code here and navigation.c. Currently navigation.c is not used at Georgia Tech.

NAVIGATION INTERFACE

On all platforms 'o', 'f' and 'w' switch between Orbit, Fly and Walk modes.

Orbit mode:

Mouse - documented here
Workbench - <not yet documented, see publications>

here

Fly mode:

Mouse - documented here .
Axis Device - (joysticks, spaceballs, etc) documented here .
Workbench - <not yet documented, see publications>

Walk mode: By and large walk mode works like fly mode, except the viewpoint is forced to hug the ground.

Navigation modes can be customized using configuration files discussed here.

Define Documentation

#define LINUX_SCHED_NAV

#define MAX_OBJS 10000

#define MAX_ROTATE_RATE f64(360.0)

Function Documentation

void modify_layer ( int layer,

int multiplier

)

void nav_init ( void )

Initialize navigation configuration and install Navigation EventQueue handlers (which runs in the EventQueue thread).

channel_t* navigationOverlay ( void )

void normalize_weights ( )

PCENUM_DEFINE ( extern ,

TYPE(InteractionMode)

)

void testRayIntersection2 ( void )

This is just code for testing terrain interaction stuff.
Ideally this function probably belongs elsewhere....

XCC_STATIC_C ( EHReturn ,

server_nav_event_handler_finish(const VGIS_Event *event, int mouse[2], vgis_boolean_t alreadyHandled, void *callback_data)

)

mark end of frame for navigation display lists

XCC_STATIC_C ( EHReturn ,

server_nav_event_handler(const VGIS_Event *event0, int mouse[2], vgis_boolean_t alreadyHandled, void *callback_data)

)

This is effectively the event handler that implements navigation code when VGIS is running as a view server or as a stand alone view.
This code runs in the EventQueue handler thread.
Only navigation code code should go here.
Other code for selection, object manipulation, etc., or code specific to other VGIS applications should go in their own event handlers. Only if you need new functionally that truely is navigation functionality (i.e. view manipulation), then consider putting it in here and added called functions and provide a reasonable API for others to use. See [F1].
Footnotes:

[F1] 3/17/04: Long ago, server_nav_event_handler code existed in a navigation thread that was pure navigation. Overtime lots of non-navigation code leaked in the original function and the functions it calls. Things got pretty messy. Zach Wartell started pulling out his hair out and finally added the EventQueue_addHandler function and started modularizing all interaction code. At present, there is still lots of object selection code, GIS query code, and Mobile VGIS stuff, etc. buried in here and, even worse, in the previously purely navigation modules. Such code is slowly being moved out of this event handler and its subfunctions. (Zach Wartell moved all the Weather code outside of navigation library). Please do not add more non-navigation code to this handler and its called functions. Instead start using the EventQueue_addHandler scheme and migrating non-navigation code out of here.

[F2] This is extremely nasty. In order to get maximum functionality in client/server view mode (view_t::network.type == VNC_CLIENT), the view client must pretty much get all the input events over the network from the view server and execute all the standard code with the exception of the fact that a view client changes to the view itself should be ignored and overridden by the view matrices received from the network. This is the only way to insure that at least the view itself is well-synchronzied in a multi-computer view client/server configuration.

There remains the possibility that due to other network and different machines execution speeds, that the two view client computers may get out of sync after arbitrary interactions. The only complete solution is to have a completely distributed scene graph. This is a whole, huge effort that would require pretty much rewritting all of VGIS...

[F3] Super nastiness. We have to be careful not to copy over the .lock because we don't want local_view to effectively reference the same lock as '*view'. (Internally, .lock could be implemented with pointers, etc...hence the danger)

[F5] Using a separate copy also avoids having to lock/unlock the view structure used by the navigation code that runs in the event handler thread. But note, prior to 4/30/06 the navigation classes and code assumed they _were_ messing with the global view_t and hence many of these classes repeatedly lock and unlock the view structure prior to modifying it. Using a copy is a better idea. But right now I don't have time remove all the now unnecssary locks and unlocks from the various navigation class's code.

Todo:
Having changed 'server_nav_event_handler' to use a copy of the global view_t all the lock/unlocks done inside the navigation class's and c modules is unnecessary. They should be removed (see [F5])
Separate all view.log related code into separate API
Deal with possible problems when using playback mode for performance comparisons.

view.log file
The purpose of the view.log file is to record continuous flight paths or sequence of discrete view points that can be later played back. This is especially needed when doing performance tests where you need a reproducable set of view points. The current mechanism has theoretical problems though for this purpose though (see below).
Read view.log:
SHFT-P - (P for "playback") read and process the file 'view.log' from the current directory
Write view.log:
CTRL-SHFT-F5 - append the current view matrix to the view.log followed by 'pause'
SHFT-F5 - toggles the continuous appending of the current view matrix to 'view.log'
In the view.log text file valid lines are:
exit -This causes VGIS to exit pause -This causes the navigation thread to pause at the current viewpoint until
the space key is pressed <float> <float> <float> <float> <float> <float> <float> <float> <float> <float> <float> <float> <float> <float> <float> <float> <float> -First <float> is timestamp. Currently ignored. Remaining 16 floats are view matrix.

Todo:
add display of whether we're recording, in playback mode, etc.
We should probably consider making the view.log be read directly by the render thread to make replays of the flight path more consistent on a frame-by-frame basis. Also we don't use the view point timestamps, how important is this?
return if render thread isn't up and running yet
Initialize nasty static variables...
debugging stuff. Occasionally, various bugs manifest themselves by generating NaN's in view matrix. This code just trys to help catch these cases
make local copy of view for manipulation by this code (see [F2] & [F5])
open Display Lists for 3D navigation cues and widgets
get time change
handle optional local_view point logging
Alter render LOD behavior to best suit current navigation mode.
--This is deprecated by any paged object databases later than version 2_0 but I'm too chicken to remove it quite yet.
(Original LOD behavior is found in lod.c:tlod_evaluate_obj revision 1.8.)
compute tracked handheld cursors
handle events
ALL the following XXXX_handler calls and many of their subfunctions should be moved outside of this function into other libraries. (see [F1])
debugging trick (should move this somewhere else...)
handle automatic mode switching
handle mode switch
execute current mode
send view data, etc. to clients
get view data, etc. from server
perform hacked up thread scheduling stuff...
for the momment I keep this nasty stuff in this function. Ideally it should be moved to the EventQueue thread loop. This is only a modularity issue. I'll try to do this soon.
Do NOT try copying this stuff to other Event Handlers. They all run in one thread so it's enough to have this junk here..
update global view 'view' with all parts of local view that were changed by all the above event handler code...

XCC_STATIC_C ( EHReturn ,

client_nav_event_handler(const VGIS_Event *event, int mouse[2], vgis_boolean_t alreadyHandled,void *callback_data)

)

This is effectively the main loop of the navigation code when the VGIS application is running as a view client or overview.
This code runs in the EventQueue handler thread.
get view client data
compute tracked handheld cursors