VertexCoords performance issues
Blitz3D Forums/Blitz3D Programming/VertexCoords performance issues
| ||
| I don't really understand what's going on in my code so I figured I would throw this out here. I've created a mesh to represent some terrain ... it's 128x128 quads. So that's 32,768 triangles. I have an interface written so that I can "draw" on this mesh and move its vertices up or down to create a heightmap. I keep track of which vertices are changing each paint operation and I affect those vertices with the "VertexCoords" command. My problem is that this is pretty sluggish on any heightmap over 32x32. 64x64 is chuggy and 128x128 is approaching unusable. I'm only modifying 40-50 vertices per operation so I don't think that's asking too much. Is there some "Lock" I should be doing before modifying the mesh? Is there some way to store the mesh in different memory so it uploads faster each time I edit it? Any other ideas? I've optimized everything to use the fewest number of vertices possible, single surface, etc. I don't see a way to make this any faster at the moment and that disturbs me. |
| ||
| When I was working on my single surface stuff, I found VertexCoords prohibitively slow, and I found it much faster to free the surface and rebuild the mesh every frame. I know that's kinda ass-backwards, but it actually worked pretty well. Course this may vary wildly between machines and this is going back a few versions now so I really don't have a clue how it'll perform now. Worth a shot though, I'd think. |
| ||
| Odd, but that actually does seem slightly faster. That makes -no- sense to me. Still kinda chuggy, but I'll take what I can get at this point... |
| ||
| Isn't there a vert limit of 64k per mesh/surface or something? If so, you must be working very close to the limit with a 128x128 mesh - that's alot of tris for a single mesh. This 'single surface is king' methodology is, apparently, only true to a certain extent when trying to optimize for speed. There's a point where actually using more surfaces is faster than stuffing everything into a single surface. I hear that 1500-2000 tris per surface is optimal. I think you might get a significant speed gain if split your 128x128 map accordingly. I guess this might be a bit tricky given the nature of what you're trying to achieve, though. |
| ||
| The reaosn updating vertcies is slow is because in order to update the mesh Blitz has to re-send all the vertcies out to the 3D card when any vertex in the mesh is modified. I presume that it caches these changes and makes them all at once, because there is no real speed difference between moving one vertex and moving 1000. But if the mesh has 64K vertcies moving one vertex will be slower than if it has 10K vertcies. So the solution to your problem is to divide your meshes up so they have fewer vertices. This will cost you because of the extra surfaces though, so only do it if you're doing this because you really want to edit the meshes at runtime as the game is playing. Of course you could do it in the level editor too so long as you recombine everything at the end. |
| ||
| Yeah, I think I am bumping against the surface limit - which I didn't know existed, so thanks for mentioning that. That makes a lot of sense now as anything more than about 200x200 on the mesh size would crash Blitz with a generic error message. I'm thinking that I'll split the heightmap up into multiple meshes. Say, 32x32 sections ... that'll let me update each section quickly and the sections will get frustum culled which will help out my game due to the camera angle I'm intending to use. *deep breath* And now ... we rewrite the editor. ;) |
| ||
| I think Blitz could be doing more work with "surfaces" I believe a modern engine should not need to worry about the concept of surfaces at all and group by texture, throw at the card, done. I bet Mark does something like this though. |
| ||
| I bet he doesn't. Blitz is far too slow when using multiple surfaces with identical textures to be doing that. He needs to do it. Pronto. (And if by some chance he had already...he needs to fix it.) |
| ||
| Perhaps this has something to do with Immediate Mode or something? (I have no idea what I am talking about) |
| ||
| Unless I miss my guess, the Blitz concept of a "surface" is simply "a group of polygons that share a common texture and rendering attributes". So Mark is, in fact, enforcing good behavior by sending each surface as a batch to the video card. There may be other problems in the code or something if it can't handle as much as it should, but on the surface (heh) it looks like his design is correct. |
| ||
| ahem... That is all very interesting; but if EpicBoy wants to update these smaller meshes, would You recommend to free the surface and rebuild the mesh, or use VertexCoords? |
| ||
| VertexCoords seems workable now that I've split the heightmap into smaller meshes. It's still not screamingly fast, but it's a hell of a lot faster than when it was all one big mesh. You can see it in action here... http://www.blitzbasic.com/logs/userlog.php?user=4761&log=248 |
| ||
| nice... The concept of surfaces should be very transparent to the programmer though. Because we have different surfaces, we are forced to code through a lot of problems. Removing the notion of surfaces will improve our development times. |
   |