1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
===========================================================================
TODO for 3Dwm -- http://www.3dwm.org
Copyright (c) 2000, 2001 Niklas Elmqvist. All rights reserved.
File created 2000-02-11 by Niklas Elmqvist <elm@3dwm.org>.
File History:
2001-08-28 Minor revision for 0.3.1.
2001-08-16 Minor revision for 0.3.0.
2001-06-10 Minor revision for version 0.2.4.
2001-05-02 Minor revision for version 0.2.3.
2001-04-01 Added server-side animation, particle systems, etc.
2000-11-03 Minor revision for version 0.2.2.
2000-09-20 Major revision for version 0.2.1.
2000-02-12 File created for 3Dwm version 0.1.
===========================================================================
The current incarnation of 3Dwm is merely a prototype of things to
come; there is a lot of things planned for the continued development
of the 3Dwm user environment. Here follows a rough outline of some of
the most important things that (probably) will need to be added to the
system in the future.
NOTE! Please, please understand that this is NOT a list on what's on
the plate for the core developers, this is a *wishlist* of some of the
functionality we would like to see being added to 3Dwm. In other
words, anything on this list is fair game for implementation by
anyone, so just say the word on the mailing list and then go ahead and
implement it!
* CAVE rendering. Can we use CAVELib here, or do we have to use SGI
Performer? VRCO, the makers of CAVELib (http://www.vrco.com), has
promised a multi-threaded version of CAVELib, that will make things
easier.
* Font support. Both normal, scalable 2D fonts (TrueType with
FreeType?) as well as 3D vector fonts. A good starting point would
be GLTT at gltt.sourceforge.net.
* 3D sound support. Possibly using the proposed OpenAL (Audio
Library), but also with the capability to use specialized hardware
(like the Lake sound system). This should be encapsulated in a
module of its own.
* Unicode support. Do we need this?
* Documentation. Hacking guidelines, client programmer manual.
* Distributed garbage collection. Tricky issue, we should probably
associate objects with the client that created them. When the
client crashes, the objects can be reclaimed. Recommend we do this
by having a POA for each client.
* Define the event graph/event propagation scheme.
Model/View/Controller.
* View frustrum culling. This should be reasonably simple to
implement once we have a working bounding volume hierarchy as part
of the scene graph.
* Level-of-detail rendering(?). At least static, dynamic may not be
useful.
* Big texture splitting moved to client code. The big texture support
allows 3Dwm to use large textures on hardware that only supports
256x256 textures (like the 3dfx Voodoo 3). However, this code
breaks several interfaces in the server, and should be improved.
* Static geometry (as opposed to procedural geometry) should be put
inside OpenGL compiled vertex arrays (CVAs) for optimum
performance.
* Multitexturing support.
* Optimization and refactoring. Large areas of the code have
stagnated and need massive cleanup.
* 3D widget kit.
* Transparency. It would be useful to be able to define geometries to
have transparent primitives.
* Server-side animation system. We need this to cut down on network
traffic so that the client doesn't have to animate stuff on its
own, but can rather depend on the server to do it for them. What
kind of an animation system do we use? Keyframe-based? Something
even more advanced, like bones and inverse kinematics?
* Particle systems. Very useful special F/X feature that could add
more power to the display server. Needs to be very general so that
it can be used for all kinds of particle systems. Keeping this on
the server side is also good for keeping network traffic
down. Should probably be turned into a plugin.
* Plugin system. Need to define the plugin system, handler and plugin
interface (which should be standardized and used to create a
KitFactory). All non-essential parts of the system should be
migrated into plugins to give more flexibility and
configurability. Look into the possibilities of doing capability
querying in clients to check the capabilities of the display server
used.
* Platform abstraction and platform implementations. We need support
for as many different hardware platforms as possible (GGI, Win32,
DirectFB, CAVELib, etc). 3Dwm is all about bridging different
hardware platforms, like desktop machines, HMDs, and even CAVEs, so
this is essential.
* Rendering API abstraction. 3Dwm should support multiple rendering
APIs, including OpenGL, OSMesa (for software emulation) and
Direct3D in Win32 environments.
* Client-side support libraries. We need support libraries for
different programming languages. There is currently a C++ support
library (Nobel++), but it would be useful to have support for Java,
Python, C, etc, as well.
|
