PublicVR Forum

Online discussions of everything having to do with PublicVR, especially current projects, tech support, educational practice and theory. See http://publicvr.org for basic information and send questions to jeff@publicvr.org
It is currently Sat Feb 24, 2018 6:54 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: CaveUT-Cursor
Unread postPosted: Sun Jul 20, 2008 12:18 am 
Offline

Joined: Tue May 27, 2008 11:29 pm
Posts: 558
CaveUT-Cursor would be a separate package or mutator, dependent on CaveUT-CORE. It would give an error message or not load or just do nothing if CaveUT-CORE is not installed. See the description of the cursor in the function reference at http://forum.publicvr.info/viewtopic.php?f=13&t=11. The CaveUT-Cursor mutator would look in CaveUT.ini for these parameters:

    EngineFOV=90.000000
    ViewRoll=0.000000
    ViewPitch=0.000000
    ViewYaw=0.000000

It's own config file would be CaveUT-Cursor.ini which would have:

    EnableCursor=True
    ShowCursor=True
    CursorSize=1.0
    CursorDefaultColor=(B=255,G=255,R=255,A=255)
    CursorSamplingRate=0.2 ;; Times per second the targeting vector is calculated.
    ShowRollovers=True ;; Cursor changes color when targeting vector intersects a targeting volume
    CursorActiveColor=(B=0,G=255,R=0,A=255) ;; Cursor color when targeting vector intersects a targeting volume


Top
 Profile  
 
 Post subject: Re: CaveUT-Cursor
Unread postPosted: Tue Jul 22, 2008 2:14 pm 
Offline

Joined: Tue May 27, 2008 11:29 pm
Posts: 558
I am thinking a radically different approach to the cursor. At the moment, I favor creating a three-dimensional cursor that appears "in" the virtual space. It would actually be drawn after the virtual scene is drawn, ignoring Z-buffering, just like the gun in the normal game. We would draw the cursor on/in/upon the unit sphere surrounding the user's viewpoint. Then, targeting is easy to calculate and we don't have to have any awareness of where the client screens are.

With a magnetic tracker, you don't need the cursor to be drawn at all. Your tracker provides the targeting vector, so all we need to do is calculate when it intersects a trigger volume. if you want something to show up on the screen, putting a laser pointer on the user's pointer/magic-wand/rifle would actually look better than the cursor. The only thing you would miss is the cursor color change when it is over an active object.

The cursor remains useful for lower-end controllers like the mouse, where you can't get a one-to-one movement to targeting mapping. In terms of the screen, having the cursor move along the inside of a virtual sphere might look a little odd for a flat-walled CAVE-like. It depends on how 3-D cursor actually looks. If we do it right, the cursor really will appear to move in 3-D space. Of course, this will be perfect for any kind of partial dome display.

The only downside is that the cursor is likely to disappear, if the user runs it off the end of the screen. We have to decide whether that's okay, or if we need to read the clients' screen extents to stop the cursor at the border. I would recommend the former.

Thoughts?


Top
 Profile  
 
 Post subject: Re: CaveUT-Cursor
Unread postPosted: Tue Jul 29, 2008 10:56 pm 
Offline

Joined: Tue May 27, 2008 11:29 pm
Posts: 558
We will keep the cross screen cursor as part of the core functionality for CaveUT, however it will be rather simpler. For example effects like "change color upon rollover" will be application specific.

Rather than keep our own targeting code, Max will look at ways to use the main firing mechanism built in to UT2004. Essentially, this will allow the user to face in one direction and fire and other. Not only will this be more efficient, it will greatly simplify applications programming. For example, in applications where the user is supposed to "click on" an object to activate it, the applications programmer only needs to tell the object what to do when it gets shot. With a variety of weapons modes built into the game, the application programmer could provide the user with more than one way to activate an object

Example: In the Virtual Egyptian Temple object-clicking and keystrokes and the only user input. We can program that is an entirely independent ut2004 level, which should function with or without CaveUT. Example: The user could simply play a regular ut2004 game in a CaveUT cave.

The cursor itself will be a 3-D static mesh drawn on a unit sphere, centered on the user's location. (In CaveUT, the user's viewpoint is always a "master" client, while additional views are provided by spectator based "slave" clients. See viewtopic.php?f=13&t=40 for more details.) The cursor will be drawn after the virtual scene is rendered, ignoring Z-buffering. The effect will be that the cursor is always visible, just like the gun in UT2004.

There will be a cross-screen cursor for each master client, controllable by the user. Because the cursor is on a sphere around his viewpoint, it will only appear on his master view and on spectators attached to his viewpoint.

In CaveUT.ini, and the CaveUT settings menu, we will have four parameters, CursorMaxLeft, CursorMaxRight, CursorMaxTop, and CursorMaxBottom, which take real numbers. Each one is the maximum number of degrees the cursor is allowed to travel along the sphere. For example, if CursorMaxLeft=90, it means that the cross screen cursor cannot go beyond 90 to the left of the master client's view vector. This prevents the user from pointing pass the extents of the composite display. Initially, the user will have to set these boundaries manually. We will then write a configurator program which will calculate default values for these extents by looking at the parameters for VRGL. Of course, we will have a flag which allows the user to turn off this limitation -- there are some applications where one really does want to be able to point off the edge of the composite display.

We will provide some method for the user to make their own cursors. Each one would be a textured static mesh, and the user should be able to select between them in CaveUT.ini and possibly the CaveUT settings menu. the cursor will also have the visibility toggle. There are some applications, where the user will not want the cursor to the visible.


Top
 Profile  
 
 Post subject: Re: CaveUT-Cursor
Unread postPosted: Tue Jul 29, 2008 11:02 pm 
Offline

Joined: Tue May 27, 2008 11:29 pm
Posts: 558
Question: is it possible to separate movement direction from facing direction? In an immersive display, people want to be able to point the controller in a direction, and have been scene move in that direction. Otherwise, they can only move forward in a direction and of the master-client's view, which is counterintuitive. This would be very helpful for the Egypt tours, for example. (See http://publicvr.org/html/ins_earththeater.html)

If this could be done, then we would have facing, movement, and firing all independent of each other. Actually, the user should be able to bind any two or all three, depending on their personal preference and the demands of the application.

Max, can this be done?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group