6DOF Quake1

[Hypersonic]

I always wanted to try 6dof with fast turns and selectable fov, and just recently I got that chance!

I detailed all the changes I made, hoping that this could be adopted by other source ports.
I have a working example applying these edits to the fitzquake_plus source port.
https://sites.google.com/site/quakeconfig/6dof-quake

Here are some key values it uses.
If any of these defines conflicts with what other mods or source ports use, they can be changed.

#define MOVETYPE_SIXDOF 12 // similar to WALK, but like Descent

There can only be one movetype set at a time, So there's a problem when you want to 6dof and noclip simultaneously.
When getting out of noclip it checks this bit-flag

#define FL_SIXDOF 8192

To know whether to go back to 6dof or walk after noclipping.

Perhaps I should just drop the MOVETYPE_SIXDOF, and just modify MOVETYPE_WALK to check for the FL_SIXDOF flag?

For the client side there's sixdof.
sixdof 0 means 2dof rotations (roll always zero, yaw is around world-z, pitch is around self-x)
sixdof 1 means 3dof rotations (yaw, pitch, roll are all self relative, like in Descent)
The qc mod sends a stuffcmd to switch this.

Please let me know what you think!

[Baker]

[ame=http://www.youtube.com/watch?v=djb-KVxcih4]vertical circle strafe.ogv - YouTube[/ame]

[ame]http://www.youtube.com/watch?v=w8aUI9flEvc[/ame]

Hmmm ...

[golden_boy]

Looks very interesting for mods. Also for adding something like a helicopter or a zero-G vehicle of sorts.

It looks like noclip in real 3D, and there seems to be no gravity anymore for the player. From what I see in the video.

Hm. Impressive work, but I'll have to meditate a bit longer to find possible uses within the game Quake (which sort of assumes that there is gravity, both for the monsters/players and also in architecture).

[Bloodshot]

Could be used for a "Vehicle" segment in a custom level/episode maybe, like an anti-gravity miner or something.

Or could be used to remake descent with a good base engine and the nice DP effects.

[R00k]

Looks cool! I kinda got dizzy watching that video, i kept tilting my head trying to right-side up the view. Add a small drift when turning maybe bouncing off walls.

edit: I just had an idea for a 3d marble game like this...

[=peg=]

Reminds me of Descent

[Baker]

I've always thought some mod where you could have anti-grav boots and camp on the ceiling would be cool.

Would add some suspense to some sort of survival Team DM mod.

[And I've been getting real about 3D math lately. v_forward, v_right, v_up are easy enough. But I get a bit of a headache when I try to add pitch, yaw, roll to that (and Quake engine source code does not help with that, since those are not factors in navigation). Will have to look at Hypersonic's engine source to see how that works. ]

Discussion at Inside3D about this kind of stuff a couple of years ago: http://forums.inside3d.com/viewtopic.php?f=3&t=1999

[talisa]

definitely looks interesting, and its a revolutionair mod, didnt think something like that would be possible in quake.

although the idea of flying around in quake like that doesnt appeal to me and i cant really see what it could be used for, beside vehicles.
but personally i dont think vehicles fit in quake, lol

but still nonetheless its brilliant of Hypersonic that he managed to do something like this with quake

[Chip]

There was a level in Crysis, when you entered the alien ship, and gravity was 0. You started to float around and turn and spin, and you had to find a way to deactivate some force fields and make your way through. Remember?

Is there a way to move the C functions to QC and make them level dependent? So, if level is my-zero-gravity-level-here, then apply the QC functions.

[golden_boy]

Indeed, that alien ship level was really cool.

The environment and enemies would have to be built around the idea. Same for vehicles.

[Hypersonic]

From golden_boy
"... gravity, both for the monsters/players and also in architecture"
Setting gravity independently for each entity would be cool! Right now gravity is automatically setup to turn off with MOVETYPE_SIXDOF.
Maybe gravity could be temporarily reduced allowing high jumps with some cool Matrix style 6dof acrobatics while shooting!
I wonder if per client gravity could be implemented using the existing network protocol.

@ Bloodshot
Or a mod Quake vs Descent, with on team consisting of Pyro-GXs from Descent, the other team Quake dudes!
Equate one unit of shield with one unit of health, and allow Pyro-GXs to 'wear armors'!
Have energy centers around. Maybe enforce a turn speed limit on the ships.
Colored lighting would be nice, like in the 6dof video game Forsaken.

From R00k
"Add a small drift when turning maybe bouncing off walls."

I was thinking of adding rotational velocity for a more realistic and smooth feel.
Although having input directly translated to velocity is the quickest way to aim, just like regular Quake's aiming.
Maybe I could have a user setting, if they want instant control over rotational velocity, or add in an inertia setting.
I do have rotational inertia in my 3dmouse-Google earth script https://sites.google.com/site/hypers...eearth-3dmouse
I do want to had wall bounce as an option, become a pinball in a 3D pinball machine!

@ Baker
I just recently figured out how to get 6dof working in my 3dmouse-Google Earth script.
In the file quake6dof.c you'll notice I just adapted the code from my previous Javascript.
I know Quake has all these sub-functions, but I just converted to GE coordinates to use my original code, seemed easier to do at the time.
It seems to work OK. There is an issue of accumulated approximation errors though I wrote about on the bottom of this page:
https://sites.google.com/site/quakec...ees-of-freedom

@ splitterface
Thanks for the comment! Flying is made easy with a 3dmouse, it's quite intuitive.

From Chip
"Is there a way to move the C functions to QC and make them level dependent?"

You can already alter the MOVETYPE_SIXDOF and FL_SIXDOF flags in QC for each client at anytime (not just at player spawning)
The QC mod can be made to read info from the map.
Perhaps a huge invisible bounding box could be made indicating zones in which you can fly within.
Perhaps outside of a spaceship you can fly 6dof, astronauts in space with jetpacks. Then inside you run and jump.



It's still an early stage, with feedback I am hoping to improve the interface.
Right now I'm thinking I should drop MOVETYPE_SIXDOF, and instead just use FL_SIXDOF.
It works using existing network/demo protocols, but client input and physics for the server and client prediction need to be altered.
It hasn't yet been tested in multiplayer, the player models probably look really weird in various orientations!

I want to be able to tilt over the bounding boxes, the code seems to be fixed in that it assumes they are always upright cuboids.

I use a 6dof 3Dmouse to control it, but I made mouse-left-right be roll because of a limitation in my 3dmouse driver.
I should have 2dmouse axis mapping so you could use a 2Dmouse and bind buttons to +rollleft and +rollright to control as well.

Thanks for all the feedback, I hope that this could be used somehow, perhaps opening up new types of gameplay.

[Baker]

In the file quake6dof.c you'll notice I just adapted the code from my previous Javascript.

... There is an issue of accumulated approximation errors though I wrote about on the bottom of this page:

I'll have to look at that

My own experience kind of went down like this:

[Spike]

by the way, movetype=12 is already movetype_follow.
I've my reservations about creating a new movetype for it, it means that you can't have movetype_fly+6dof for instance, which would perhaps be more practical than noclip in a real mod.

bboxes don't rotate, correct. there's quite a few issues with doing so - including having to check against other entities every time something that rotates and being prepared to undo the rotation if it gets stuck.
q1 bsps are particuarly problematic. there's only a set number of bbox sizes that can correctly collide with the world. there's nothing you can do except clipping against the faces themselves - which drops all support for clip brushes and makes corners nasty. While many engines can rotate bsp objects, such rotations also rotate the bbox too!
Q3 bsps allow arbitary sizes and could support bbox collisions of any size, but if the interaction is not axially aligned, you're pretty much stuck with the bbox needing to expand in order to contain the corners - note that capsual traces could work fine, if you have a way to define the two points of the capsule.

I would expect that descent used only sphere interactions, instead of bboxes. Using spheres instead of bboxes means that there's absolutely no effect upon collisions based upon angles.
It should be 'easy' to edit qbsp to expand brush faces uniformly instead of different lengths based upon axis, while modding the engine to check ent vs ent using a sphere probably requires the most code, but is logically straight forward in itself.
The issues come when you want to retain compatibility.

[Scotto]

This is static gravity, not dynamic - for real functionality it will need to be written (if possible) like what the id tech 4 engine is capable of doing for games like Prey etc...

[bluntz]

I'll have to look at that

My own experience kind of went down like this:

ROTFLMFAO!!!
Agreed
I got dizzy just reading this thread!