[Gnu3dkit-discuss] Development Plan Topics - Overview

[Brent Gulanowski]

I've taken the initiative and been presumptuous, whatever you want to 
call it, but here's a list of items for discussion as well as some 
starter points. Some of the material discussed already exists in some 
forms, either implicitly in existing or earlier code, in other messages 
on the mailing lists, and/or in earlier forms of the documentation. 
Please cut and paste or provide exact references as appropriate for 
anything missing.

This is all design and development documentation. It will be used to 
help write the programmer documentation and the headerdoc documentation 
for the API reference. It is not itself meant to be an outline for 
programmer documentation (user guide, tutorial, etc.). Those will come 
later.

I would really like to be able to assemble something semi-official as a 
Development Plan some time in December (2002) when I'm on my break from 
classes, so everybody (anybody) on this list is strongly encouraged to 
offer any input at all in the near term, even "Yea" or "Nay" is helpful 
in some regard. Granted I have no idea how many people that amounts to 
-- could be only three of us for all I know. (I'm writing this all with 
a kind of imaginary audience of ... well, dozens or something. 
Hopefully many more in the future, once we get academic and independent 
game developer user bases. Come on all you GNUstep 3D game developers! 
I know you're out there.)


NOTE
 Consider this message a summary or table of contents for the 
document(s) being proposed. Reply by cutting out particular sections 
and writing individual emails for each. *Please don't reply to this 
message by quoting the entire text.* Choose a single sub-section, and 
please use the sub-section title (or your preferred alternative) as the 
message subject. eg: "Dev Plan II.2.b - Object representation classes", 
or "Dev Plan IV.4. - Development Tools", or even just "Development Plan 
Part Five". We can then use these subjects to guide assembly of the 
documentation into a coherent whole.

Thanks!

-- Brent.

Development Plan: Outline of Major Topics and Sub-topics
Part I - Goals Features
I.1. General Goals and Objectives
a) Objectives: why are we doing this?
- GNU philosophy is good
- OpenStep is good
- GNUstep is therefore doubly good
- 3D graphics are essential to a modern application
- 3D graphics benefits from a good scene graph standard
- Cocoa/GNUstep needs a 3D rendering system which is built according to 
the OpenStep methods and philosophies

b) Goals: With the above in mind, GNU 3DKit is expected to provide:
- a robust and flexible system for managing structured 3D scene data
- a mathematics toolkit appropriate to 3D object and scene management
- an integrated, high-performance, fully-featured renderer
- support for OpenGL acceleration when available on target platforms
- a renderer specification and plug-in model for use with custom 
renderers
- interfaces for extending the system and/or integrating it into custom 
solutions
- a dynamic library binary, suitable for use in commercial 
Cocoa/GNUstep applications

I.2. Feature list
a) no imposed limit on scene size or complexity
b) high speed renderer
c) support for entire OpenGL 1.3 specification in default (scan line) 
renderer [OpenGL 2.0 when finalized by ARB?]
- including Evaluators, Fog, Dynamic Lighting, and heck I don't know 
what got added to 1.3 actually...
- the following OpenGL extensions if supported by the target platform 
[list your favourities -- i.e.: the one's you'll be handling :-)]
d) default renderer can be replaced with custom renderers which follow 
renderer specification
e) [something about RenderMan support -- not my area]
f) comprehensive mathematical toolkit for linear mathematics (vectors, 
matrices)
g) comprehensive library of mathematical object ADTs
h) dynamic LOD for models and terrain
i) muti-threaded: independent rendering and scene update threads (maybe 
more, like separate I/O thread -- implies that any user-interface for 
an app would be yet another thread -- ideally this is all transparent 
to the end-user app developer)
j) bounding box and frustum culling
k) plug-in architecture for additional visibility culling algorithms 
(scene-wide or on particular graph branches)
l) support for multiple monitors
m) scene compilation: ordering of scene elements (objects and/or 
polygons) according to optimal renderer state changes
n) scene flattening: take a branch of the scene graph and reduce it to 
one mesh/array of triangles

far out stuff:
- distributed process model -- renderer can run on different node than 
scene management
-  synchronization of scene cloned on different network nodes 
("multi-player" hehe -- seriously, useful for visualization, too)
- data-based driven, paged scene data
[OK add or subtract as desired/required]

