| Z | Ô | I | O | N |
Z, The Z Project: (from greek ζῷον, “zoion” creature pronounced 「ゾイアン」 or “zoh-yawn”). n, A research project intended to invert the relationship between two-dimensional and three-dimensional applications in the current desktop paradigm in human-computer interfaces. The Z paradigm supports the use of legacy two-dimensional applications within a shared three-dimensional spatial environment. Moreover, the Z environment itself is network-sharable, supporting multiple distributed users and discretionary access permissions, providing a common context for both professional collaboration, shared gaming, and private tasks.
The ΖΩΙΟΝ project is my personal research into spatial environments.
Currently only some of the experiments are public, since the rest
is still undergoing design churn.
:-)
Currently entangled in the process of writing an STL-like NTree class. It's a bit frustrating that although there are reasonable overviews of writing STL extensions, it seems to be nearly impossible to dig up a good canonical example upon which to base a new template. Grrr. Regardless of the trauma factor however, moving the implementation of the Zones' tree structures into a generic class allows the mechanism to be tested in relative isolation, which is clearly worthwhile.
Part of the quirkiness of the implementation I'm working has to do with the search for LISP-like tree instantiation. With some clever use of + and an auxilliary class, one should be able to generate reasonably efficient code for creating trees with code similar to that used for static initializations. In the example below, copies are made of the original nodes by the + and / operators, with this floating copy, once linked together, assigned to the tree.
It doesn't help, of course, that C++ wants all the happy temporaries in such an expression to be constant, dramatically interfering with the whole goal of linking them without generating gobs of sub-copies.
typedef NtreeNode_t<std::string> N;
N tree = (N("a1") / (N("b1") / (N("c1") +
N("c2") ) +
N("b2") / (N("d1") +
N("d2") )));
Currently about 13,000 lines of C++ (and additional bits of gmake, lisp, perl, sh, and the zop/zys scene languages), zme has been rewritten from scratch using a new, hierarchic model from the zone proto-server, and using an increasing amount of threading. It renders objects read in from external .zop files and maintains them in a frame-of-reference hierarchy, which can be edited interactively in some (as yet limited) ways and then saved in its entirety back to disk. The viewpoint is also an object in the FoR, and the nested transforms of both it and the other objects can be manipulated. Basic object highlighting is used to indicate the current manipulation focus.
My favorite bugs so far have been the 4MB/s memory leak(!), and the teleporting sheep bug (a matrix stack overrun), both of which have been fixed,
Textures and full support for the Spaceball 4000 FLX have been added. Motion of the viewer is now intuitive (despite the continued evasion of quaternians), but manipulation of a non-viewer object still happens in its frame of reference rather than in that of the viewer. A control to swap viewer and focus object is present to mitigate this for now.
xvfbtex showing the xgltex server buffer mapped onto a rectangle
and a roaming sphere; Heretic is running and playable.
To go with the xgltex X server, I wrote a program to map the X screen onto an object as a texture in a basic GLUT program. However, GLUT immediately revealed itself as the usual albatross, and had to be removed to allow for use of XTest or XSendEvent. It uses GL_LIGHT0 to illuminate the X screen - an oddly jarring effect, since it's never happened to a real X server in my experience until now. This is actually the seventh program in a series, each more divergent from the GGI program from which I began.
xvfbtex showing the xgltex server buffer mapped onto a rippling
X screen, with fully usable xterm, fvwm2, and mozilla.
2005-01-09: Pointer tracking now works on the moving sphere as well, allowing full use of X via the sphere's surface just as well as through the rippling X screen behind it. Of course, stopping the ball first eases interaction significantly. This version is being used as a basis for doing some factoring on the unproject code.
2004-01-22: Pointer tracking for arbitrarily rotated and scaled surfaces now works, including for complex surfaces with computed or animated z-axis variation, such as sinusoidal variation in z. A initial class-encapsulated model allowing for full variation along x, y, and z is in progress.
2003-04-20: This demo now supports keyboard, mouse, and button input. However, the code is still a an uncharacteristic mishmash of C, C++, and GLUT-derived style (ie: too many globals).
(initial implementation 2002-06-07 - 2002-06-15 - 6 programs)
I've written a prototype X server using a memory-based framebuffer compatible with OpenGL textures, which uses shared memory to provide the framebuffer as a texturable image for OpenGL clients. Loading the texture itself frequently generates quite a bit of traffic to the GPU, since the GPU can't use the shared memory directly (ah, I miss the concept of an SGI with Unified Memory Architecture), but even a 1024x1024x32 screen works surprising well. The other formats, particularly the monochrome bitmap, still need work. The name could be improved as well, I think...
Xserver in GL texture with Xeyes as the eyes, fvwm2 and
the X worms(1) program running on its back in zme.
xgltex started out as XGGI from the GGI project, an impressive work that does any number of neat things. One of its best points is its generality, but for my tightly-targeted purpose, this came at too much of a cost due to the numerous extra levels of data copying and conversion involved. So, to achieve the kind of refresh rate I wanted without having to work in very low resolution X screens, I forked off a separate server dedicated to rendering into texture-compatible framebuffers.
XGGI itself looks to have been derived from the XVFB (Virtual Frame Buffer) X server, which I had also explored early on. The latter would have had a decided theoretical advantage over XGGI due to its being part of the standard distribution, since having to compile both GGI and XGGI tends to put off new users. Unfortunately, after any number of differently command line options and the associated amusing framebuffer layout clashes, porting an X server to my own nefarious ends looked easier than trying to use any existing one.
My intent is to arrange for a special Xatom to be available on screens supporting the shared memory attachment, and to allow the client to request the shmid (see shmat()) directly from the X server. By removing the need to track the shmid separately, references to X servers in textures can be a URL-style string in a form resembling: xserver://DISPLAY/shmem This URL-like approach is key to integrating X screen into the Z texture methodology, both for its textual simplicity and even more so for the advantages of the lasting value of the URL form over the transient and unpredicable nature of the shmid's themselves.
The framebuffer format itself, as represented in the shared memory segment (currently just the image data) could soon have a header or footer as well, allowing the OpenGL program to dig up all the remaining detail on the visual format from the header. This removes the need to bury screen dimensions, depth, and format information, etc., in the URL, an obvious advantage. On the other hand, the same could be achieved by making the information available from the X server shared-memory-screen property, potentially even simpler once I figure out how to set the Xatom values inside the server code instead of just creating empty ones.
Another promising possible use for some additional framebuffer data would be optimization information for which scanlines need to be updated. Adding a vector of height sequence ids corresponding to the XGLTEX servers scanlines could allow quick determination of screen subsegments for update, by simple comparison with the client's memory of the last sequence number it saw on the prior update.
(initial implementation 2002-06-13 - 2002-06-15
Appearing in retrospect to be a completely crazed reimplementation
of the worm screensaver to OpenGL,
this program sports about 100 little wrigglers,
some equipped with illuminating antennae that activate
(non-simultaneously) during dusk and deactivate during dawn
in the internal, one-minute long solar cycle.
Up to 8 light sources are used at once, with very nice glow halos
around each. The effect is particularly profound in the darkest
period, when only those critters within the spheres of illumination
are easily visible.
(initial implementation 2002-06-04 - 2002-06-07
Are you an national or global ISP? I wrote a quick hack to
display the earth in 3d, complete with indicators across the surface
indicating where RADIUS-based users are logging in, in realtime.
Uses the incoming areacodes and translates them to longitude,
latitude, and altitude using a database. Spheres over specific
areacodes grow in proportion to the (approx) cube root of the traffic,
and decay to minimum diameter over a 15 minutes period.
The planet can be rotated and zoomed in realtime.
Run on a huge projector display in our NOCC, it gives a good feel
for the login habits in different geographic areas.
Terminals now have translucent, texture-mapped backgrounds.
A PERL client was written which can connect to zland2 via a socket
and control a matrix of squares within the space, using it as a
display for a life cellular automaton, as seen in
this picture.
Further development on zland2 has ceased in favor of the zme program.
Earlier versions of the program also had tty capability, but the focus
to control them was a separate, black-and-text input target
- a legacy from the
original terminal concept implemented as a simple text window with
a surrounding control brace in the zglyphs program.
A variant of gluttool with more complex objects,
in this case little spermatozoa-like things with their tails
(composed of little tetrahedrons) trailing behind them.
A rewrite-from-scratch to experiment with the GLUT tookit,
resulting in the realization that GLUT isn't suitable for serious work.
Lots of wiggling spheres inside of a textured globe,
with the word "Center" floating at, predictably, the center.
The zglyphs program, with
animated texture maps on the octahedrons.
a bracket-like text widget with vector-based text,
texture-mapped terrain with reasonable lighting,
and a floating billboard with a somewhat
racy image (if you're a large, sea-dwelling mammal)
image of two orcas.
A GL fractal trees program,
my first fresh experiment with 3D graphics,
with viewpoint control, fog, and control of the level of detail.
For those of you wanting to use a Spaceball 4000 FLX under Linux, mine
works wonderfully, except for the small detail that the joystick driver
under RedHat linux is a royal pain to make work with it (worse now than
in 2001, when it couldn't even reliably recognize a 4000 FLX despite
the fact that it responds predictably to a number of queries and
setting options), and integrating it into Xinput is yet another dire
area. However, just as I was about to start writing my own interface
I discovered a related Sourceforge project named
libsball
along with their
homepage,
which definitely had a lot to offer in terms of protocol handling in
more than just one type of spaceball.
Nevertheless, I eventually ended up finishing my own application-level (and currently specific to the spaceball 4000 FLX) library, in order to integrate better with C++ and produce full, typed C++ spaceball events, an incoming event queue, and xyz coördinates in right-handed OpenGL-style. Unfortunately, hoped-for support for a ~/.spaceball file and per-axis user-configurable tuning have not yet materialized, and integration with the Xinput extension isn't included, with the excuse that the objective is, after all, to replace X :-)
I've made the alpha level C++ spaceball module available for download.
If you're still trying to use the pitiful linux joystick driver
(with regards to the spaceball, that is) and
jsattach, which apparently can only identify a 4000 FLX during startup
and even then not reliably, I once found the following shell fragment
helpful in establishish the initial connection,
after which you can use jstest to see if it's really working.
Be sure to insmod for input, serio, serport, spaceball first.
( while ! jsattach --sball4 /dev/ttyS0 ; do : ; done ; ) &
Protocol is in development for communications with zme and other zclients.
A sound server, as though there weren't already enough, functional until the incept of an incomplete assault on distance delay and doppler effect in sheep .
I'm still curious about how to close and reopen the X connection for OpenGL use without mysteriously crashing in glXCreateContext. (Feel like debugging? Take a look at the testcode sample , a structure-flattened C++ regression test-in-progress).
The program zland2 was implemented in GNU C. Z and zme are being implemented in C++v3 compiler, originally with Mesa 3.2 and a 3dfx Voodoo3 3000 card (and more recently with an NVidia subsytem, despite the slower framerate at 1600x1200, which just isn't worth it on the NVidia. Perhaps the new Matrox will do better?)
Although moving to C++ helps in some ways, I already miss GNU C's local functions (an issue which neither namespaces nor macros really addresses), and there are numerous other grumbles I'll spare you from.
The Virtual Object System (VOS) is a hierachical distributed object system, a dessert topping, and a floor wax. It is an infrastructure for object-oriented network communication, and building flexible, distributed object networks for a variety of purposes, but mainly multiuser collaborative virtual environments. It also tastes good and will keep your floors shiny.The VOS idea of objects having context-carrying links to other objects without constraint to the main tree is intriguing (and more open-ended than Z's action-acquisition menu request), as is their codifying of matrix transform data as generic properties where Z instead currently (2003-10) considers such information as special. The VOS approach would simplify the addition of properties, although there might be issues in implementing the Z permission concept under an open property paradigm rather than as an intrinsic part of the Zone code.
| contact ζωιον |