Jan 21
Six steps forward, six steps backward
It’s always disappointing to do a lot of work, only to have to undo it again.
I’ve spent the past few hours working on modifying MMORPG Tycoon 2 to keep just one copy of each building model in memory. At the moment, each respawn point that you place (for example) stores its own copy of the respawn point model. This means that memory grows rather a lot, as you place more and more respawn points. The standard solution to this situation is to load the model just once, and then to draw the single model in lots of different places in the world.
In practice, though, actually making that happen can be a little tricky. I’d gone a fair way toward implementing it, before finally realising that the way I was doing it was ugly and difficult; it was going to be a nightmare in the long run. I certainly learned some things from doing it, but it’s always a bit disappointing to end a session of coding by undoing all your changes, and putting things back the way they were before you’d started.
At least I do now have a path forward, and I’ll make a little progress along this new direction before it’s time to sleep. But I would have liked to have some visible results tonight, and it doesn’t seem like that’s going to happen.
Oh well.
January 22nd, 2010 at 3:36 am
Always look at the briiight siide of life! *whistle*
January 22nd, 2010 at 7:15 am
Is this what is referred to as instancing?
January 22nd, 2010 at 7:28 am
Yup, when you have just one copy of a model, and draw it in lots of different parts of the world, those duplicates are called “instances” of the original model.
Another approach to doing a similar task is to render a particular view of a model into a texture, and then paste that texture in lots of different locations within the world. This approach is heaps faster if you have a lot of copies, but can introduce perspective glitches, incorrect clipping against nearby 3D objects, and other problems. Things which are rendering this sort of pre-rasterised view of a 3D object are generally called “imposters”, and were mostly used in the PS2 era. (Trespasser used this approach for most of the objects on its terrain; it was probably the biggest user of imposter technology. But lots of games used imposters in order to make big crowds of people; just render one or two civilian models, then splat the resulting textures all over the place to make a sea of people)
January 24th, 2010 at 8:41 am
I thought instancing was supported by hardware? Or is that only DirectX, because I haven’t seen it in OpenGL or as an extension.
January 24th, 2010 at 11:53 am
Instancing absolutely is supported by hardware, including via OpenGL. But your software has to know what to tell the hardware to do.
Typically, the hardware support for instancing is to allow a game to load a whole bunch of drawing commands and data onto the video card’s memory, and then just have your game tell the card “Hey, remember that big model I told you about a couple minutes ago? Draw it over here. And over there. And in that other spot, rotated like this. And over there.” And so on. It basically saves having to send all that data between the CPU and the GPU separately for each copy of the model each frame; instead, you just send it once sometime earlier on, and then reuse it over and over again.
Under OpenGL, this sort of support is provided via vertex buffer objects (VBOs), and compiled display lists. The popular wisdom these days is to use vertex buffer objects if the current card/driver supports them, and to avoid display lists if possible. For anyone looking at the source code for VectorStorm, my usage of vertex buffer objects is inside VS_GPUBuffer.cpp/h, and compiled display lists are handled inside VS_DisplayList.cpp/h (I really liked this code; it takes an interpreted VectorStorm display list and compiles it into a native OpenGL display list)
Under the new specs for OpenGL 3.0, even vertex buffer objects are being phased out, in preference for the new hot thing: vertex attribute objects (VAOs). I haven’t played with those yet; I expect that VectorStorm will be sticking with its OpenGL 2.x coding style for a fair while, yet.