I.3. Non-feature list
We will not be implementing the following [or, please feel free to move 
up to I.2 if you think it's on the timeline]
a) physics simulation
b) particle system (this seems borderline)
c) special input devices (but maybe we should provide a generic control 
input layer?)
d) artificial intelligence, entity behaviours, or agents
e) animation beyond very basic sort of mesh substitution -- no 
kinematics

Part II - Sub-systems (up to and including interface -- Class, 
Protocol, or Category -- specifications, where reasonable)
II.1. Geometry Kit
a) general functions for manipulating and operating on vectors, 
quaternions, other data structures
b) classes to represent Mathematical ADTs:
- tuples
- vectors
- quaternions
- matrices
- lines, splines and planes
- 3D object primitives: box, sphere, cylinder, cone, pyramid, platonic 
solids, and the like
- 3D object composites (CSG operations) [I'm stretching probably...]

II.2. Render Kit
a) a general purpose scene graph node class
- determines visibility of itself and children -- whether or not to 
draw (if culling is active)
- "duplicate" sibling nodes (various reps of same object, see below) 
can choose one of themselves to draw, appropriate to rendering context 
(meant to replace functionality of LOD switch group in v0.3)
b) flexible camera/viewport class -- multiple viewports per scene
c) multiple scene representation types -- primarily two:
- assembled, and
- merged, aka flattened; also
- billboard
- AABB
- OBB, and other approximations are possible
I'd also like
- a textual representation for use as overlay and in 2D data views; 
maybe more?
f) object representation classes (used to produce the representation 
types above)
- raw vertex arrays (separate and interleaved)
- edge list using vertex indices
- triangle list using edge indices
- triangle list using vertex indices
- bezier curve
- bezier patch
- polyline
g) object attribute classes (used to customize or characterize the 
types and classes above)
- material and colour specification
- texture or texture set (for mip-mapping and multi-texture)
- other renderer state specification (anti-aliasing, transparency, 
polygon mode, etc. -- I only know OpenGL, and that barely)
h) static and dynamic lights
i) geometry kit primitive extensions for producing tessellated 
approximations of themselves in above representations
j) importer/exporter back end to convert to/from internal scene format 
-- works with scene reps (or be type of scene rep?)
k) scene archiver/unarchiver for storing scenes in internal format
l) scene archiver/unarchiver for storing scenes in human-readable 
(e.g.: XML) format

[the far out stuff]
m) scene (including sub-scene or branch) flattener
- takes multiple object representations and output a single one; for 
example, to generate approximations for use as "duplicate" sibling node 
for LOD; also, prior to production of visibility divisions
[the general idea here is that a group of objects could be merged, 
exploded, or otherwise re-arranged into a better organization for the 
sake of rendering performance, such as embedding them into a visibility 
structure like a BSP, quadtree or octree, or assessing occlusion 
culling viability, etc.]
n) terrain -- hopefully with dynamic LOD and stuff -- I want to adapt 
lscape (probably be a year or two before that happens)
[add your "To Do" items for RenderKit here!]

Part III - Code Standards
III.1. GNU Standards. Please see: 
http://www.gnu.org/prep/standards_toc.html
[having this already in existence certainly helps a lot]

Part IV - Dependencies and Environment (and limitations)
IV.1. Language
- Objective-C and C

IV.2. Runtime
- Objective-C runtime with Foundation framework

IV.3. Platform (O/S mostly)
- Linux and Mac OS X

IV.4. Development tools
- whatever will handle specifications set out in Part III
- gcc, make, and the like (?)

IV.5. Dependent Libraries
- Foundation framework
- OpenGL (for built-in renderer)
- NSOpenGL* on Mac OS X (I don't know the equivalent or replacement on 
X11)
[probably some kind of image managers for textures -- ideally something 
in GNUstep]

IV.6. File formats (probably none specified)
[something to do with documentation, perhaps]

IV.7.  [insert more dependencies here]

Part V - Construction Plan
V.1. [I'll leave this up to later iterations of this plan]

Appendix A - Patterns
[this is a catch-all for specifying OOP design patterns, if and when 
there are alternatives for solving a certain design problem; we could 
also specify new patterns based on our work, if we create any and want 
to contribute to the pattern library; it's sufficient to provide links 
to where the pattern is described elsewhere.]

Appendix B - Algorithms
[as with patterns, preferred algorithms for solving particular kinds of 
defined data processing problems; links or references are sufficient 
for descriptions.]

[Other useful Appendices? links and resources?]


--
Brent Gulanowski                                address@hidden

http://inkubator.idevgames.com/
Working together to make great software.