Iam currently in the process of writing a RTS game engine and iam keen of the idea of having maybe 100’000 possible units on the screen at once!!!(think medieval total-war but bigger)
My idea is to use sprites for the units with 3d for terrain and big features (buildings maybe) hence i would like to use openGL for the 3d stuff. But iam unsure if openGL will let me push that many sprites around the screen?
I was thinking of using a textured quad for a sprite, but iam also concerned about how would i animate the sprites using opengl?
If openGL isnt appropriate for this application is there any alternative APIs that would allow me to do what i want or would I be looking at writing low level windows code from scratch to push aorund this many sprites efficently?
This prolly gets asked alot I know and yes i have searched the forum already to check!!
In OpenGL you can draw as many things as you want. The only question is the performance - but it will be difficult to find something more efficient than OpenGL.
You can do the sprites with textured quads(billboarding), but maybe you should take a look at Point Sprite extension for best performance.
However, the idea of 100000 units on screen at once is weird - 8 pixels each (1024x768)?. It will not be looking good I think. Besides, if you allow the camera to rotate, the sprite soldiers will look just ugly…
Still, good luck!
I agree, I don’t think you’re going to get away with using sprites as the soldiers…they aren’t going to move at all?
what happens if a unit fires an arrow? you’re going to keep binding new textures for the animation on the quad?
given a lot of different units, and the fact that they all won’t be doing the same thing at once (12,000 archers, aren’t all going to be firing arrows at the same exact time - likewise with cavelry and infantry for example) you’d possibly end up thrashing constantly swapping textures in and out.
For objects such as characters in a game, i really think the day of the sprite has passed.
there was a long winded debate about instancing a little while back, it seems this is a perfect candidate for that technique.
Originally posted by Aeluned: given a lot of different units, and the fact that they all won’t be doing the same thing at once (12,000 archers, aren’t all going to be firing arrows at the same exact time - likewise with cavelry and infantry for example) you’d possibly end up thrashing constantly swapping textures in and out
No, he’d have a single texture with all the units frames of animation in it, then simply change the texture coordinates of each unit to access the relevant frame of animation needed. With VBO, he can selectively update bits of a vertex array with minimal performance impact.
Another frig would be to have a separate texture for each viewing angle (to a reasonable angular resolution) and simply change the texture you bind to when the viewing angle changes beyond a certain point. This will give a psuedo solidity to the sprites.
Obviously, when the viewpoint zooms in beyond a certain point you should start to blend in some real geometry, but at that point the majority of your units will have been frustum culled out anyway, so your poly budget remains reasonably constant.
When i say sprites i guess i meant them more in like a voxel kind of capacity a bit like total war and c&c. I want the engine to be able to command 100’000 units although it prolly wont be neccessary to alway have all thos displayed on the screen at once any how, but there would be a time where it could happen.
I did think about using fully poly representation for the units, but iam more focused on making a game then solving graphical problems with openGL (although i respect that solving openGL problems is the bane of this forum!!!).
I think trying to render 100’000 units with polys would provide some serious head aches!
I remember some writing a RTS game with 100’000 units for the Indie Game Jam 2002 and it was alot of fun which is why i wouldnt mind having ago at making something more serious!
the problem i see with 100,000 different ppl is aliasing (as anyone whos done high polygon scenes will tell u)
50,000,000 / 100,000 = 500
50,000,000 reasonable amount (with simple texture shader)
of course u will want it running at more than 1fps (500/20fps) = 25verts a person (enuf?)
i recently tested my card can do ~15,000,000 drawelement calls a second thus the 100,000 is no worries
Originally posted by knackered: Very nice stuff, dorbie. You wrote the renderer?
No I was just part of a team. The engine was in house and established technology. The endo image based rendering was one of the things I implemented while I was there.