Max Poly Level
Blitz3D Forums/Blitz3D Beginners Area/Max Poly Level
| ||
| There is of course no max, really. But I was wondering if Blitz3D is efficient enough to render 800,000 plus polygons, now of course there's LoD but even with that, I have to consider vehicles, weapons and up to 31 other characters to render (online of course). So to my question: Would 800,000+ polygons render with minimal lag in Blitz3D? Thanks, Liam |
| ||
| my levels regulary have about 250 000 polys(not visible at once)..so very nice frame rate (60)I keep when I have in sight about 75K polys(including vfx postprocessing), on my test rig(nVidia 6600GT).. |
| ||
| I wouldn't try and render 800,000 plus polygons per frame. As for your biggest speed hit, it's likely to be the amount of surfaces, and more importantly, (if your characters are boned) the number of characters you have. Boned animation in blitz3d is pretty slow. I'd maybe think about scaling back a bit. It also will vastly depend on the computer running it. Alot of folks have on board graphics cards, or the lastest models. CPU speed is a big factor too. |
| ||
| Late reply - thanks alot to Ross and Naughty. I think I will take up writing my own C# engine (XNA) for this type of task (not because Blitz can't do this, just because its my decision.) |
| ||
| Boned animation in blitz3d is pretty slow. What is your comparison? Why you say this? I really don't know much how to judge an Engine in this area. |
| ||
| Boned animation in Blitz3d, uses the CPU to calculate the transformation of the vertices, and is therefore alot slower than using the dedicated GPU to do this. I'm not sure if it's a limitation of blitz, or DX 7 though. It is very slow compared to hardware bone animation. The only difference, or advantage with using the CPU, is i believe you are unlimited to the number of bones you can use, whereas, with Graphics card, i believe have a limited number of bones they can use. Don't take that as fact, it's just what i've picked up and learned from more knowledgable people. The bone slowdown in blitz is a fact though :o) |
| ||
| Thank you Ross C |
| ||
| Ross C / LiamShearer, Yes it is a fact and you are right to be cautious where bones and characters are concerned with Blitz. I would like to let you know that on a dedicated rig, it is possible to have more than 30 characters, and using clever code you can swap these out where necessary like guards in an fps game). I have had something like between 40 - 50 characters, with between 21 and 30 bones, each character with high res textures and something like 3,000-4,000 polygons, all animating, all running about nicely and in a pretty nice landscape too. All the characters were independent, following their own intelligence algos and I have to say looking pretty cool. Client confidentiallity prevents me from posting images unfortunately. The extra problem Liam may face is networking traffic with all these characters, I have never attempted that although that sound like a cool idea to test! I agree with RossC here again, 800,000 polys is a lot to ask in one render from Blitz if you want smooth gameplay and framerates. However by dividing up your level into smaller chunks and using your own simple sort of 'portal' or culling system might help. By that I really mean by turning off stuff which you cannot see and designing your levels in such a way as to keep the poly count visible to the camera always to a minimum, your levels could almost be endless (memory providing of course). You need to use a combination of tactics. The secret is in loading everything into an array or type which you can access very quickly and switch on or off depending upon what the camera can see. (1) using clever design and breaking levels into small chunks will allow you to have only the necessary sections available to B3d to render (i.e. hide the rest using the Entitydistance and Hideentity/Showentity commands). You only need to hide stuff infront of the camera as the rest (if they are loaded as separate meshes, won't get rendered if they are out of the camera view, so you can pretty much ignore them). (2) Use a camera range which can change to refelct the section of the level you are in, as you can alter it on the fly. Where you need a vast emtpy field open the camera range up, when interiors are small and cosy, close it down and have more detail. (3) Use textures no bigger than 1024 x 1024 and try to use DDS where posisble (look around the forum for informaiton on compressed textures it may help keep the quality of your levels very high). (4) re-use animation sequences, by that I mean build one type of animating character and simply re-texture him where possible for all the different characters you need. By adding bits of additional accessories where necessary you can make them seem like individuals. When it comes to animation sequneces simply use the same set of animations for all the characters which have the same characteristics, bone count and names, i.e. a squad of soldiers only needs one set of animations, which every animating character mesh can share between them. (5) Lightmap stuff instead of using real-time lights. Hope some of this helps. IPete2. |
| ||
| It is very slow compared to hardware bone animation. The only difference, or advantage with using the CPU, is i believe you are unlimited to the number of bones you can use, whereas, with Graphics card, i believe have a limited number of bones they can use. Broadly. yes. The number of instructions a shader can include varies according to the shader model, and the older (read:outdated) shader models like 1.3 and 1.4 didn't really have enough instructions to transform as many bones as you might conceivably want to do. Nowadays even entry-level onboard videocards are Shader Model 2.0 compliant, so the only cards around which would have problems would be really old gamer cards, and obviously gamers tend not to have old machines. Besides, with FX shaders, it's trivially easy to set up multiple fallbacks and drop the number of bones on older hardware. I wouldn't bother personally, but it's dead easy if you wanted. Boned animation in Blitz3d, uses the CPU to calculate the transformation of the vertices, and is therefore alot slower than using the dedicated GPU to do this. I'm not sure if it's a limitation of blitz, or DX 7 though. DirectX 7. Blitz couldn't use the GPU if it wanted to. Having said that, the transforms do seem to be especially slow, as witnessed by people who have written their own animation handling system and achieved some major speed increases even on the CPU. No idea how they did that mind, as I'm doing it purely on the GPU these days. |
   |