Maxim polygons
Blitz3D Forums/Blitz3D Programming/Maxim polygons
| ||
| How much polygons I can move fluently in a Blitz3D game. My computer es Pentium 2GHZ 512mb Ram 128mb 3DCard. Thanks |
| ||
| Somewhere between a few and several. You're biggest hit will be surfaces so you need to keep those down to a minimum. Vertex manipulation slows things down. Bones slow things down. Fill rate (how much screen is being drawn) is a frame rate killer. Alpha blend slows things down. Multiply blend slows things down. Additive blend slows things down. Also combine these 3 blend modes with your fill rate for really impressive frame rate hits. The list goes on... My point is that there is no difinitive answer to your question. |
| ||
| I has escenary with 10.000 polygons and 256x256 textures and 5 players with 1500 polygons . Can I move the escenary in Blitz? Can you help me? Thanks |
| ||
| Thanks. But the escenary has 100.000 polygons and 256x256 textures and 5 players with 1500 polygons . Can I move the escenary in Blitz? |
| ||
| Just make sure you cut your scenery up into parts and only show what you can effectively see....and unless your characters look really great , don't use 1500 polys per character. I bet in the hands of a decent modeller they would look the same in 900 - 1000 with decent textures. |
| ||
| 1000 - 2000 polys. Not really much difference in rendering time. BUT, i have found that going above 2000 tris, there is a very small slowdown, like the mesh gets processed in 2000 poly batches or something. I would chop up your scenary a little, as Hujiklo suggests. But, for what you have, i think blitz should be able to handle that no problem. Depends on some of Rob's points too. Why don't you run it and see what kind of speeds you get? |
| ||
| I'd still suggest as few verts as possible for the characters - especially if they are going to be animated. There's nothing worse than testing five or so characters and seeing no slowdown and getting all chuffed only to find later on as you add all the other stuff you wanted that the engine really does have to much to think about, and then realizing that wise optimizing from the start was really the smartest way to go. |
| ||
| Foreward thinking from the start is good, but optimizing from the start means you'll burn out before ya get anything that you will enjoy doing done. At least in my experience. I find it helps to just move on with things, then optimize periodically, or at the end of the project. |
| ||
| Well if you forward think - you don't need to optimize anything! ;) |
| ||
| gotelin, Everything that Rob said is very important, you must get as much out of your system evey inch of the way, if you don't need or see the polys - loose them - dont leave them hidden. Looking forward - or planning as I prefer to call that phase, is the MOST IMPORTANT PART OF YOUR DESIGN. You must try to take into account every aspect you can, so you won't meet anything undesirable when you build and programme your projects. Have contingencies too - if I can't do it this way or have this many characters of this number of polygons have a Plan B which is easy to implement. With animated characters this may be before you add detail - save characters out and keep them separately from the more complex detail you add. You can then go back instead of starting from scratch. Also be frugle with your bones. Don't use them if you don't need them. You must also accept a level beyond which you will not develop - or the project will never get finished - so set the ground rules and follow them stringently. We have a simulator which has upwards of 850 vehicles running with AI and user input via steering wheel - the vehicles travel along a motorway and interact with you - the user. The motorway is vast about 130,000 z pixel depth - all loaded at once and all textured and with animations. Plus a rear view mirror camera. I can tell you that including cars and scenery running on an Athlon 2.4 with 1GB RAM and a 64MB GeForce 4 - I have managed to push in excess of 145,000 polygons with a 30 fps frame rate. The best advice I can give is keep your surfaces down to a minimum. If you have any vehicles try to use as few textures as possible for each vehicle, ie one texture for bodywork and one for glass is enough. This would be the same for animating characters, keep your surfaces down to a minimum and bones too. In our driving sim, we had 30 different type of vehicles all running at once - originally each had 20 surfaces for bodywork textures etc. I managed 13 different vehicles on screen before the system clogged up. So we made all the vehicles into 2 surfaces one for glass one for body and then we could manage all 30 vehicles at once. It crawls on lower end machines, but as it was built for the PC I mention above - it runs fine on the finished sim. IPete2. |
| ||
| Thanks, But can I hidden the polygons? With Entityxxxx? Can you help me with a example ,please? Thanks |
| ||
| You can't hide individual polygons really. You really need to hide the whole mesh. But, since blitz does it's own culling of meshes, the only speed gain you'll get, is with there being no collision detection done on them, as HideEntity does that. |
| ||
| "My point is that there is no difinitive answer to your question. " Ok ,the matter is very complicated, but it should be possible to define a reasonable number of "Tris per frame" to use as guideline during the game development. I propose 100.000 for gotelin's system. What do you think? |
| ||
| a lot dpends on the CPU and video card you are targeting and what kinds of optimizations your doing. Aerial Antics could only push 11,000 polys befor ewe started experimenting with optimizations, ended up with about 40,000 and dynamic shadows. but how many surfaces and shadow polys you can push seems to depend to some degree on your CPU, and wether you want the game to run on older cards pre geforce 1. |
| ||
| 100000 poly are possible but not if they are meshdeformed. Mesh deformation ( or realtime vertex manipulation in general ) slows in Blitz, far more than the same amount of static meshes would |
   |