Hi,
Now my egg octree splitter is done, I would like to try LOD. My purpose is to set up a demo with a hudge hi-polymesh world, not a terrain. I find heightmaps too restrictive and would like to see a level that is not topologically equivalent to a plane, with some caves and so on.
GeoMipmapping semms to be a fairy common technique when dealing with terrains, and the good point is that it allows the use of a single vertex buffer that is shared by multiple index buffers.
But the point is that I’m not sure I’ll be able to apply the algorithm to a lambda mesh that is not only a heighmapped plane.
Another technique I tried with DirectX is mesh simplification. Giving a mesh, it’s possible to extract it’s adjacency, and then perform a mesh simplification with conservation of the adjacency.
Then if the mesh is divided into cells, each cell can be simplified in respect to its adjacency.
I’m now hesitating between 3 options :
trying to apply the geomipmapping algorithm on a lambda mesh (but I feel bad about it)
trying to find or port the adjacency and simplification algorithms in Panda with the egg lib
admitting this is has to be done at the level-designing level and then use the 3D editor functions / scripts to build LODed eggs
My intuition is that, in professional game studios this is preferably done with authoring tools that complete the level editor, something closer to the third option. I can’t afford writing a level editor and was planning to reduice it to some scripts / macros inside the 3D modeler.
The implicit question is : since all that must be precalculated, does it makes sense to program it with Panda3D, ie a real time rendering engine ?
Hello,
I won’t be able to give direct answers to your questions, but since this is a topic I am wondering about frequently (without a final answer yet) I will try to give my two cent. I too find heightmaps too restrictive, since I want to have overhangs, caves, arcs with my “terrain” (well, full static environment actually).
Geomipmapping: As far as I know this depends heavily on regular grids. Each LOD every second grid node is left away (ok, it’s a bit more complicated, and the problem is in making adjacent patches with different LOD fit without cracks). Might be I have a bad day, but I don’t see a way to apply this algorithm to arbitrary irregular meshes. So any ideas are welcome.
Simplification: I have some code for wrapping QSlim (unfinished and rather messy) and Terra (working) algorithms by David Garland http://graphics.cs.uiuc.edu/~garland/software/qslim.html. None of these supports adjacency though. And so they are pretty useless for now, except for LOD of singular objects like barrels, tables and so on.
A question about conservation of adjacency: Assuming the simplification is done offline (either in the 3D modeler or post-processing the modeler output with Python scripts), then you will have to create at least 6 “versions” of a cell: one with the high LOD, one with with the low LOD, and four with low LOD but “skirts” (north, south, east, west) which connect to the adjacent high LOD cells, right?
Something I was wondering about, but never tried out is not to bother about seamless integration of two LODs, but just to lower (move down) lower LOD cells by a small amount. The lower LOD cells are farther away, so one wouldn’t see the cracks, and perhaps it is possible to soft-paint or blur the transition.
Well, if the simplification process takes care of adjacency, no gaps between cells should appear (maybe some inaccuracies but not so much I think).
AFAIK, lod simplification doesn’t usually care of the state of its neighbors when switching the state of a particular cell, but I’m not a professional game programmer so maybe am I wrong.
The underlying question is at which level should we do that. I’m sure the simplification algorithms in use in Maya or 3DS are complex and work well with UVW projections. I’m not sure to be able to achieve the same think with the Egg lib.
Some scripts or macros are written in the modeler scripting language, to split-up the mesh and creating as many LOD as we want. The cells are named with a certain convention then exported to an egg file (or in multiple eggs files)
In panda, the egg is loaded and LodNodes are created according to the naming convention of the nodes (eg : cell_[X][Y][NodeLevel])
Pros : Quality and reliability of the simplification process
Cons : Part of the code depends on the modeler (so in most cases on Autodesk commercial strategies )
custom scripts use the egg library to build splitted and LODed EggNodes with naming conventions
Panda loads the nodes in the same way than (1)
Pros : modeling package independant, allows to program either in C++ or python
Cons : need to implement simplification algorithms
u Level editor[/u]
In a professional studios, I think in most of cases a custom graphical level editor is built that covers everything between the modeler and the runtime. The editor generates lots of files, including geometry (in the egg format for example) but also piece of scripts, configuration files, metadata and so on. In that case, the simplification process might be a detail.
Pros : We all want the same
Cons : Who can work 6 months on this for free ?
I’m actually thinking of going in the 1st way, but I can’t decide which modeling package is good enough to investing time and money in the long term.
those skirts might be pretty intresting. for example:
take a simple poly-reducer (like the ones which comes with blender or whatever) aaaand your mesh. first you sortof need to split your mesh into chunks (if they arent already) and then let the reducer generate several LOD’s … lets say 3. while doing so let him keep sort of a vertex-list vor each vertex which has faces across 2 chunks and a single list for each lod.
this way it should be possible to have those nice lod-chunks precalculated with one-time on-the-fly borders.
not a perfect solution but still better than storing 8 mesh-versions for just 2 different lod-levels. and you can combine any lod levels you like … like one chunk is level 1, the one above 3 and the one left of it 0.
might work…sortof… with propper workout for the edges …maybe^^ just an idea it’s not that far away from geo-mipmapping but should work on almost any geometry.
)
…maybe^^ just an idea it’s not that far away from geo-mipmapping but should work on almost any geometry.