Ten Thoooooooooousand Quads?

Blitz3D Forums/Blitz3D Programming/Ten Thoooooooooousand Quads?

Adam Novagen(Posted 2011) [#1]
Okay so. Game uses tile-based maps, up to 100x100 tiles, a potential 10,000 tiles in all. Each one is painted with a 64x64 texture, and there are currently about 18 "frames" in the tile list, but they need to be capable of being re-textured in realtime. I've been doing some trickery at the moment: instead of using 10,000 individual squares, I made 625 big ones. Each quad is 4x4 tiles, and given a 256x256 texture encompassing 16 tiles, applied via brush. This allows me to have a single mesh with only 625 surfaces that hold all 10,000 tiles, and can be repainted.

There are two problems with this, though. Because the tile images are painted ONTO the textures of the quads if they change, there is a (VERY) slight spike in the load when redrawing a tile, and although it doesn't happen often, I'd prefer it not to happen at all. The second and more obvious "problem" is that this means that we now have 625 RGBA textures at 256x256 pixels each, which means a whopping 163,840,000 bytes of memory needed to store them, or 156.25MB. Even though it has WORKED on everything down to my netbook's pitiful little virtual GPU, it seems ridiculously excessive to me from a quality-control point of view.

I realized that if I instead used ten thousand individual quads - just basic, two-polygon, single-surface, single-sided squares - I could avoid having to give each tile its own texture to be DRAWN to, and instead just assign each tile the appropriate frame of the 18-tile texture list. Memory problem solved, one single texture is applied to all tiles with only the FRAME differing, and no redraws either. New problem: Blitz3D now has ten thousand extra surfaces to loop through at each and every call of UpdateWorld(). A quick test showed this to be just as impractical as I suspected it would be. Everything ground to a halt.

Now, here's my question. I know that the obvious solution here is to combine them all into one mesh, leaving only a single surface behind. My problem is this: how can I combine all ten thousand tiles into one mesh, and still be able to assign each and every individual tile a different frame of the same texture, at any point during runtime?


Kenshin Yurihara(Posted 2011) [#2]
http://blitzbasic.com/Community/posts.php?topic=94893#1090545

You can look in my topic there, you might find what you're looking for.
It started out as 2D lighting, but B3D's fail 2D system with no alpha
ruined that. Then it turned into a talk about quads and all that beautiful
stuff.


Adam Novagen(Posted 2011) [#3]
... OMG OF COURSE. VERTEX COORDS. Why did I not think of this?! I was thinking of re-setting the texture for an individual quad to change its frame, when in actuality, I should just load the texture as NON-animated, and change frame via the UV! GOD I am an idiot XD

Alright, so I can make that adjustment; naturally, 10,000 quads is 40,000 vertices, which is above the DX7 limit, but I'll split the mesh into four sets, 10,000 vertices each. Now the load will be up to whether or not the renderer will like 20,000 polygons or not; shouldn't be a problem. Ross C, you are a genius XD


Ross C(Posted 2011) [#4]
Yeah, I got it working with one large texture. Each tile was saved as a part of the texture and each quad had it's own unique UV-cords. You only needed the quads you see on the screen, plus some overlap. Same rules apply as the 2d tile map. You move the quad mesh up, add the new tiles onto the texture, the same way triple buffering works in a 2d tilemap.


Adam Novagen(Posted 2011) [#5]
Erp... I just realized that this method won't quite suit this, due to a second texture layer: special images that "link" the tiles together. This second texture doesn't coincide directly with the tiles themselves, i.e. two tiles can be linked, then one tile might change, but the link texture remains the same. Would a second set of 10,000-quad meshes be pushing it render-wise? *probably knows the answer to this...*


Ross C(Posted 2011) [#6]
Why not just overlay 2 tile meshs then? That way your still only rendering the tiles that the screen can see?


SLotman(Posted 2011) [#7]
You can have several texture layers. Each layer with it's own UV index... see some topics where people project shadows into terrains - the shadow is uv mapped on a second (or third) layer.

And 40k polygons limit? Where? I had scenes with 60-70k without problems - the only limit you have, on B3D, is a single mesh can't have more than 65k polys.

Anyway - why so many quads? Just render the quads on screen, and the ones just outside the border. After they "scroll in" just reset everything into place, and re-set the textures accordingly.

Last edited 2011


Yasha(Posted 2011) [#8]
A single surface can't have more than 65536 vertices, are the actual hard limits of DX7 (a mesh is a Blitz3D thing that doesn't exist in DirectX, and polygons are dependent on vertices). However, some old and crappy graphics cards may have lower limits of their own (these days those cards are probably too old to care about, much like ones without 32-bit colours and so on).

Last edited 2011


Adam Novagen(Posted 2011) [#9]
This thread is a whopping month old, I know, and I apologize in advance for resurrecting it; I just happened across it while searching for something last night, and realized that I never responded to say that, thanks to you all, I did in fact manage to solve all these issues, and have since moved on quite happily with fully-functional code in tow. Didn't want to seem ungrateful or anything, so there it is: thanks!