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 (or joystick)? (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?

edit: this thread has evolved beyond that of rotating the camera with mouse, see newer posts

you mean like in older FPS games? I'm sure it's possible, but I dunno.

Fortunately, such will be easier that camera tilting is fairly trivial; and stereo GL projection is already supported.

Unfortunately, as Nexuiz uses OpenGL, you'll have to code in such support for [1] Determining the pitch, yaw, and roll of such head tracking device [2a] Mapping such movements towards cursor/joystick movement & acceleration OR [2b] Directly translating such movement in Darkplaces to camera movement.

well i guess it couldn't hurt to provide a little more info as to what i'm doing

i'm using a program called GlovePIE to remap devices onto other devices, so i could use a joystick or such to controll a mouse etc..
in this specific project, i started with a wiimote, but since the wiimote cannot detect yaw, i'm migrating towards the PS3 sixaxis controller.
i've already created a script that converts the angle of pitch into mouse movment that results in looking up or down.
it is actually quite simple, i can do the same with yaw once i get a ps3 controller, tilt/rotation can be controlled this way too, however i couldn't find any console commands or variables that would allow for direct camera controll with the mouse.

any tips on where i could start if i wanted to add my own?

There's support for a cvar called joy_axisroll in vid_sdl.c, but all references are commented out.

thanks! not sure what i can do, but its a start!

This sounds like it could get interesting. Please keep us updated.

edit: http://www.cs.cmu.edu/~johnny/projects/wii/

well, i wasn't able to get the view to rotate with the mouse, but once i figured out how to compile into a binary, it was pretty easy to remove the // and get the code to work, i modified it a bit, so that holding the joystick position will determin the roll position, (i removed a + and increased sensitivity) problem is though that it is really shakey at the extremes.
other than that, i just have to work on my glovepie script a bit more.

i want to build a map that makes the user cross over an abyss via narrow beam. (using the vr helm) i have to come up with a way to track walking motion from the user and put that into the game. accelerometers could work, but the math involved is a little difficult for me.

I have a quick demo of what i have been able to do so far, but there is one thing that i hope i can get help with.

on line 293 of vid_sdl.c i changed the code from

Code: Select all

cl.viewangles[2]   += IN_Joysti........
to
cl.viewangles[2]   = IN_Joysti...........

also there was a speed variable at the end of the line that i commented out because it gave me a declaration error when compiling, (i replaced it with an arbitrary number of 200)
anyways, i took out the + so that the view angle would corispond with the position of the joystick (and therefor the positon of the ps3 controller)

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?

it may help you to know what i'm doing with the VR stuff
if you are a little confused, i've published what i'm doing on my website, i have a video of my customized nexiuz in action too!

http://joelclemens.colinr.ca/stuff.html

Nice man, looking real good.

Very cool =)

cool
I need those goggles

Looking good.

erroneus wrote: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).

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...

erroneus wrote: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.

[TSA] Psychcf wrote: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.

phandentium wrote: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.

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.

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.

well, my project is finished, though wireless couldn't be finished on time, it is still successful.
check it out here
http://joelclemens.colinr.ca/thesis

thanks for all your help, i couldn't have done it without this forum.
-joel

Congratulations !
That's a really great project . I love what you've done there. Must feel really cool to walk around like that
I think the biggest problem with all these approaches on virtual realities is still the fact that walking around in the virtual environment very often doesn't conform to the movement in the real environment. Means: You'll walk against walls.
I've seen some funny devices which take care of this problem, but they're all in it's infancy.
This is one of my favorites:

This one's also a crazy thing, but poorly useable imo (telling from the vid): http://www.youtube.com/watch?v=EvkubXHilk0
But hey: it works.

I hope you'll stay involved in VR-research.
Great stuff !

Looks really cool man, I wish your videos would show an example of stepping off the beam though. I can't imagine how that would make your feel inside.

I see the VR Head Display is roughly $80, what was the total cost of the project?

Strahlemann, that is ridiculously cool.


P.S. For those who stumble, help out -> http://www.stumbleupon.com/submit?url=h ... ca/thesis/