Now we've got WW3D up and running with the skeleton app. Here is a somewhat more detailed/organized list of what is left to do: LIMITATIONS/POTENTIAL PROBLEMS: - Skins need to use a limited set of rendering features? - Polys going into the alpha system must use a limited set of rendering features. - Additional procedural material passes cannot be applied to alpha blended meshes (no multi-pass alpha) - Meshes only get two vertex color arrays. Their vertex materials must be configured properly to enable them. - HY: Simplescene supports only four global lights - HY: WW3D Spoltlights have an approximate inverse linear attentuation instead of max linear attentuation UPDATED TODO LIST: agg_def: - Texture replacement feature needs to be implemented assetmgr: - Texture cache, - Dazzle loader, bmp2d - works. Code for setting aspect ratio was added but not used due to legacy - HY boxrobj - Alpha blending support needed - Vis rendering code needed camera - *** CameraClass projection convention changed to -1Apply() and the state is being tracked by the shader class. Materials have been converted to Material->Apply() which calls Mapper->Apply() Now, some big issues we need to think about are (in no particular order): SOME GOALS - Maintain as many existing class interfaces as we can so that our apps don't have much re-coding! Input data is existing W3D files, no format changes or new tools! (for now anyway :-) Incorporate the ideas in Jani's DX8 code, grouping small meshes together in larger VBs, etc GERD Replacement - our new low-level rendering interface needs to be the replacement for everywhere we are using the GERD. It needs to supply all of the features that we are using in the GERD currently while allowing us to use Jani's mesh optimizations. There is a lot to think about here and almost everything depends on us doing this right. It also might need to serve as an abstraction layer so that I can implement a software VIS-renderer behind it. SOLUTION: No GERD replacement, no abstraction layer. DX8Wrapper will be a thin insulation layer though. VIS - I'll have to re-implement the rendering code for VIS. It will be a 32bit, solid fill, zbuffering software rasterizer. Not too hard but still a bit of work. Needs to be done in a way that all render objects can be rendered through it easily. SOLUTION: Vis rendering will branch at the render object level to a new custom vis rasterizer possibly based on the bw shadow code TEXTURES - there are many features in the textures system, the "file cache", background loading, LOD, tga loading, global texture reduction factor, etc. SOLUTION: Naty is working on this system. MESHMODEL - I think we'll need to do some load-time conversion of all of our mesh-models into a form similar to Jani's dx8 mesh code. More thought needs to be put into this. ALPHA SORTING - This issue becomes especially complex when you think about mixing different types of render objects. This issue will influence how we design the low level rendering interface. SOLUTION: There will be a custom alpha sorting/rendering system. RenderObjects will be allowed to talk to either DX8 or this system. UNIX - It looks like Neal has put some effort into making ww3d compile under Unix. We will probably make life very difficult for him if there are DX8 calls all over the place :-) SOLUTION: UNIX version of E&B will not use WW3D2. It only needs collision detection so we'll implement a custom solution. Optimizations: ============== * Currently we search a linear list for textures with the same name every time we ask the asset manager for a new texture. We should probably use the hashtable template for this instead. * The VectorProcessorClass stuff is completely unoptimized - we might want to optimize this in future. ********* NEW STUFF ************ DX8 Features which we currently do not support and might want to in future: * Different modes than clamp and wrap - DX8 exposes all kinds of cool modes like mirror, mirror once - do we expose these in our tools? How well are they supported in hardware? If they are not universally supported then we probably don't want to expose them... * Cube and volume textures - support via inheriting from shared base class with TextureClass? * Anisotropic filtering: currently trilinear is enabled in the TextureClass but not in our tools. There are issues to think about for both trilinear and anisotropic like: not all hardware supports it, some hardware supports it if there is just one texture but not otherwise, or with a slowdown etc. - this is probably not something we want the artist to specify directly: perhaps the artist can mark those meshes which would benefit from "advanced filtering", and we turn it on selectively depending on hardware? We can do fancy texture matrix operations "for free" now. (Only on Hardware T&L cards!)