Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Posted: Sun Nov 02, 2014 6:02 am
Are there any news regarding XMLConverter? Ogre 1.10 nor 2.0 can't be released with this issue not getting fixed.
Support and community hang-out spot for Ogre3D
https://forums.ogre3d.org/
Hehe...I'm pretty inactive currently and limited in time, but I will get a mail if somebody replies to this thread.I'm hoping he's still around. He hasn't logged on in 4 months...
I'm still not sure whether putting mesh==>mesh operations (which has nothing to do with XML) into XMLConverter is a good idea. At least it should have a proper name like OgreMeshTool as scrawl suggested. If the user wants to have a binary with name XMLConverter, we can copy the file (and symlink on non-M$ operating systems). However I'm not officially an Ogre3D developer so my opinion is unimportant to this...so who likes this idea to have an allinone XMLConverter should do that part...Are there any news regarding XMLConverter? Ogre 1.10 nor 2.0 can't be released with this issue not getting fixed.
XMLConverter is the key tool for importing assets from 3rd party modelling software. It is THE most important tool for content creation.sajty wrote:I'm still not sure whether putting mesh==>mesh operations (which has nothing to do with XML) into XMLConverter is a good idea. At least it should have a proper name like OgreMeshTool as scrawl suggested. If the user wants to have a binary with name XMLConverter, we can copy the file (and symlink on non-M$ operating systems). However I'm not officially an Ogre3D developer so my opinion is unimportant to this...so who likes this idea to have an allinone XMLConverter should do that part...
Nice to have, but FYI the OgreMax plugin has an option for this in the settings. Ask the developers why it's off by default7. merge equal vertices: For example OgreMax has exported my collada models in a way which was suboptimal. It was never reusing the same vertex even if the position, normal and uv coords was equal ( in other words: index count = vertex count).
Take in mind most important optimizations are:9. Create an optimize(mesh) function, which will not generate any Lod levels, but optimize the vertex and index buffers for fastest rendering (just enabling some of the above features and generating new index and vertex buffers).
I would place much effort on manual Lod levels. They're a PITA to support and thus getting abandoned in 2.0.11. generate Lod levels as separated meshes, which allows to recalculate normals for each Lod Level for best quality then load them as manual Lod levels.
At runtime in general or just the tool?Disadvantages of the new features:
-50% bigger memory footprint: We now store for every vertex position: the vertexID list, including submesh, normal and UV coords. So we also need to touch the UV buffer and generate lot of extra data.
Hehe, but you cant trust the mesh input to be correctly generated. A wrongly exported/generated mesh should also have a nice LOD and in the LOD generation process it comes handy if the mesh also gets optimized.Nice to have, but FYI the OgreMax plugin has an option for this in the settings. Ask the developers why it's off by default
Yeah, I know these and I have lot of great ideas in my head to improve the generator, but currently I dont have enough time to work on it.Cache optimization (relevant literature: here, here, here, some code). We already have a cache optimizer and an AMD Tootle integration, but I don't know their current state or quality (IndexData::optimiseVertexCacheTriList, VertexCacheProfiler::profile). May be worth checking out.
Actually, I have read your Ogre 2.0 pdf after implementing these vertex buffer related features, so porting to 2.0 will also be harder, because now the algorithm is directly processing the position, normals and UV. I dont have checked ogre2.0 until now, but I hope the implementation will be transparent between different number representation (However that may cause overhead).Compression. Store position as 16-bit half. Normal tangents and bitangents as QTangents. UVs as 16-bit half. This is already done in Ogre 2.0 though (we use a different mesh file format)
Just the MeshLodGenerator, when generating the LOD levels. So its not that big deal, because normally you can preprocess your meshes and you will not get any slowdown ingame...if you generate them on the fly, then you should use a background thread anyways, so hopefully that 20% slowdown when generating will not get noticed by the user.At runtime in general or just the tool?