VR system with nexuiz

[tZork]

Very cool =)

[Strahlemann]

cool
I need those goggles

[aikbix]

Looking good.

[LordHavoc]

i know what your thinking, why would anyone want to do that?
well, my reason is a little long to post here, but basicly, i'm trying to build an affordable VR system by means of a head tracking device. (school project) it would work on any platform that can use joystick, mouse, and keyboard. Nexuiz seems to have all 3. (and is open source if i'm not mistaken)
i've taken a look at the wiki and controls, and it seem that the engine has the capability of rotating the camera (tilt with strafe or death), but how could i control it (or add an control) that is from a mouse axis? (specifically the z axis... which i only found out because directX has a z axis for the mouse for some reason)

so, is this possible?

DirectInput has a Z axis for the mouse wheel, which reads 0 99% of the time, only changing for an instant when it is rolled up/down and then returning to 0, it's quite stupid.

Even more amusingly I read that DX10 has deprecated DirectInput entirely, which I assume means going back to windows input (which isn't bad at all).

In any case, the Nexuiz SDL client joystick code has extensive cvars (joy_ prefix) which can read 6 axes from a joystick device and apply them to movement and rotation, however it expects them all to be continual motion inputs (not an absolute head tracking).

It would be easy to add additional joystick capabilities, such as treating an axis as absolute.

The Nexuiz Windows client joystick code is quite confusing on the other hand, I haven't dared mess with it, I should spend some time rewriting it to mimic the SDL input sometime.

The other clients don't have joystick code.

Mouse input is strictly 2 axis, plus many buttons (mwheelup/mwheeldown come directly from windows messages - it does not use DirectInput, and windows input messages treat mouse wheel roll as button clicks, not as a Z axis).

I would recommend adding 6 additional outputs on the joy_ cvars, specifically joy_axishead* cvars (pitch/yaw/roll/forward/side/up) and sensitivity cvars for the forward/side/up, and then these can be utilized by the view.c code to change the view angles and view location without altering anything else.

No deadzone or sensitivity values should be necessary on the orientation axes mappings, I imagine the pitch/yaw/roll would come in as 16bit unsigned angles (not degrees or radians).

However you might prefer quaternion instead, which would need 3 axes (use an implied negative w component).

[Psychcf]

looks good, just one minor thing...

Nexuiz is an open source version of the Quake1 engine.

that should read "Nexuiz is a game that uses the Darkplaces engine, both being open source." or something like that...

[LordHavoc]

what i need help with is that when i am holding the joystick (virtual or real) at a constant value, the camera jitters like crazy, the further i push it, the more jitter there is.
i've managed to fix some of it by removing code that was found in cl_input.c
(commented out line 400

Code: Select all

cl.viewangles[ROLL] = ANGLEMOD(cl.viewangles[ROLL]);

i also took out the bounding code on line 409

Code: Select all

cl.viewangles[ROLL] = bound(-50, cl.viewangles[ROLL], 50);

and that stopped the jitter when the angle is maxed out
any suggestions?

Hmm, why is it using both ANGLEMOD and bound? They are somewhat hostile toward one another (since ANGLEMOD turns negative numbers into positive ones). Oh I see it also remaps >= 180 roll to become negative, undoing that side effect of ANGLEMOD, which should make the bound work safely.

Okay, I've cleaned up this code some in svn, maybe it will help, maybe not.

[aikbix]

looks good, just one minor thing...

Nexuiz is an open source version of the Quake1 engine.

that should read "Nexuiz is a game that uses the Darkplaces engine, both being open source." or something like that...

It uses an engine based off Quake 1. Though some re-wording would be appropriate.

[Psychcf]

It uses an engine based off Quake 1. Though some re-wording would be appropriate.

but at this point it has nothing to do with quake 1, it's it's own engine really.

[erroneus]

thanks for your replies guys, just another update.
i managed to fix the jitter in the roll by reading the data directly from the joystick SDL.
not too bad considering i can't really program in C what-so-ever (what i've done is basically from a result of reverse engineering)

so i've compiled a new version that reads absolute positional data from the joystick on both roll and pitch, (freeing up the mouse forward axis for possbly walking forward)

i've uploaded my windows binary and my new glovepie code to my website. (along with a better video outlineing the project)
http://joelclemens.colinr.ca/stuff.html

here is the code i used to fix the jitter:
as an example for the pitch i replaced

Code: Select all

cl.viewangles[0] += IN_JoystickGetAxis(joy, joy_axispitch.integer, joy_sensitivitypitch.value, joy_deadzonepitch.value) * cl.realframetime * cl_pitchspeed.value;

with this

Code: Select all

cl.viewangles[0] = (SDL_JoystickGetAxis(joy, joy_axispitch.integer) * 90 / 32767)

in glove pie, i map out the pitch angle from -1 to 1 for -90 to 90 degress, and works quite well. (using this new code, i don't need to worry about anglemod or bound, as it takes care of itself)

oh and i also fixed the wording on my assumption that nexuiz was directly related to the quake 1 engine.

remaining issues that i'm looking for help with is motion tracking, you can see in my latest video that i have a sort-of working prototype of motion tracking, its using the mousewheel on a cordless mouse. i just used the smooth function in glovepie to map it to the joystick for forward motion.

you may ask, why didn't i the now available forward axis of the mouse?
well, using an optical mouse would be great, but i didn't have a way to block the side/lateral axis, so any slight side to side motion screws up the head tracking (because its mapped to the mouse driver)
so i used a ball mouse.... i put some tape on the IR led that was part of the ball tracking, but the ball wouldn't really grip the carpet as well as the mouse wheel.

my original plan was to re-wire the mouse so that the left/right axis is putting data on the mousewheel signal, so i would be able to use the mouse to go left right, forward and backward, but the damn crappy cordless mice i have, (logitech) have some issue where you can't spin the mousewheel and move the mouse at the same time without some lag... i dont have this issue on my corded microsoft mouse.. i guess it might have something to do with wireless bandwidth.

oh, and i got my project featured on hack a day
http://www.hackaday.com/2008/02/09/cheap-360-degree-head-tracking/
since then i've emailed gizmodo, but nothing yet.

i've had a suggestion from the creator of GlovePIE to use a step counter (pedometer) along with the accelerometers to account for direction. i'm considering this, but the problem is the nature of the step counter vs the actual motion i'm trying to achieve.
(it would be easy to wire in the pedometer into a mouse or something and count mouse clicks.. more clicks = higher joystick level = speed increases in game).. this approach would be very laggy i think.

[LordHavoc]

That change to joystick input is incompatible with normal joysticks, because people expect a joystick to rotate smoothly over time, and that does not take into account the varying passage of time each frame.