Tilemap to mesh
BlitzMax Forums/MiniB3D Module/Tilemap to mesh
| ||
| Hi, I'm loading a simple 2D tilemap and uses different meshes as tiles, combining them into one big mesh using the addmesh command. Works just great! The problem I have is that the map is really large. 256x88 tiles. Some optimizations have been made (don't place a tile in the middle of a group of similar tiles, unless it's a part of the ground) but everything is just too slow. I tried to add a call to createoctree (going to need collision detection later anyway) but it never returns. When I say never I mean that I leave it running for a couple of minutes and then kills the app. I used 200,5 as the values but have also tried other bigger and smaller values with the same result (nothing happens at all). So, what do I do now? Is there a bug in createoctree? Am I feeding it with a mesh that is too big? Have I misunderstood the concept of an octree? Should I leave createoctree running for 5-10 minutes? (Can I even require future players to accept a loading time that long?) Thankful for any help! |
| ||
| Octree creation should only take a few secs. Try 0,3. Does that work? Might be a bug. As for your tile map, it sounds like you might have too many textures/surfaces. Try and pack your tile images into as few textures as possible (you will need to offset your tile mesh UVs as a result), then your mesh will only needs a few surfaces at most. |
| ||
| 0,3 did work, if I left it running for 5 minutes (debug build) I think I might have an enormous amount of surfaces, if a surface is another word for triangle. CountSurfaces() tells me that the map is made out of 9 surfaces, but I know it contains 22528 tiles and a total of about 200-270000 triangles. If addmesh() reuses textures, or how things now work deep down in the source, I should only have about 10 or so. The textures all got a size between 32 and 128 in width and height. Hmm. Surface = Texture? |
| ||
| The problem is the debug build. It will significantly slow down loops. Try to define the functions that you know that work and that have loops as "function bla(...) nodebug" to prevent them from beeing killed by the debugger. |
| ||
| The non-debug build was only a couple of seconds faster, createoctree still takes about 5 minutes to run. |
| ||
| Hmm. Today the non-debug build creates an octree in 76 seconds. Odd, but I don't complain! :) A one minute loading time is tolerable, I think. |
| ||
| What are you using the octree for? Octrees (in MiniB3D) are only useful for collisions and picking. 9 surfaces are OK. AddMesh will combine surfaces (which share the same texture) when it can. It's a lot of tris though, which explains the CreateOctree time. |
| ||
| I'm no expert at octrees, but I have a faint memory they was also used to speed up rendering. :) If that turns out to be false, I will need to check for collisions later so it should still come in handy. |
| ||
| I think you misunderstand the term Octree. A Octree could be used for different things. It is nothing more than a tree with 8 nodes. You could use it for scenemanagement like it is done in my next release or you could speedup collisions like simon did. It always depends in what search criterias you have and what kind of input . Also at least and most important what you want to achieve. In fact most time an octree is named by the context of speeding up rendering. But only because thats what most people want to know. Instead Octrees are used much more in 3D Engines than most people think. I hope and think you will see the difference with my next release (hopefully) next week. |
   |