Some projects which need to happen in order for Solace to become a useful
platform for things other than eyecandy (posted for the benefit of other people
at NMSU who want to work with me on Solace):
- Windowing abstraction - Right now, Solace's API expects X11. Making
an abstraction layer for the windowing system similar to the current
abstraction layer for the rendering system would be a good thing, since then
Solace could be ported to platforms such as video game consoles, exotic
graphics workstations, handheld devices, and maybe even Microsoft Windows.
- Geometry image modeler - Solace uses geometry images (basically a
parameterized patch) for its mesh representation. Although algorithms exist
for converting traditional polygonal meshes to geometry images, they all
produce less-than-stellar results, which also run into major issues with
scalability, resolution, and artifacting. I feel that certain properties of
geometry images may lend themselves well to writing a modeler which will also
have the nifty side-effect of being much easier to work with than traditional
3D modeling systems
- Algorithmic improvements - Currently only distance-based isotropic
mesh sampling is supported. View-dependent anisotropic mesh filtering would be
easy to implement, if only I could think of a way to parameterize the filtering
equation.
- Animation/physics engine - I have ideas on how to use behavioral
modeling and rigid-body physics simulation to make objects move without
explicit keyframing or other labor-intensive processes.
- Server and network transport - The primary goal of Solace is to make
a large-scale online community using a MUCK-like user-scriptable server, which
could then be used for a number of graphics applications. It would work with
the animation/physics engine to provide semantic, action-oriented information
(for example, 'character Bob walks to the table' once rather than 'character
Bob takes a step to this coordinate' ten times a second). This really entails
three separate-but-related portions: the game server needs to maintain state,
the network transport needs to establish the protocol in which this state is
published, and the game client needs to interpret the protocol and send out
appropriate messages.
- Vertex shaders, and improved shader flexibility - Right now the
pixel shader architecture is primitive-based (and not hardware-friendly) and
the vertex shaders are nonexistent. Extending the render pipeline to support
hardware pixel shaders, and using the concepts to support both primitive-based
and hardware vertex shaders, would make Solace much more future-proof and
platform-independent.
- Documentation/release - Solace does no good if all it exists as is a
chunk of code on my hard drive. I need to come up with licensing terms which
are beneficial to both me and any programmers who might want to actually use
Solace in their own projects or products. And, in event of engine release,
it'd be nice to have some documentation as well.