Limit number of surfaces per Mesh?

Blitz3D Forums/Blitz3D Beginners Area/Limit number of surfaces per Mesh?

Abomination(Posted 2011) [#1]
I'm working on a pixelperfect gui in a 3d world.
I wanted to make it singlesurface, but I've come to use too
many vertices for just one surface. (more than 3200?)
Also wanting to add more textures, will require more surfaces.
Now what to doo?
I could just add more surfaces to the mesh.
Or add more meshes with just one surface. locating them all in one location.
Or add up to 3 surfaces per mesh (because more would slowdown graphics?), then create an other mesh, etc. etc.
i.o.w. Is there (speedwise) a limit to the number of surfaces per mesh, or to the number of meshes in view?(since they are all located in the same location here.)
A few tips will be greatly appreciated. ;)


Kryzon(Posted 2011) [#2]
It's good that you're doing it single-surface from the beginning. Saves you the hassle you would get later on when things start to slow down from the lack of optimization.
Your goal is to keep a steady and fast frame rate. If you can reach this frame rate by having only 3 surfaces per-mesh, I don't see why you should be trying to join everything in the same mesh.

To help with that you should make your system very generic in the sense that a Const could define how many surfaces per mesh you want max. If you need another element\surface and the current mesh's surface count has topped, then you build another mesh to populate with surfaces.

I believe there isn't a limit on surfaces per mesh - the help file is quite clear on this. Another useful piece of information (this one isn't on the help file AFAIK) is that a surface cannot hold more than 64 thousand vertices. If you notice you are about to add a collection of vertices that would break this limit, make sure to put them on a different surface (even if you have to create another mesh + surface for this).


