Surfaces: less = better? I'm not so sure...
Blitz3D Forums/Blitz3D Programming/Surfaces: less = better? I'm not so sure...
| ||
| After conducting several test with various single-surface particles systems, etc, I'm not convinced there is an advantage in using less surfaces. In fact, some single-surface systems will barely run on my hardware (could be due to implementation). The Blitz3D Manual implies a greater number of surfaces to be more useful. I'm having difficulty finding facts that contests this or explains the disadvantage of using more surfaces, although I have found some reasonable speculations: "I believe it's to do with modern 3D cards rendering pipelines, whereby meshes are loaded into the pipeline surface by surface, therefore the more surfaces a mesh has the more iterative the rendering pipeline becomes for that mesh. Not sure though ;)" -Sunteam. However, if surface counts impact performance I would like to reduce them. Any assistance would be greatfully appreciated. |
| ||
| Surface count DEFINITELY affects speed. Take my word for it... I've been using Blitz 3D since it came out. Each surface causes a stall on the 3D card, and so a realtively few number of surfaces will really bog your framerate down. I don't know more than that, and you don't need to either to make use of the knowledge that less surfaces = better. :-) Just try creating 400 single surface particles, and you'll see your framerate drop significantly. A single surface system can handle that many easily. Of course, you can't do as much with a single surface system. One more thing... combnging meshes into single surfaces is a balancing act. When you have a single mesh that whole mesh gets transformed and rendered when any part of it is in view. And you can't hide part of it when it is more distant. And stuff like my shaodw system for instance needs meshes to be small so that their bounding spheres don't intersect the shadow volumes, or else their polygons have to be clipped. So combine your meshes, but don't go overboard and keep in mind that stuff. There's no good reason to combine every building in a level into one mesh, unless you know that you need to render the whole city at once from high above, and you have lots and lots of buildings visible at once, for example. |
| ||
| sswift, Thank you for the swift reply:) I definately take heed to your advice. My current particle system is non-single surface to support meshes > 2 triangles as particles are used for ammo, etc. However, I would like to use a single surface for sprite particles and lens flare system. My only concern with the implementing single surface is the massive number of operations needed to manipulate the quads at the vertex level. I see many using a significant number of cos/sin calls, etc and I'm weary. |
| ||
| I would not use cos/sin. I would use tformpoint and a pivot. At least then, if sin/cos is being used for the trasnformation it's done as fast as possible in C. It may also be possible to do the transforms by calculating three normals from the cameram, one for each of it's axes, and then figuring out how much to scale those by accoridng to how far away the quad is. In other words, the camera's Z normal tells which direction the quad faces. You can probably throw that away. The camera's X and Y normal can be scaled by some values, positive and negative, to calculate the corners of the quad, so they are aligned with the camera view. But then I suppose the quad would roll with the camera. So you might have to use a pivot that you somehow control the roll of to calculate these. And then you use the distance of the quad from the camera to calculate what to divide the size of the quad by so it changes with perspective. Then again, I suppose since you would be actually positing the quad at it's location in space that you need not actually scale it by it's distance. That's good cause it saves you a divide and a square root. So I guess what you'd do is: 1. Create your pivot which you align to the camera in some way depending on whether you want the quads to roll with the camera or not. 2. Use TformNormal twice, once with 1 in the X slot, and once with a 1 in the Y slot. That gives you the pivot's X and Y axis. For each quad: 3. If your quad is 2 units in radius, multiply these normals by 2. 4. Then, using the center of the quad, calculate the positions of the four corners by addind and subtracting the normals from that location as appropriate. 5. Position your vertices and build your triangle. 6. To get the normal for each vertex if you want lit quads, then you can transform that pivot's Z axis too... though use -1 so it points towards the camera. Yeah that should work. And no sin/cos except for one hidden int he tform function that you only do once per frame for all quads. |
| ||
| What Swift said - combining meshes needs careful consideration. You usually want to have as few surfaces as possible per object, so it makes sense to group things and textures that are usually seen together, without "going overboard". Example: Level with furnitures and objects, few enemies, guns and usual stuff. 1. Level You should combine textures here as much as you can and use horizontally tiling wall textures bundled together with other details like lighting fixtures. You can use separate texture map for ceiling stuff and keep the ceiling separate object - same for the floor. Reason behind keeping walls, ceilings and floor separate objects is that the will be culled properly... when you look up, there is no need to draw the floor and when you are close to wall you don't see the floor OR the ceiling. All this assuming that you have complex levels with lot's of polygons and high res textures. And of course you should split levels as "rooms" and not keep it one huge lump. 2. Furnitures These are separate stuff like tables, chairs control desks, soft drink machines etc. It makes sense to group these together somewhat like table & chair pairs, but since they are probable separate entities anyway they are also automatically separate surfaces. But if you have static group of chairs and tables they will be then single surface entity. 3. Players & enemies These should be one surface entities if possible, but sometimes you want to make different sets of enemies easily by mixing and matching legs, upper torsos and faces - they will be then separate objects and surfaces, so it might not be usable to combine legs, torsos and face to the same texture map at all. 4. Weapons As these will be separate objects for sure, you can just concentrate keeping one spesific weapon as much single surfaces as possible - it's no use to combine EVERY weapon in the game to a same map. |
| ||
| There is a thresh hold limit on the number of single surface particles where cpu time is greater than gpu time handling an individual surface for each particle. having one surface per mesh is faster than having multiple surfaces on a mesh. |
| ||
| its odd though. my level has 65 surfaces.| tried texturing my level wiht one grey texture( 128x128) and the framerate was no different |
| ||
| Ruz you still had 65 surfaces even though they all had the samd texture on them. |
| ||
| erm no It didn't. it went from having 65 material ids to 1. how does that constitute 65 surfaces? I applied one standard texture in max and lost all the material ids. |
| ||
| The number of material ID's likely has nothing to do with the actual number of surfaces you have. Use countsurfaces to dtermine how many surfaces a mesh has. And use countchildren to dtermine if your mesh is comprised of more than one entity, each of which can have it's own children, so you'll need to write arecursive function to make sure you count them all. Each entity that has polygons, has at least one surface. And each entity can have children that will each have at least one surface and may have children with their own surfaces. The only way to be sure is to check. You don't have to write a recusrive function to count the children though if you determine that the main entity has no children. |
| ||
| I don't know the specifics of exporting from 3D Studio Max but my understanding has been that separate materials=separate surfaces, and conversely same material=same surface. At least within a single object. Sswift's point about separate objects is important, that the separate objects/entities thing would still matter. Because even if all the objects have the same material, separate objects are always separate surfaces. In most of the levels I've seen created in 3D Studio Max, people went crazy with separate objects and/or were lazy about combining objects, resulting in a separate object (and thus separate surface) for every little detail in the scene. |
| ||
| Isn't it that fps depends actually on the number of vertex your scene have? I mean, I believe, at last, everything depends on vertex... (texture coords, directx lights, polys, mesh deformation...) Most of the time, the amount of polys and the amount of vertex has a certain "relation", but sometimes, not optimized scenes and NOT welded vertex on surfaces or entities can cause a fps slowdown... later! Paolo. |
| ||
| hey Eruy ;) surface count ussualy have more Impact now than polycount...unless you pushing 4-5 hundred thousand. (even in 3drad) collapsing a mesh(to a surface per texture) can easily double your frame rates if not more. Like jhocking its also been my experiance that the texture count is the surface count when loading a mesh into b3d. ( accorsding to coutsurfaces)doesnt b3d merge them istself, since blitz3d 1.6 (before that I used to colapsing them myself) but when creating enitys each is a surface? even if the same texture is used? Zmatrix |
| ||
| Surfaces work because the material command is called, and then an array of vertex data is passed to the video card. Changing surfaces "interrupts" this optimized process, slowing it down. |
| ||
| 'The number of material ID's likely has nothing to do with the actual number of surfaces you have' as far as I am aware each material id equates to a surface when exporting from max I tried exporting one entity( it had no children) with 65 material id's(this equated to 65 surfaces in blitz because i checked),then checked the framerate, then exported the same object/entity with 1 grey texture and there was no difference in frame rate. |
| ||
| I would think that would depend on how much vram you had also? (in Ruz's case) Hell I dunno, lol What about this , in quest3d if I load a cshop level thats made of say 3000 brushes and 10 textures, it will be fairly slow 50-60fps max. but if I collapse the mesh , it will be much faster 160-200fps now is that surfaces or entitys?(beacuse quest 3d automatically loads the hierarchy?) so all 3000,brushes are seperate. A test could be loademesh vs loadanimmesh in b3d. Zmatrix |
| ||
| Ruz, could you be more specific about your level? Or better yet, give us the files to inspect ourselves. Oh, and the code you are testing it with and/or how you are checking the framerate. While you're at it, give us specific numbers for the framerate and not simply that there is no difference. If the scene is fairly simple to begin with, and depending on how you are tracking the framerate, you may be looking at your monitor's refresh rate. Thus simplifying the scene won't change the number you get since it is already capped at the refresh rate of your monitor. That's why I asked for specific numbers. If the framerates you are getting are like 75 then it's probably capped to the monitor's refresh rate. There's nothing specifically wrong with this (I do this too) but it will give you misleading results vis a vis slowdown from multiple surfaces. |
| ||
| What i've found out, regarding the sin/cos stuff. It's not that much different.. I've tried look up tables, instead of sin and cos, not much difference. Best trying to find your extra speed else where i say. |
   |