This image may not look like much to you, but it's the first indication that a complete overhaul of the graphics and physics subsystems of the Freebuild engine are under way.


After devoting quite a few hours to rewriting the rendering code on my own, I decided to completely tear out the existing rendering pipeline and replace it with a high-performance open source solution (that will also more easily integrate with the Bullet physics engine we will use to power the new vehicle/train systems). OpenSceneGraph is an extensible SceneGraph library designed for easy extensibility and high performance rendering. At this point I'm drawing only an empty scene, but the entire GameRenderWorld() method has been replaced with OSG code, and once I write some plugins to support LDraw and Torque art assets, we'll be up and running pretty quickly. I'm hoping that this won't take more than a couple of weeks, but like always, life is busy and we'll see how things progress, and I'll try and post frequent updates on my progress.

Oh yay, development news!

oooh Nice I wanne here more abo9ut this project!

Have you ever played The Better Mod or even original Blockland? Freebuild is a (massively?) multiplayer game with virtual worlds that you can explore but more importantly, build with blocks in! You can also fight with weapons in the DM modes, fly or drive around in vehicles, etc.

Elfprince: Congrats! Are there any sample OSG objects you could randomly throw into the game to see what they look like rendered?

Actually there are, but I'm gonna work instead on getting Torque and LDraw support plugins going in one of the OSG demo applications and then just use that directly in game.

Look, a skybox and some pyramid geometry! Unlike TGE's stock skyboxes, this one is actually being rendered using proper techniques, like Primitives and DrawElements, instead of manually specifying coordinates with a glBegin/End block and individual quad/vertex calls. Also, proper use of GL_TEXTURE_CUBE_MAP

Congrats! I'm very happy to see that this is steadily progressing.

Me too!

I don't suppose you've gotten to the point where you've had large enough scenes to be able to benchmark the performance of the new system, but I hope once you do you'll share your results with us.

As I transition over, some of the coding time is drawn away from the rendering issues to simply integrating the two systems. In addition to writing the skybox code, I also worked on getting the TextureManager to start playing nicely with OSG, and also am working on passing keyboard+mouse input to the OSG input handling functions.

I'll definitely post results when I get them though.

Very nice, carry on then and don't let my questions distract you too much. I am looking extremely forward to playing around with this.

Since you're rewriting the entire rendering and physics systems, I'd like to make a few requests:

* Painted decals on shapes(dts, etc.). Currently decals can only be painted on terrain and interiors. Allowing them to be painted on shapes(and allowing scipters to differentiate between interiors and shapes) would allow for a multitude of things, including bloodstains, bullet-holes, wounds, burns, and less violent things like paintball splats.

* 'Portal' rendering, that is, being able to render and show a different view of the map on a surface, like for security cameras, dimensional gateways, or starship viewscreens.

* Bump-mapping as an option for all surfaces(interior or shape). Simple grayscale heightmaps are all I'd need or use, but if you wanna do full dot3 normals, or even parallax maps, I'm sure some people could make great use of them.

* NPCs. Not sure if this would fall under rendering or physics or something else, but I'd like to be able to create NPCs will full animation, movement, and interaction, without having to simulate an additional client for each one.

* 'lagless movers'. I'm sure this is a physics issue that's already being considered, but I'd like to be able to take a static shape, give it a location and orientation to assume, and the individual clients could do the rest, pretty much eliminating all client-server interaction. Though I'd also like to be able to move/crush/kill players with bricks too, so additional commands would be needed make that possible.

Actually, depending on the results of my work today, it is rather likely that interiors (in their current form) are going away. Do you still have the source models for all the work you've done on FreeBuild (interior and dts)?


This should be pretty trivial to implement through OSG's viewer interface, but it isn't at the top of my priority list.


Again, this isn't high priority, but http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00070.html should make it relatively trivial.


Simulating additional clients (through the AIConnection interface) is actually the cleanest way to do it in a game that allows things like deathmatches, because clients persist after death, and players do not.


This will take a bit of work to implement, but the basic principle (down the line, I'm doing OSG integration first, then Bullet) would be turning a static object into a kinematic object, or a normal physics object with motion constraints, and turning it back into a static one upon reaching it's destination.

<3

But when you have hundreds of simulated clients, the whole game gets slowed down to a crawl. I'm not looking for deathmatch opponents, I'm looking to populate a city, maybe even pit massive armies against each other.

I've rewritten TOB zombie bots for my mod I am making.The zombie bots I rewrote can handle about 50 zombies with 60 bricks and about 5 players.Its not really that the AIConnection doesn't work well,but its improper use.The computer I tested on is about 10 years old.

It occurs to me I could probably fake npcs with kinematic objects, assuming the physics engine is stable and the scripting straight-forward...

Isn't that exactly what AIConnections are for? I feel like if they're not fast enough for you with many, the problem is an inefficiency in the coding of their underlying systems rather than in the fundamental use of them.

Perhaps, but I can't see simulating a client for each and every person in a group a few hundred strong being very efficient. Maybe I'm wrong, and there is a way to get AIConnections to work for that. If so, I'd be more than happy to use it. All I know is, having a few dozen clonebots in a build like my cruise ship makes it nearly unplayable, and I have aspirations of simulating entire cities and armies with this engine in the future.

There are situations where AIPlayer objects without an AIConnection are appropriate, but in a scored deathmatch, that isn't the case. One of the nice things, for example, is that (iirc) players controlled by AIConnections can connect to other servers, which would allow you to distribute the work of processing the movement/behavior logic for your bots over multiple computers. On the other hand, something like a bunch of zombies (who don't need to respawn) chasing a single guy (ala blitz_9100's comment above) would work just fine without an AIConnection, and can still be implemented that way as we have the engine now.

The other thing to check for, especially when you are writing code that has to run frequently or control a lot of separate bots in game is to REALLY thoroughly figure out what the bottlenecks are, and work to reduce them.