Warner(Posted 2011) [#3]
This may be a silly question, but why are you using so much vertices for your GUI? If each control uses say 4 vertices, are you trying to draw 800 controls?


jfk EO-11110(Posted 2011) [#4]
It also sounds strange to me to have so many vertices in your gui, maybe you want to make it real 3D, not only 2D on a texture?

However, there are some facts about surfaces and vertices:

Officially there may be 64k Vertices, but a lot of older cards will support only up to 40'000. And: the max number of triangles may be 32k. I would suggest to stay below 30k with both, vertices as well as triangles.

I don't know the max number of surfaces, but I would not be surprised if it is limited to 32k as well (signed 16t bit, good old DOS limits), but 32'000 surfaces for sure is more than you ever (?) need.

There is one thing you should know: if you use Addmesh and both meshes are using identic surfaces (for example two surfaces with the same texture and all settings are the same) then DitectX will merge-optimze the surface count, resulting in a mesh with only one surface. If each surface already had eg. 35'000 vertices then this may result in a MAV on renderworld, due to 70'000 Vertices after AddMesh. You can prevent this Merging when you use very small diffrences in the brush settings. For example in the brushcolor: 255,255,255 vs 255,255,254. This can hardly be seen, but will allow to have an almost unlimited number of Vertices in one texture.


Abomination(Posted 2011) [#5]
@Kryzon: Thank for this advice.
I thought this limit of vertices per surface was 3200, because I came across this number in a few examples on these forums.

@Warner: Not a silly question at all, old fruit ;)
1. you never know what someone wants to do with your gui. Perhaps create a few dozen windows the same time?
2. Most of the controls only use 4 vertices, but some have more, so I can add some "special effects". Who knows what I will think of next.
3. I want to give the program, that will work together with this gui,
the possibility to "share" the use of the surfaces of the gui.
4. I thank you for thinking along...

@jfk: Thanks for this info. I don't think my gui, or the use of it, will top those limits. But perhaps the graphics could slowdown before that?

Last edited 2011


jfk EO-11110(Posted 2011) [#6]
That's hard to say if we don't know your gui. Example: if you have 10 quads, each one with 4 vertices and 2 triangles, each one covering the screen (pixelperfect, if you want), using alphablending, then you only got 40 Vertices, but there will be a serious slowdown. So using big (screen-filling) alpha objects will slow rendering down, no matter how many tris you got. It's even worse when every quad is using an individual brush/texture.

32 kTris as opaque, non-alpha, normally textured 3D gui (like some buttons made of boxes and stuff) at the other hand may render quickly and be acceptable on a card that isn't real ancient.

Normaly people use a 2D gui on a quad, only to be able to have it semitranslucent onscreen, like many modern games (as well as to scale the 2D gui automaticly, tho this may blur the gui). For this kind of "2D in 3D" gui ONE single (screen-covering) quad should however be enough.

Last edited 2011


lauri(Posted 2011) [#7]
My game-project works still with ~60 000 tris with another surface with alpha. Coluld there be problems with older computers if I use so much tris? And how I can make very large terrain? LoadTerrain() doesn't work because I need caverns, tunnels and things like that in my wold.


jfk EO-11110(Posted 2011) [#8]
There are two things, alpha and non-alpha tris. With alpha the size on screen as well as the number of alpha layers the renderer has to go trough does matter more than the number of trianlges, where of course the number of triangles is always critical as well. Nonalpha meshes do not really care about the number of layers in ZSpace. But 60k Tris is still a lot for older cards. You maybe get 15 fps or so on a tyical DX7 card.

Not only the number of triangles matters, but also the number of surfaces in the scene. 60k Tris on 1000 Surfaces is much slower than 60k Tris on 2 surfaces. At the other hand a single surface with 60 kTris will always be rendered, even if there is only a few triangles of it visible on the screen, so for a landscape it's better to have several fragments, allowing the renderer to skip things behind the cameras back, as well as things out of the camerarange.

No matter how smart you are, you'll reach certain limits when you try to do superhuge worlds with high details on old hardware. When you watch older titles, they used a lot of tricks. For example levels where designed in a way that prevented the player from climbing up hills and watch the whole region, instead the player was locked in canyons and valleys. An other approach is radical LOD. Level Of Detail is using multiple versions of every mesh and will display only a low poly version when it is far away. It is radical when you are using simple quads for complex distant scenery. Eg. a hill with many trees, far away from the camera: render it once then hide it and show only the render on a quad as long as the players view angle to the hill remains within a certain range. You can do extremly detailed world this way.

Nevertheless, the complexity of worlds is limited by the level loading time. You don't want to load for hours, do you? Many modern games have a streaming world architecture, the enviroment is loaded in the background by a seperate process while the player is moving, depending on where he's going to. So far this isn't possible with Blitz, since Multithreading isn't really possible whith the DX7 Surface (at least not with the LoadMesh command, as far as I know).

So the conclusion may be: if you want complex and detailed outdoor scenes, there's no way around a powerful LOD system. You maybe gonna find something in the archives.

BTW. I repeat, make sure to get only 40k Vertices and 31k Tris in one surface. Some cards will not support 64k Vertices or 64K Tris.


RemiD(Posted 2011) [#9]
Hi Jfk,

Do you have any links to learn about how to code a streaming engine ?

I have my ideas on how to code it, but i'm curious of how others are doing it.

Thanks !


jfk EO-11110(Posted 2011) [#10]
No, I never tried that so far.

You sure will find some infos in the web, but if you want to do it in B3D then you maybe should first try to get multithreading working in Blitz3D. That's not so hard (wasn't there a Userlib for multithreading?), but you need to be able to load a Mesh to a handle that the primary thread knows. So basicly you need to reserve Ram and a handle then run an additional process thread that will load the mesh to that handle while the main game process continues. If the mesh is loaded, a flag is set and the entity becomes valid in the main process.

One problem is: you have to load the entity to a known address, contrary to LoadMesh, that will return the address/handle that was autocreated. That's the tricky part IMHO. You maybe could load it using LoadMesh, then RTLMemoryMove it as a Block of Ram to a dummy entity that was created with LoadMesh and has the same number of Surfs, Verts and Tris. But moving Ram requires the child thread to have access to the parent thread's ram - that might be restricted by the OS..

A lot of hacking is however needed when you do it in Blitz3D. Maybe there is a simpler way to do it, but I can't see it right now.

Last edited 2011


RemiD(Posted 2011) [#11]
In fact i wasn't thinking about managing the memory.

I was thinking about using a grid to load/unload progressively the meshes, the textures, the sounds depending on the Player position and orientation.

I guess the best way to know if it works is to try :)


Yasha(Posted 2011) [#12]
You can do this sort of thing with a single thread as long as you have:

- a counter to keep an eye on the time elapsed each frame, so you know how much spare there is for loading
- a dynamic system that "learns" how long it take to load assets so that as the game goes on, they fit better into the time available
- render tweening, so that if there is a slight overrun, the gameplay will seamlessly absolrb it without skipping.

If you write your own loading routines, rather than relying on the builtin commands, you can also add verts and polys to single large meshes in more than one burst, splitting it up over several frames.


lauri(Posted 2011) [#13]
Fastpointer library from fastlibraries, maybe?
But how I use it to loading meshes correctly?

Last edited 2011


jfk EO-11110(Posted 2011) [#14]
Yasha - I agree, to use your own loading routines makes it easier, but there are certain things that you cannot do with code, you can only LoadMesh it, eg. weighted vertices in animations, probably Mesh animations at all, unless you want to rewrite the entire Animation handler - not a simpe task.
Lauri - you have to try, be the first... This thing is however no longer something for the beginners section. So don't expect it's going to be easy.

I think it would be rather easy to do it for terrain and plants environment only, static meshes only. Just use your own loading routine that will seek the required data inside a huge file of the worlds vertex, tris and material data. It might gonna be a little tricky to add triangles with perfect smoothing and seamless to the existing geometry. Probably not very obvious when you load patches of a certain size.