Bay 12 Games Forum

Ooh, Janus, good one! Thanks, I completely forgot about the icon

At this point I plan to recycle VF's approach, with Perlin noise and everything. Although, I don't know how the difference between his custom renderer and OSG will affect the implementation. I'm pretty sure OSG has their own noise generators, etc.

Just finishing up the DFHack bindings, so that I have something to test the geometry generator on.

I had a nice super long weekend, but work starts again tomorrow, so expect the progress to slow down a wee bit

V0.04

Obsidian now has a DFHack module and can successfully attach to Dwarf Fortress!

That's acceptable usage? Nice
Lemme go set that up.

You see, that's the kind of stuff I had planned for Obsidian!

My original idea (and I've got a large piece of paper with some architectural diagrams on it around here somewhere... *rummage*)
was to have an intermediate format for storing the DF world in. DFHack will be one of the standard loaders for this format, i.e. loading a map directly from DF. But you could make your own loader, i.e. load the map directly from a voxel-based fort editor, etc.
Hell, if Toady has the time/inclination he could even decide to write a DF save file loader for offline visualizing The format will also provide serializers for saving to/loading from storage in whatever format you could shake a stick at.

The reason for an intermediate format is twofold:
1) going the memory dump route would tie each file too closely to the platform - so sharing saved forts between linux, max and windows versions of Obsidian would be a nightmare.
2) An intermediate format can be made version-less and support best-effort implementation by tools.

The second reason needs some explanation - if you take a step back and look at the problem from a different viewpoint (licking a frog might help) we're basically dealing with a highly structured collection of information. You've got a bunch of discrete cells in a 3D cube - each cell has certain base properties and can contain a list of objects (items, creatures, constructions). The cell itself can be assigned to other objects, either singly or in groups (buildings, burrows, etc.) The rest, all of the niggling details, are just the effect of each cell/object having different properties/tags/metadata.

Toady will most likely shift the details around a lot, but the concept of a cube of cells won't change that quickly. So, as long as any tool that uses this format can handle the concept of a cube of cells, it will be able to load a saved/designed fort.

It might not understand all of the properties of a cell/object (Toady might have introduced new building types, or constructions) but it would be able to load it and maybe display a ? mark or something, instead of crashing or throwing a tantrum. And it can write the cells back out after it's work is done, passing through anything it doesn't understand just in case the next tool or a future version of itself will.

Such an intermediate format is an ambitious undertaking, true, but we do that regularly in the games industry ... and as long as you stay away from a few pitfalls it is very definitely doable.

Out of pure curiosity, why choose a sphere?

Is it because of the material display spheres made famous by 3D Studio Max (I think)?

Or was it pure coinkidink?

As for Sizik's statue - if it wins the competition we'll have to go recursive and actually render it with Obsidian (once it can, of course)

I wasn't exactly sure which board is the right one for external utilities (which is distinct from modding the game itself). In the absence of a specialized board, convention is to go with the general.

As to the multiple threads, I did that for separation of concerns - the reason why we have epic multi-hundred page threads is because everyone throws everything in one thread, which is a headache to read through for newcomers.

That said, I have no qualms with moving any of the Obsidian threads to a more suitable board, if such exists.

One thing I think that should be implemented is full camera and scene controls for the user, it'll be a real time GPU-based studio in that sense, so one will be able to add lights, control shadow parameters and even adjust camera perspective and stuff...

I'm playing with the OpenSceneGraph project as my scene manager. It comes with a full Lua binding, so you'll be able to modify everything in the scene (add/remove nodes, set transforms, materials, meshes, move camera) using Lua scripts and interactive commands directly.

This will likely mean a lot of typing, which is the way I roll, but I'm thinking most users will want a GUI. So I'll ponder on how I can set things up so that a GUI frontend can run in-process and send the required LUA commands to the engine. That will be another thing someone can help with (trust me... you don't want to be punished with one of my GUI's)