VectorStorm Blog

Well.. procedural generation of buildings, anyway;  plenty of other stuff is already being generated procedurally.  There’s not a lot to look at, here, really, but what you’re looking at here are the first three fully procedurally generated buildings in MMORPG Tycoon 2.

While all the geometry that you’ve seen before has been generated on the fly and on demand, it was generated according to explicit instructions that I gave to the geometry generation code.  These here are the first ones generated entirely by the building generation code without my input — they’re the first ones which I didn’t design myself.  Obviously, there’s still an awful lot to be done to make them nicer, but these are the very first ones.

The building on the far left is an inn.  I kind of like that precariously balanced prism on its top!  To its right, those four narrow pillars mark the boundaries of a starting area.  Behind the starting area is a graveyard, which looks almost exactly like a regular “as defined by me” cube graveyard model, except that the procedural generation code seems to have randomly decided to make it about a quarter its usual height.

I’m not certain quite how much latitude to give to the procedural generation code — whether I should be giving it complete freedom (as I have here), or whether I should have some standard building templates which it’s only allowed to make minor variations upon, so that a player can reasonably be expected to distinguish between the different types of building just by sight.

I seem to be getting very little done, the last few days.  However, here’s a quick first pass at getting some simple models in as stand-ins for trees.  Of course, these don’t actually look anything at all like trees;  I’m discovering the limitations of my current procedurally generated model tools.  To turn these things into trees, I need to add the ability to do some branching, to add color/texture, and some randomness.

Still, it’s kind of neat to see things like this breaking up that horizon line a bit.

Today I converted all Region-placed objects in MMORPG Tycoon 2 to render via the region’s octree.  This includes buildings, roads, monsters, player characters, and AI developers.  This basically means that any objects which aren’t at least vaguely in front of the camera won’t use up time being drawn by the graphics card.

The player himself, his GraveShip, and his mouse cursor are not constrained within a single region, and so are still not rendering via an octree.  The terrain itself also is not covered by the octree;  it has its own system for accomplishing a similar task.

Tomorrow I should be able to try out a forest, and see what performance on it is going to be like.  Crossing fingers!

Continuing in my tradition of working on things which can’t have screenshots taken of them…

I’ve recently begun a short-term goal of putting a forest of thousands of trees into MMORPG Tycoon 2.  This task has two obvious sub-tasks, and a few non-obvious sub-tasks.

The obvious sub-tasks are (1) create a tree model — preferably using the procedural geometry creation systems which I’ve already built, so that we can have a couple of different types of trees without any extra labour on my part.  And (2), put lots of copies of those tree models into the world.

The big non-obvious sub-task is that I need to come up with a mechanism so that I won’t be sending every tree in the world to the graphics card to be rendered every frame — only the ones which could potentially be visible right now.  But at the same time, I don’t want the CPU to overload itself, testing each individual tree to see whether it might be visible.

In video games, the usual approach to this sort of problem is to divide up space, and then test the different bits of space for visibility, instead of testing each individual object.  You can think of it a little like arranging lots of small objects on a chess board — instead of checking each tiny object to see whether it could be visible, you instead can check each square of the chess board to see whether that square might be visible, and if so, then draw every object inside that square.

This approach is usually a pretty good compromise between spending a lot of time on the CPU determining precisely what objects will be visible when drawn by the graphics card, and between spending a lot of time on the graphics card drawing objects which turn out not to even have been in front of the camera.

The particular scheme that I’ve just finished implementing today is an “Octree“;  you can think of it a little bit like a chess board where each square contains another whole chess board (except in 3D!).  While I haven’t built any trees yet, I’ve converted the MMORPG buildings over to render through the octree, and tomorrow I’ll spend an hour or two moving several other types of objects over into the octree as well.  Theoretically, the 3D cursor should be a good deal faster to calculate via the octree as well, but I’ll probably leave that optimisation for later on.

But for now, I need to grab some rest.  Didn’t get nearly enough sleep last night!