Z
Ô
I
O
N

Erlkönig: Z (ζῷον)

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.

Beyond the desktop

[zland trees with tiny leaves] 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. :-)



Current Status

2004-12-29 C++ N-Tree[trapezoidal] Class

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") )));
(Read past status entries.)
zme - prototype viewing client, working in local mode, Spaceball 4000 FLX support

Manipulating an object with a XGLTEX X server mapped onto it.
[X server in an OpenGL texture]

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 - An OpenGL program with a realtime X display as a texture - (code)

xvfbtex showing the xgltex server buffer mapped onto a rectangle
and a roaming sphere; Heretic is running and playable.
[xvfbtex display of xgltex X server as OpenGL texture]

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.
[rippling, usable X server with Rikku as background]

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)

xgltex - X server rendering into an OpenGL texture format framebuffer - (code tree, xgltex subdir, notes)

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.
[X server in an OpenGL texture]

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

glsperm - 2002-06-07 - Floating tadpoles (spermatoza, actually) with illumination

[glsperm screenshot] 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

radius3d - watch RADIUS logins across the earth's surface

[picture of earth wit numerous small spheres] 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.

zland2 - full terminal and remote apps in 3d space

[zland with a translucent teletype] 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.

zland - basic terminal and remote apps in 3d space

[zland with an early teletype implementation] 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.

glutproto

[numerous spheres with tails floating about] 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.

gluttool

[numerous spheres floating about] 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.

zglyphs

[a formation of octahedrons, text widget, and billboard] 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.

trees - fractal trees in SGI GL

[a rather harshly geometric, mostly stalk, tree] A GL fractal trees program, my first fresh experiment with 3D graphics, with viewpoint control, fog, and control of the level of detail.

spaceball - hardware

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 [mine's actually a dark racing green Jaguar special edition] 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 ; ) &

Z - the zone server

Protocol is in development for communications with zme and other zclients.

soundd

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

Implementation Notes

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.


Related Research




contact ζωιον