Tasks
From Yage3D Wiki
These tasks are more isolated and would be easier to implement for someone less familiar with the engine. They're arranged in no particular order.
Contents |
[edit] Terrain Support
Yage currently has some commented-out terrain support (scene/terrain.d) that hasn't been kept up-to-date with changes in the engine. There's also scene/graph.d which allows creating a grid from an xyz function. It would be good to have terrain support with these features:
- Can be loaded from a heightmap, created from a function, or the combined result of both. Creating it from a function would allow for terrain with overhangs or even generating spheres (planets) and other shapes. It could even be used to dynamically generate waves in water.
- GeoMipmapping -- blocks of terrain are tested against the Camera's view frustum before rendering, and distant ones are swapped out for lower-polygon versions.
- Multiple blended textures -- there's a way to do this without shaders by using vertex color values to chose between up to four different textures.
- Vegetation maps -- low resolution grayscale images can be used (along with a 3d model) to control where vegetation/rocks/etc. appear on the terrain.
[edit] Lense Flar Node
Renders a lense flare when visible. It accepts an array of materials and an array of distances to control what's rendered for the flare effect.
[edit] Decals
The ability to render bullet holes, explosion marks, etc. on an existing Geometry. Research needs to be done to determine the best API for doing this.
[edit] Model LOD
It would be nice if Models could automatically generate lower-polygon versions of themselves to be rendered at greater distances. This can potentially be hard to implement.
[edit] A New Windowing System
Yage currently uses SDL for creating a rendering windows on Windows and Linux, but it suffers from the following limitations:
- Switching from windowed to fullscreen mode is buggy, sometimes the OpenGL context must be recreated which involves reloading all resources.
- Resizing sometimes messes up the rendering area.
- Only one window can be created.
- Input can only be accepted in the same thread that performs rendering.
Switching away from SDL would involve these tasks:
- Creating new windowing code for Windows and Linux (and eventually Mac). It would be good if an OpenGL context could be created on engine initialization without creating a (visible?) window, then any subsequently created windows would share that same context.
- Input would need to be rewritten to not use SDL.
- NeHe's first OpenGL tutorials have Linux and Mac ports and would be a good place to look for windowing / input code.
Note: dsfml might become your friend: http://www.sfml-dev.org/ It's very easy to use and modularly organized.
You need to use the sfml2 svn branch though: http://sfml.svn.sourceforge.net/viewvc/sfml/branches/sfml2/
[edit] Picking
Implement Camera.getNodesAtCoordinate() so clicking can select objects in 3d space.
[edit] UI Controls
See yage.gui.controls for a list of possible GUI controls and some of their members/functionality. These are open to ideas for improvement.
[edit] libavcodec
Yage currently uses libvorbis to support ogg vorbis decoding and sdl_image for image loading.
- libavcodec is faster at decoding vorbis audio files than libvorbis. See here.
- libavcodec supports a dizzying array of both audio and video formats, it's what allows vlc to support almost everything.
- libavcodec is actively developed.
- This would reduce the number of dll's used by Yage (ogg.dll, vorbis.dll, vorbisfile.dll, sdl_image.dll, jpeg.dll, libpng12-0.dll, zlib1.dll) to a single libavcoded.dll which is also more likely to already exist on Linux systems.
- Derelict users would probably love having access to libavcodecs functions in d, so derelictization would be nice.
- This code shows how to use libavcodec with OpenAL.
