Difference between revisions of "Q3osc"
From CCRMA Wiki
m (→media) |
|||
| Line 2: | Line 2: | ||
'''q3osc''' is a heavily modified version of the ioquake3 gaming engine featuring an integrated oscpack implementation of Open Sound Control for bi-directional communication between a game server and a multi-channel ChucK audio server. By leveraging ioquake3’s robust physics engine and multiplayer network code with oscpack’s fully-featured OSC specification, game clients and previously unintelligent in-game weapon projectiles can be repurposed as behavior-driven independent OSC-emitting virtual sound-sources spatialized within a multi-channel audio environment for real-time networked performance. | '''q3osc''' is a heavily modified version of the ioquake3 gaming engine featuring an integrated oscpack implementation of Open Sound Control for bi-directional communication between a game server and a multi-channel ChucK audio server. By leveraging ioquake3’s robust physics engine and multiplayer network code with oscpack’s fully-featured OSC specification, game clients and previously unintelligent in-game weapon projectiles can be repurposed as behavior-driven independent OSC-emitting virtual sound-sources spatialized within a multi-channel audio environment for real-time networked performance. | ||
| − | q3osc is an update of the manner in which the quake3 gaming engine can be used to export player locations and entity movements and actions outside of the q3 server via OSC. While q3osc is working from a fresh [http://ioquake3.org/ ioquake3] codebase, the inspiration came from pix + delire's excellent [http:// | + | q3osc is an update of the manner in which the quake3 gaming engine can be used to export player locations and entity movements and actions outside of the q3 server via OSC. While q3osc is working from a fresh [http://ioquake3.org/ ioquake3] codebase, the inspiration came from pix + delire's excellent [http://julianoliver.com/q3apd Q3APD] project, which unfortunately makes use of the string-based [http://en.wikipedia.org/wiki/FUDI FUDI] protocol instead of a more flexible proper [http://www.cnmat.berkeley.edu/OpenSoundControl/ OSC] protocol. |
After using Q3APD for the 8-channel work [http://ccrma.stanford.edu/~rob/220c maps & legends], it became apparent that while the mod was great, the idea could be improved and further explored, especially in terms of using OSC instead of FUDI, additional player gestures and data-points being exported from quake3 to an external audio engine. Since Q3APD used the string-based FUDI UDP implementation, rather than a full-blown standards-based OSC implementation, only PD could reasonably be used as the recipient of Q3APD outgoing data-streams. Since there are other excellent languages to be used, osc is a better choice. | After using Q3APD for the 8-channel work [http://ccrma.stanford.edu/~rob/220c maps & legends], it became apparent that while the mod was great, the idea could be improved and further explored, especially in terms of using OSC instead of FUDI, additional player gestures and data-points being exported from quake3 to an external audio engine. Since Q3APD used the string-based FUDI UDP implementation, rather than a full-blown standards-based OSC implementation, only PD could reasonably be used as the recipient of Q3APD outgoing data-streams. Since there are other excellent languages to be used, osc is a better choice. | ||
| Line 376: | Line 376: | ||
[http://ccrma.stanford.edu/~rob ~rob]<br /> | [http://ccrma.stanford.edu/~rob ~rob]<br /> | ||
[http://www.audiomulch.com/~rossb/code/oscpack/ oscpack]<br /> | [http://www.audiomulch.com/~rossb/code/oscpack/ oscpack]<br /> | ||
| − | [http:// | + | [http://julianoliver.com/q3apd Julian Oliver's q3apd]<br /> |
[http://ccrma.stanford.edu/~rob/220c original project page]<br /> | [http://ccrma.stanford.edu/~rob/220c original project page]<br /> | ||
[http://www.chatbear.com/unity2/6079/78,1198798504,2104/1065824/0#1 ChatBear thread 1]<br> | [http://www.chatbear.com/unity2/6079/78,1198798504,2104/1065824/0#1 ChatBear thread 1]<br> | ||
Revision as of 10:23, 3 February 2008
q3osc is a heavily modified version of the ioquake3 gaming engine featuring an integrated oscpack implementation of Open Sound Control for bi-directional communication between a game server and a multi-channel ChucK audio server. By leveraging ioquake3’s robust physics engine and multiplayer network code with oscpack’s fully-featured OSC specification, game clients and previously unintelligent in-game weapon projectiles can be repurposed as behavior-driven independent OSC-emitting virtual sound-sources spatialized within a multi-channel audio environment for real-time networked performance.
q3osc is an update of the manner in which the quake3 gaming engine can be used to export player locations and entity movements and actions outside of the q3 server via OSC. While q3osc is working from a fresh ioquake3 codebase, the inspiration came from pix + delire's excellent Q3APD project, which unfortunately makes use of the string-based FUDI protocol instead of a more flexible proper OSC protocol.
After using Q3APD for the 8-channel work maps & legends, it became apparent that while the mod was great, the idea could be improved and further explored, especially in terms of using OSC instead of FUDI, additional player gestures and data-points being exported from quake3 to an external audio engine. Since Q3APD used the string-based FUDI UDP implementation, rather than a full-blown standards-based OSC implementation, only PD could reasonably be used as the recipient of Q3APD outgoing data-streams. Since there are other excellent languages to be used, osc is a better choice.
With q3osc, the goal is to use a fully-featured OSC implementation like oscpack to not only recreate the basic user-coordinate tracking from Q3APD, but to also expand the scope of usable in-game parameters to include missle objects and other actionable items and events in the game world. Using OSC, we can implement audio engines built in any osc-capable audio software, such as ChucK, Max/MSP, SuperCollider or PD.
By adding behavioral controls to in-game entities like plasma and bfg-bolts (both of which have interesting visual attributes), visual in-game behaviors like bouncing and attraction/homing both to self and other in-game entities, we can create audio gestures which tightly follow the visual gestures.
Contents
media
- demo movie: q3osc-demo1.mov (~340mb) [no-sound]
- random screenshots: ~rob/q3osc/images (.tga, .jpg)
current status
feature list
|
|
enhancements
dedicated server support
OSC input functionality
assignable clientID projectile tracking
individual control of projectiles (speed, xyz)
changeable color for each user for plasma and bfg
update history
1/30/08
- interesting to note, all modification made on weapon entities seems to be handled entirely on the server side, to such an extent that a clean default installation of OpenArena on a ppc Mac can interface perfectly with the server running q3osc-tweaked code. Wow. It just got even easier.
1/28/08
- seems like upper-bound on renderable projectiles on the screen at any given time is ~253, tracked via new object ids sent via osc to ChucK. Projectile IDs start at 73, not 0.
1/27/08
- modified durations on CG_BubbleTrail le->endTime to extend bubbles... funny looking but mostly useless... eats up alot of entities.
- increased MAX_ENTITIES in tr_types.h from 1023 to 100000; not sure how this is affecting things, may be more complicated.
1/26/08
- modified cg_weapons.c to turn on "bubble trails" for certain weapons
- added g_parent_homing_only flag to make homing projectiles only follow parent (bind j homingparentonly)
1/25/08
- created q3osc.ck ChucK main processes/class-models
- made "/<classname" descriptor for each osc projectile message and "/player" for osc client messages.
1/24/08
- added sendOSCmessage and sendOSCbundle switched by osc_bundle boolean
- added cg_plasma_trail_length to cg_local.h et al.
1/21/08
- added osc_bundle checks to determine whether bundles or single multi-field osc messages are sent
- split sendOSCMessage_projectile into sendOSCmessage_projectile... and sendOSCbundle_projectile... using osc_bundle boolean as switch between methods
- added methods and check for boolean into g_missile code
1/20/08
- added first demo movie: q3osc-demo1.mov (~340mb)
1/20/08
- using cg_oldPlasma 0
1/19/08
- added g_plasma_persist, and g_homing_persist and used in checks on G_HomingMissle to trigger expiration of all typed entities
- added g_plasma_homing_persist, g_bfg_homing_persist and logic track them in G_HomingMissle
- added bindable "plasmahomingpersist", "bfghomingpersist"
1/18/08
- added osc_send_projectile, osc_send_client booleans to turn on and off osc output
- added g_bfg_persist flag: 1 postpones ent->nextthink so bfgs don't explode... when flag is set to 0, then after g_bfg_time G_ExplodeMissile will be called and all bfg entites bouncing around will explode/go away
1/16/08
- added g_homing_radius
- recorded video demo of homing balls
- /record balls1
- /stoprecord
- /demo balls1
- /video (converts to .avi from demo format)
1/13/08
- Added insane g_parent_homing flag to allow projectiles to home on their parent client. This can create great spheres of entites revolving around the client when g_homing_speed in set just so.
1/11/08
- Running q3osc with client data output as bundles to one IP/Port while projectile data is routed to its own IP/Port. Homing and bounce are triggered by client variables, so each client can decide for him/herself whether or not homing/bounce are enabled.
1/09/08
- Ludicrous bouncing/homing enabled for Plasma and BFG projectiles. Added g_homing_speed, g_plasma_speed, g_rocket_speed cvars. Added g_plasma_bounce (taken from q3apd)
- g_synchronousClients 1 : synchronizes client messages but purportedly makes playability more difficult... will see.
1/08/08
- missle tracking working; need to isolate individual gentity_t id's for each rocket, as well as target ids (this can probably be gleaned from the radius reference)
- osc bundle output working: needed to "#define OSC_HOST_LITTLE_ENDIAN 1" in OscHistEndianness.h (oscpack) for linux system. Will need to re-set this for Windows compilation.
- Osc output console variables "/osc_hostname" and "/osc_port" are working. Currently designing and implementing osc namespace.
1/03/08
- osc output from test.cpp using oscpack compiled into ioquake3 engine successfull using homing rocket as trigger. Now moving on to isolate good params for export including the methods used in q3apd plus new goodies.
12/29/07
- initial linking success with test.cpp, thanks to ge's sweet sweet compiler flags:
$(B)/baseq3/qagame$(ARCH).$(SHLIBEXT) : $(Q3GOBJ) $(CC) $(SHLIBLDFLAGS) -lstdc++ -o $@ $(Q3GOBJ)
$(B)/baseq3/cgame$(ARCH).$(SHLIBEXT) : $(Q3GOBJ) $(CC) $(SHLIBLDFLAGS) -lstdc++ -o $@ $(Q3GOBJ)
DO_CPP=$(CPP) $(BASE_CPPFLAGS) $(SHLIBCFLAGS) -o $@ -c $<
12/07
- uber-beta floundering; while test .cpp classes are compiling correctly, something is going screwy in the linking process, which causes qagamei386.so to fail on the foo method call (see below)
Loading dll file qagame. Sys_LoadDll(/user/r/rob/data/q3/dev/ccrma-kdevelop/build/release-linux-i386/ccrma/qagamei386.so)... Sys_LoadDll(/user/r/rob/data/q3/dev/ccrma-kdevelop/build/release-linux-i386/ccrma/qagamei386.so) failed: "Failed loading /user/r/rob/data/q3/dev/ccrma-kdevelop/build/release-linux-i386/ccrma/qagamei386.so: /user/r/rob/data/q3/dev/ccrma-kdevelop/build/release-linux-i386/ccrma/qagamei386.so: undefined symbol: foo"
references
dev shortcuts
rm -rf ccrma && mv baseq3 ccrma && ./ioquake3.i386 +set sv_pure 0 +set fs_game ccrma +devmap space +set vm_ui 0 +set vm_cgame 0 +set vm_game 0 +set cg_draw2d 0 +set cg_drawGun 0
~/.openarena/ccrma/screenshots
/cg_thirdPerson (0/1; default: 0) /cg_thirdPersonAngle (0-360; default: 0) /cg_thirdPersonRange (default: 40)
/r_mode -1 /r_customheight 1021 /r_customwidth 1672 /vid_restart
r_ext_texture_filter_anisotropic 4 r_flares 1 cg_shadows 2 r_stencilBits 8 r_detailTextures 1
/com_blood 0
things to think about
- Bi-directional communication: ChucK <--> ioq3
- VideoTrace
- head-tracking with wiimote as lean-controller?
- another homing missle approach
- l3dgeWorld
- Stanford's Jeremy Bailenson VR
- virtual world resources
- SARC Sonic Lab
- q3 on PocketPC
- Q3ce Google Code page
- Q4 SDK
- OpenArena Message Boards
- Serious Games Summit
- Phoronix: Linux & Solaris Hardware site
- Kandinsky: "Point and line to plane"
bundle data: 1/13/08
196 byte message: 23 (#) 62 (b) 75 (u) 6e (n) 64 (d) 6c (l) 65 (e) 0 () 0 () 0 () 0 () 0 () 0 () 0 () 0 () 1 () 0 () 0 () 0 () 18 () 2f (/) 63 (c) 6c (l) 61 (a) 73 (s) 73 (s) 6e (n) 61 (a) 6d (m) 65 (e) 0 () 0 () 2c (,) 73 (s) 0 () 0 () 70 (p) 6c (l) 61 (a) 73 (s) 6d (m) 61 (a) 0 () 0 () 0 () 0 () 0 () 18 () 2f (/) 70 (p) 72 (r) 6f (o) 6a (j) 65 (e) 63 (c) 74 (t) 69 (i) 6c (l) 65 (e) 6e (n) 75 (u) 6d (m) 0 () 0 () 2c (,) 69 (i) 0 () 0 () 0 () 0 () 0 () 54 (T) 0 () 0 () 0 () 1c () 2f (/) 6f (o) 72 (r) 69 (i) 67 (g) 69 (i) 6e (n) 0 () 2c (,) 66 (f) 66 (f) 66 (f) 0 () 0 () 0 () 0 () 42 (B) ffffffcc (?) f () ffffffaa (?) 45 (E) 1f () 6e (n) 0 () ffffffc5 (?) 11 () ffffffdd (?) ffffffd0 (?) 0 () 0 () 0 () 14 () 2f (/) 6f (o) 77 (w) 6e (n) 65 (e) 72 (r) 6e (n) 75 (u) 6d (m) 0 () 0 () 0 () 2c (,) 69 (i) 0 () 0 () 0 () 0 () 0 () 0 () 0 () 0 () 0 () 14 () 2f (/) 74 (t) 61 (a) 72 (r) 67 (g) 65 (e) 74 (t) 6e (n) 75 (u) 6d (m) 0 () 0 () 2c (,) 69 (i) 0 () 0 () 0 () 0 () 0 () 37 (7) 0 () 0 () 0 () 10 () 2f (/) 62 (b) 6f (o) 75 (u) 6e (n) 63 (c) 65 (e) 0 () 2c (,) 69 (i) 0 () 0 () 0 () 0 () 0 () 1 () 0 () 0 () 0 () 14 () 2f (/) 65 (e) 78 (x) 70 (p) 6c (l) 6f (o) 64 (d) 65 (e) 0 () 0 () 0 () 0 () 2c (,) 69 (i) 0 () 0 () 0 () 0 () 0 () 0 ()
[ 000000001 /classname "plasma" /projectilenum 84 /origin 102.030594 2550.875000 -2333.863281 /ownernum 0 /targetnum 55 /bounce 1 /explode 0
