Limits of BlitzMax 3d
BlitzMax Forums/BlitzMax Programming/Limits of BlitzMax 3d
| ||
| Could Blitz Support post some type of specifics about the limits of the future 3d engine? What I am looking for is any information on polycounts, amount of bones assigned to a single vertex, anything that should be known to for modeling/animation. Why? Content can take forever to design/build... so it would be nice to get a jump start while the 3d engine is still being built. Thanks. |
| ||
| I think as long as there is not the overly restrictive surface limit that b3d has, the other things should be fine. I think we all have cried loud and long enough about that one that he won't make that mistake agian. ;) |
| ||
| We'll let you know when we find out ourselves! |
| ||
| What I am looking for is any information on polycounts, amount of bones assigned to a single vertex, anything that should be known to for modeling/animation. This is pretty hardware-specific. I'm assuming Mark will take advantage of the 'modern' (post-DirectX 7) features such as hardware skinning for animation. |
| ||
| I was told by many blitzers that a good polycount for b3d was 2k or less. Modern 3d engines can handle 3 and 4 times that per model. Is it best to stick with the 2k or less idea? Or design higher detailed models? |
| ||
| determine how long it will take you to complete your game. 6 months, 12 months ? double it. create characters and environments with twice the polycount of current AAA titles (it is somewhat easier to remove detail than to add it) |
| ||
| >> "good polycount for b3d was 2k or less" For each model or for the whole game?!?!?!?!?!??? |
| ||
| @bradford - I wasn't asking for advice for a development cycle. Doubling the current AAA polycount would mean 12-16k poly characters.... not likely. @theduck, per character model. B3d would seem to slow up dramatically with 30 animated characters with 2k polys |
| ||
| Could Blitz Support post some type of specifics about the limits of the future 3d engine? The main limitation would have to be "It's not out yet". That'll slow any project right down to a crawl. I think as long as there is not the overly restrictive surface limit that b3d has, the other things should be fine. Well you're probably out of luck there. The "surface limitation" is a limitation of DirectX/hardware (more specifically ammount of index buffers), so there really isn't much BRL can do about that. But how often was it actually a problem? I've never needed to use more than 40 surfaces at once. B3d would seem to slow up dramatically with 30 animated characters with 2k polys Yes. Well there isn't much hardware arround today that can handle near real-time manipulation of 5 million vertices per. second. |
| ||
| Well you're probably out of luck there. The "surface limitation" is a limitation of DirectX/hardware (more specifically ammount of index buffers) and what planet are you living on? ;) the B3D surface limit is not the fault of directX, its [likely] the way b3d handles vertex data. Do you think other blitzers have been making single-surface code/libraries just for the fun of it? its because ss stuff gets around b3ds "surface count limitation" |
| ||
| Yes. Well there isn't much hardware arround today that can handle near real-time manipulation of 5 million vertices per. second. erm, even if every triangle had 3 verts, thats only 180,000... |
| ||
| Well you're probably out of luck there. The "surface limitation" is a limitation of DirectX/hardware (more specifically ammount of index buffers), so there really isn't much BRL can do about that. But how often was it actually a problem? I've never needed to use more than 40 surfaces at once. No it isn't. Blitz3d is not capable of automatically batch rendering entities which share the same material properties, and since we do not have low-level access it is not possible to do it manually either. Combining multiple entities into one surface is the only guaranteed way to batch render ( CopyEntity kinda works but not 100% ) and that is most definitely not the case with DirectX. |
| ||
| Do you think other blitzers have been making single-surface code/libraries just for the fun of it? I can't really comment on what other people chose to do with their time. Blitz3d is not capable of automatically batch rendering entities which share the same material properties, and since we do not have low-level access it is not possible to do it manually either. Really? Since when? I've had several thousands of different entities with the same multitextured, animated material on screen at once. I believe the sample is even on the Blitz3D CD. erm, even if every triangle had 3 verts, thats only 180,000... Yes 180.000 per frame which is roughly 10 million per second at a respectable 60Hz. I was assuming there where only 2 more vertices than polygons. |
| ||
| Really? Since when? I've had several thousands of different entities with the same multitextured, animated material on screen at once. I believe the sample is even on the Blitz3D CD. Yes and Mark himself said there's no guarantee that they will be batch rendered. |
| ||
| good polycount for b3d was 2k or less Really? I guess my main character is missing half of his/her body and I haven't even noticed. And oops, there isn't any polys in the enviroments either?!? [yes, I know... bad attempt at being sarcastic...] IMO B3D can push 10-20 times 2K multitextured polygons per frame easily - of course bad programming always can make things slow, even with just one polygon. |
| ||
| I'm sure the 2K polygon limit was/is a DX optimal rendering number, per surface/mesh. Having the boned animations handled by hardware, WOULD have great speed ups, as in Blitz3D it's handled by the software. Hardware is always going to be faster. |
| ||
| I would think that the engine would be only limited to the underlying limits of the technology it uses - that is, OpenGL and DirectX. You can look at the documentation for those. I'm sure you should still be able to interlace a splattering of direct OpenGL commands, for example, in amongst regular Max3D calls. I would think they would try to allow the module to do as much as the underlying rendering libraries can handle. |
| ||
| lol. Engines vary greatly in speed. If all engines did everything the most basic way - passing all vertices every frame, sure they would be the same speed. However, better engines have more methods to do things. A good engine will be able to do things many different ways, and be able to use the proper method in different situations. Most of the time this depends on how much the mesh will be changing, or what specific graphical requirements are. There are also different schemes of handeling matrices, the mesh data in general, occlusion, LOD, etc. If OpenGL/DX were higher level it wouldn't make much difference, but they are pretty low level. |
   |