Horde3D

Thought I'd share some work-in-progress stuff for my project.

When I have more stuff, I'll post it to this thread so as not to spam the forums.

This is just part of my zombie behaviour. Here you see a number of zombies (the darker guys) after the lighter guys (humans). The animation controller isnt working as expected yet, so attack and walk cycles seem a bit bust in the video. Also to be done is seperation of the agents in space (right now there's no collision on them) and baking the various trees and houses etc into the navmesh. But hey, one thing at a time eh!

http://www.vimeo.com/6502931

Although I haven't fully understood, what you are doing with all those funny box characters, I'm always glad to see some demo videos.

Looking good.

Zombies!

_________________

Let's bring 'em out! Any old iron! Any old iron!
A door opens and a homewife brings out a rather sophisticated-looking ground-to-air missile system, and dumps it on the cart.
Thank you.

Looking great so far, I'm looking forward to more.

Ok, this time we have a rather unusual feature. I got sick of the zombies all stacking up on top of each other, but was too lazy to write my own sweep and prune broadphase collision, so I decided to get a little creative. A few hours later I had box2D almost ready.

I had a little bit of a hiccup first

http://www.youtube.com/watch?v=48C8zBlMJHY

Then it finally worked.

http://www.youtube.com/watch?v=QQZ4yzoxWKA

Recommend watching in HD for the glorious rendering.. oh wait. Maybe not.

White guys are called "whitey", Green guys are zombies. Zombies want to eat whitey.

It's so ridiculously cute, cannibalistic boxes.

I really like the "AI debug render" - it's cool seeing all the collision shapes and goals (guessing the blue lines are the agent's goals?)

Blue lines are paths to current target, either position or object. There's a red square at the end (because it looks more interesting). Red circles are collision shapes (box2d).

I'll be adding in sensor spheres next I think. Which should speed up volume queries (currently its a nasty brute force search through a list). There really is a lot to do

Going in for a competition to get some funds to pitch the concept to sony. Will see how that works out. If that happens I'll hire a full-time artist and really start to motor a bit.

Are you currently drawing the debug geometry using direct ogl calls? I ask because we plan to add a horde function to draw debug geometry at some point and it would be good to know what you're requirements for this are. I assume colored/alpha-transparent lines and polygons are enough for you?


Sound good. So you are aiming for PS3?

Yeah, direct OGL calls. One thing that would be nice, would be some way to manage debug render states. Or at least get some idea of what they are. Disabling shaders for instance might be useful in this context.

If the sony pitch thing pays off, its like we'll be going for PSN and PSPGo as the platforms.

We were thinking about a simple high level function which takes a list of vertices (probably indices as well) and draws them as lines or polygons with a configurable color. So you don't have to manage states in your application and the nice thing is that the debug geometry would also work with a different graphics API (e.g. d3d) if Horde gets ported to that.

I'm not sure I'd do that kind of thing with Horde. It'd clutter the interface and most of the debug rendering I've been doing has been from third party libraries. So just turning off shaders and letting me call fixed function calls is a lot easier. The libraries themselves either call GL calls themselves, or provide a callback mechanism where I do the GL calls (i.e. physics libs usually have an interface you can inherit from that recieves callbacks to render specific objects).

So I'd suggest NOT making horde do it. Just because its better to never actually have it in a proper build. If that makes sense?

An alternative would be a utility library that either creates or updates Geometry/Model resources on the fly, which horde can then render.

This accomplishes portable debug rendering and procedural content

If there were debugging features in the API, they could be #ifdef'ed out for "shipping" builds.

This is certainly the more generic and powerful approach. But then we have the problem again that models are persistent in the scene and have to be managed by the user (e.g. removed in the next frame). I think it is in many cases more convenient to just draw a bunch of lines and forget about them after that.

Although it would be certainly a good possibility to simply draw geometry without having to care about the underlaying platform using Horde3D, I also agree with zoombapup, that it would be good, if it's still possible to use fixed function pipeline methods without having to care about saving and restoring OpenGL states. That does not need to be the default case, but for example bullet use OpenGL drawing functions a lot, and porting all those draw calls to Horde3D draw calls means a lot more integration work. And considering the quick updates of bullet, it would save much time if this has not to be done every time.