Dwarf Fortress Wiki - User contributions [en]

Utility Talk:Obsidian/Art

2010-06-16T17:39:02Z

Skeggox: /* Scale */

Let's discuss Obsidian's art here [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 07:54, 11 June 2010 (UTC)

== Scale ==

How should we determine what scale the models should be set to?

I was thinking that we could take the single largest object in the game that fits into one square (or one character on the screen), then decide many units that is in 3D, and then use that scale for everything else. So, like, 1 unit in 3D = _____ meters. Otherwise, we could end up with a chair that is the same size as a whale shark. --[[User:Crunch|Crunch]] 16:44, 11 June 2010 (UTC)

* It won't work that easily. Unfortunately, when it comes to creatures and items, DF is not consistently scaled. For example, you can have more than one 100ft dragon fit in a single 10ftx10ftx10ft cube, along with say, 500 barrels. We'll need to come up with an alternative solution for creature/items. The only real scale value we need to nail down is the height-to-surface aspect ratio (call it R). Since tile surfaces are square, our x:y aspect ratio is 1. That means we can safely set our x and y rendering units to be 1 as well. If we choose R to be 2 (i.e. cells are twice as high as they are wide and long), then we must scale models so that if their boundary box is (-0.5, -0.5, 0) to (0.5, 0.5, 2) (I think a local tile origin placed in the center of the floor will work well) they will fill a cell completely. The value of R will determine how stretched the architecture/models will look along the Z-axis. I recall reading a thread somewhere on the forum about what the right R should be, but I can't recall where. If a consensus was reached, we should use that R, otherwise grab one from VF or determine the best one ourselves. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

* To give an example: let's assume that average-sized Urist is 4ft tall (a good dwarfy height). Then we choose cells to be 5ftx5ftx10ft: that means Urist will be able to lay down on the floor of a single-tile tunnel without touching either wall, and have his twin brother Tsiru stand on his head and still have 2ft headroom. That also means the generic dwarf model needs to have the top of its head be at around 0.8 (4ft/10ft * 2) rendering units. I would prefer that we define our rendering unit length to be equal to unit cell size; that will simplify geometry generation code quite a bit. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

* Thinking about it, we could try making R equal to the Golden Ratio? What do you think? [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

* One way of handling the infinite-packing-of-items/creatures-into-a-tile is to pick the most important object (one of the dragons instead of one of the 500 barrels, say) and only render that single object. If the chosen object is larger than a cube (like a dragon), we can scan the surrounding cells to see how much space we have available and then try and scale the model up to its real size. We could also have contextual models - a dragon in the open will rear up and spread it's wings, but in a tunnel will stay low to the ground with its wings folded flat. Just a thought... [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 20:05, 11 June 2010 (UTC)

* Hmm, first let's use metric for universality's sake. For the R problems, I beleive this will need a good bunch of empirical tinkering so we can come up with a sensible value. The problem is that even if the DF tiles were perfectly cubic, stuff would look weird as terrain, stairs and construction ramps would be damn 45° inclines (not bad if you wanna make a norse church though). A smaller than one R would probably be closer to realistic approaches, however it would make stuff such as chairs, beds, tables and barrels look incredbly small and isolated from each other. What we can know of the size of each DF hypercell is that they are divided in-game on 7 levels, which are its water level gradient. We could infer the rough height of each cell (which is quite small it seems.) A possible way of solving such problems would be giving the end-user control over the R. This would involve making most tile-centered geometry dynamic, which could get messy to make stairs geometry, however it would suit everyone's tastes. The problem with the lonely isolated barrel would be solved with my next idea.--[[User:Djohaal|Djohaal was here.]] 02:38, 13 June 2010 (UTC)

* Metric it is, then. A variable R is a good idea - I have no problem with creating procedural generators for some of the cell-geometry, like stairs. VF procedurally generates stairs, fortifications, etc. already. Also, I don't think the 7 liquid levels have anything to do with the cell size - Toady likely chose 7 because that uses only 3 bits per tile, leaving him with another 5 to specify type of liquid, et. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 17:39, 16 June 2010 (UTC)

== Procedurally Generated Models ==

Will Obsidian know everything about ''everything'' about the game, or just the stuff seen from the visual tiles? In other words, will it know that Urist McMiner has green eyes, a convex nose, brown hair, and that he likes to take long walks on the beach?
* Obsidian will know whatever DFHack can get from Dwarf Fortress, so that is out of my control unfortunately. But Peterix is hard at work on figuring out stuff like that, so the chances are good. Otherwise, one could probably devise a DFHack-based tool that takes a text screen capture of a dwarf description, then parse the text to get the particulars (fairly hacky, but it will work). [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

If so, maybe we could make dynamic models of of the miners, with an assortment of possible beard, nose, hair, ear, etc. models, that then get cobbled together based on the description. We'd first need to know the range of possibilities for each aspect, though... and I'm not sure where to find that.
* Check the DF wiki - search for attributes. Someone will have a list of all of that up by now ;) Procedurally combining sub models looks easy enough, especially if we use OSG's animation support to add bones to the basic dwarf model - then the Lua script can be used to attach the correct beard submodel to the chin bone, etc. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

We could also do something similar with statues, and items have have been encrusted with jewels, etc...
* Hell yeah. I was also thinking of stamping engraving designs into the base texture and bump maps for engraved walls/floors, to get a kind of bass-relief effect going, but that will have to wait until the DFHack guys figure out where engravings are stored in DF's memory. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)
--[[User:Crunch|Crunch]] 17:03, 11 June 2010 (UTC)

*Yeah, the engravings thing would be awesome, we could use the basic graphics DF uses for each engraving. For statues and such, it would be relatively easy (if DFhack can read what each statue is), we could use un-posed geometry of animals or such but with the material texture. As a whole I think we should leave charachter posing to a far goal, if a goal at all, maybe just static models... I personally have no skill with skeleton and posing, all I know is that it is a messy job. I can already picture my graveyard lined with statues of donkeys though.... lol. One thing that we could implement to help users to better control how their forts are displayed would be a "prop" editing interface. One could pick any object (walls included and such) and edit what they look like or which material they are made a posteriori, allowing for users to change statues which they don't like and fix problems such as two different materials (say, gabbro, diorite, obsidian and slate) being similar in-game however looking different on the texture set. Maybe an eyedropper and paint state tool could be used to ease mass fixing of such issues. Placing additional props manually (and perhaps without being bound to the mother grid, or being bound to a far finer grid) would allow for users to make more crowded-looking stockpiles and such if R < 1 and do scenic stuff such as a bunch of discarded, bloody swords after a battle scene or a tantrum spiral in the main hall. One thing that would be vital on this is giving the user full control over the transforms (position, rotation and scale, just like a mini-CAD) of props, that could lead to interesting effects and never-thought of usage of items, not to mention solving the problem with figuring out which side a chair must face when it is surrounded by tables, the user will choose. We could even include non-DF-canon props (and perhaps a way of placing them easily) such as torches and stuff, so at end obsidian would look like a furnish-your-own-fort tool. Might sound like a dollhouse (simdorf anyone? lol) but I think a lot of people would enjoy hand-crafting every square milimeter of their forts to their heart's content. This also has important implications should skegg decide to implement that, since this means obsidian will need to have support to transform manipulation after a scene is read and being able to handle all this data not only in view mode but as saves and such. These wiki mega-paragraphs confuse me, and if my text got confusing someone poke me and I'll send a better written version of this mess on PM --[[User:Djohaal|Djohaal was here.]] 03:00, 13 June 2010 (UTC)

*Oh, god. [[Planepacked|FML]]. --[[User:Crunch|Crunch]] 18:10, 14 June 2010 (UTC)

* D, you can always split your paragraphs :) I agree with the post-editing, and I've designed the save/load format specifically to be extensible - so that adding scene info (transforms etc.) will be easy :) [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 17:34, 16 June 2010 (UTC)

== Textures ==

Here's a neat free [http://www.dualheights.se/caustics/ caustics texture generator] that I found recently. It'd probably come in handy for underground environments that have water involved (to simulate light reflections on the walls and roof, and for the light that hits the ground under the surface of the water). And it's free. --[[User:Crunch|Crunch]] 17:18, 11 June 2010 (UTC)

While this is quite useful, I don't beleive we'll need such luxury for hardware rendering. The future-who-knows-when POVray mode would do the light job automagically, so this wouldn't be needed either... I'm tinkering how would we implement a raytracer snapshot function to obsidian, however there are some big issues which would need either user intervetion or incredbly smart coding, but I'll save that to once we can render a fort on openGL :P --[[User:Djohaal|Djohaal was here.]] 02:42, 13 June 2010 (UTC)

Utility Talk:Obsidian/Art

2010-06-16T17:34:48Z

Skeggox: /* Procedurally Generated Models */

Let's discuss Obsidian's art here [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 07:54, 11 June 2010 (UTC)

== Scale ==

How should we determine what scale the models should be set to?

I was thinking that we could take the single largest object in the game that fits into one square (or one character on the screen), then decide many units that is in 3D, and then use that scale for everything else. So, like, 1 unit in 3D = _____ meters. Otherwise, we could end up with a chair that is the same size as a whale shark. --[[User:Crunch|Crunch]] 16:44, 11 June 2010 (UTC)

* It won't work that easily. Unfortunately, when it comes to creatures and items, DF is not consistently scaled. For example, you can have more than one 100ft dragon fit in a single 10ftx10ftx10ft cube, along with say, 500 barrels. We'll need to come up with an alternative solution for creature/items. The only real scale value we need to nail down is the height-to-surface aspect ratio (call it R). Since tile surfaces are square, our x:y aspect ratio is 1. That means we can safely set our x and y rendering units to be 1 as well. If we choose R to be 2 (i.e. cells are twice as high as they are wide and long), then we must scale models so that if their boundary box is (-0.5, -0.5, 0) to (0.5, 0.5, 2) (I think a local tile origin placed in the center of the floor will work well) they will fill a cell completely. The value of R will determine how stretched the architecture/models will look along the Z-axis. I recall reading a thread somewhere on the forum about what the right R should be, but I can't recall where. If a consensus was reached, we should use that R, otherwise grab one from VF or determine the best one ourselves. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

* To give an example: let's assume that average-sized Urist is 4ft tall (a good dwarfy height). Then we choose cells to be 5ftx5ftx10ft: that means Urist will be able to lay down on the floor of a single-tile tunnel without touching either wall, and have his twin brother Tsiru stand on his head and still have 2ft headroom. That also means the generic dwarf model needs to have the top of its head be at around 0.8 (4ft/10ft * 2) rendering units. I would prefer that we define our rendering unit length to be equal to unit cell size; that will simplify geometry generation code quite a bit. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

* Thinking about it, we could try making R equal to the Golden Ratio? What do you think? [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

* One way of handling the infinite-packing-of-items/creatures-into-a-tile is to pick the most important object (one of the dragons instead of one of the 500 barrels, say) and only render that single object. If the chosen object is larger than a cube (like a dragon), we can scan the surrounding cells to see how much space we have available and then try and scale the model up to its real size. We could also have contextual models - a dragon in the open will rear up and spread it's wings, but in a tunnel will stay low to the ground with its wings folded flat. Just a thought... [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 20:05, 11 June 2010 (UTC)

* Hmm, first let's use metric for universality's sake. For the R problems, I beleive this will need a good bunch of empirical tinkering so we can come up with a sensible value. The problem is that even if the DF tiles were perfectly cubic, stuff would look weird as terrain, stairs and construction ramps would be damn 45° inclines (not bad if you wanna make a norse church though). A smaller than one R would probably be closer to realistic approaches, however it would make stuff such as chairs, beds, tables and barrels look incredbly small and isolated from each other. What we can know of the size of each DF hypercell is that they are divided in-game on 7 levels, which are its water level gradient. We could infer the rough height of each cell (which is quite small it seems.) A possible way of solving such problems would be giving the end-user control over the R. This would involve making most tile-centered geometry dynamic, which could get messy to make stairs geometry, however it would suit everyone's tastes. The problem with the lonely isolated barrel would be solved with my next idea.--[[User:Djohaal|Djohaal was here.]] 02:38, 13 June 2010 (UTC)

== Procedurally Generated Models ==

Will Obsidian know everything about ''everything'' about the game, or just the stuff seen from the visual tiles? In other words, will it know that Urist McMiner has green eyes, a convex nose, brown hair, and that he likes to take long walks on the beach?
* Obsidian will know whatever DFHack can get from Dwarf Fortress, so that is out of my control unfortunately. But Peterix is hard at work on figuring out stuff like that, so the chances are good. Otherwise, one could probably devise a DFHack-based tool that takes a text screen capture of a dwarf description, then parse the text to get the particulars (fairly hacky, but it will work). [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

If so, maybe we could make dynamic models of of the miners, with an assortment of possible beard, nose, hair, ear, etc. models, that then get cobbled together based on the description. We'd first need to know the range of possibilities for each aspect, though... and I'm not sure where to find that.
* Check the DF wiki - search for attributes. Someone will have a list of all of that up by now ;) Procedurally combining sub models looks easy enough, especially if we use OSG's animation support to add bones to the basic dwarf model - then the Lua script can be used to attach the correct beard submodel to the chin bone, etc. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)

We could also do something similar with statues, and items have have been encrusted with jewels, etc...
* Hell yeah. I was also thinking of stamping engraving designs into the base texture and bump maps for engraved walls/floors, to get a kind of bass-relief effect going, but that will have to wait until the DFHack guys figure out where engravings are stored in DF's memory. [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 19:58, 11 June 2010 (UTC)
--[[User:Crunch|Crunch]] 17:03, 11 June 2010 (UTC)

*Yeah, the engravings thing would be awesome, we could use the basic graphics DF uses for each engraving. For statues and such, it would be relatively easy (if DFhack can read what each statue is), we could use un-posed geometry of animals or such but with the material texture. As a whole I think we should leave charachter posing to a far goal, if a goal at all, maybe just static models... I personally have no skill with skeleton and posing, all I know is that it is a messy job. I can already picture my graveyard lined with statues of donkeys though.... lol. One thing that we could implement to help users to better control how their forts are displayed would be a "prop" editing interface. One could pick any object (walls included and such) and edit what they look like or which material they are made a posteriori, allowing for users to change statues which they don't like and fix problems such as two different materials (say, gabbro, diorite, obsidian and slate) being similar in-game however looking different on the texture set. Maybe an eyedropper and paint state tool could be used to ease mass fixing of such issues. Placing additional props manually (and perhaps without being bound to the mother grid, or being bound to a far finer grid) would allow for users to make more crowded-looking stockpiles and such if R < 1 and do scenic stuff such as a bunch of discarded, bloody swords after a battle scene or a tantrum spiral in the main hall. One thing that would be vital on this is giving the user full control over the transforms (position, rotation and scale, just like a mini-CAD) of props, that could lead to interesting effects and never-thought of usage of items, not to mention solving the problem with figuring out which side a chair must face when it is surrounded by tables, the user will choose. We could even include non-DF-canon props (and perhaps a way of placing them easily) such as torches and stuff, so at end obsidian would look like a furnish-your-own-fort tool. Might sound like a dollhouse (simdorf anyone? lol) but I think a lot of people would enjoy hand-crafting every square milimeter of their forts to their heart's content. This also has important implications should skegg decide to implement that, since this means obsidian will need to have support to transform manipulation after a scene is read and being able to handle all this data not only in view mode but as saves and such. These wiki mega-paragraphs confuse me, and if my text got confusing someone poke me and I'll send a better written version of this mess on PM --[[User:Djohaal|Djohaal was here.]] 03:00, 13 June 2010 (UTC)

*Oh, god. [[Planepacked|FML]]. --[[User:Crunch|Crunch]] 18:10, 14 June 2010 (UTC)

* D, you can always split your paragraphs :) I agree with the post-editing, and I've designed the save/load format specifically to be extensible - so that adding scene info (transforms etc.) will be easy :) [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 17:34, 16 June 2010 (UTC)

== Textures ==

Here's a neat free [http://www.dualheights.se/caustics/ caustics texture generator] that I found recently. It'd probably come in handy for underground environments that have water involved (to simulate light reflections on the walls and roof, and for the light that hits the ground under the surface of the water). And it's free. --[[User:Crunch|Crunch]] 17:18, 11 June 2010 (UTC)

While this is quite useful, I don't beleive we'll need such luxury for hardware rendering. The future-who-knows-when POVray mode would do the light job automagically, so this wouldn't be needed either... I'm tinkering how would we implement a raytracer snapshot function to obsidian, however there are some big issues which would need either user intervetion or incredbly smart coding, but I'll save that to once we can render a fort on openGL :P --[[User:Djohaal|Djohaal was here.]] 02:42, 13 June 2010 (UTC)

Utility:Obsidian

2010-06-13T17:56:52Z

Skeggox: /* Credits */

=Obsidian=
[[File:obsidianicon.png|thumb|right]]

'''Please note this tool is not complete and cannot render dwarf fortress. It is in development.'''

Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and raytracers.

Its a modular Lua framework, using Open Scene Graph for rendering and DFHack for talking with Dwarf Fortress.

This [http://www.bay12forums.com/smf/index.php?topic=57920.0 forum thread] has more detail.

=Screen shots=
[[File:obsidian_v_0.01.png|100px|Obsidian V0.01]]
[[File:obsidian_v_0.02.png|100px|Obsidian V0.02]]
[[File:obsidian_v_0.03.png|100px|Obsidian V0.03]]
[[File:obsidian_v_0.04.png|100px|Obsidian V0.04]]

=[[Utility:Obsidian/Art | Art]]=
Obsidian's art will be contributed by the community. Follow the section title to a page with more details on how you can contribute.

=Credits=
* Technical lead programmer - Skeggox
* Art Director - GFXiNXS
* 3D artists - Djohaal, opsneakie, Crunch
* Icon design - Janus

=Technical Info=
==[[Utility:Obsidian/Cell definition files | Cell Engine]]==
This is a structured representation of a DF fortress (technically a cellular automata with metadata) in C++. It provides XML and binary serializers by default, as well as Lua bindings. All of the code is generated from XML definition files, which represents all of the information we know about Dwarf Fortress

Utility Talk:Obsidian/Art

2010-06-11T20:34:45Z

Skeggox: /* Scale */

Utility Talk:Obsidian/Art

2010-06-11T20:31:17Z

Skeggox: /* Scale */

Utility Talk:Obsidian/Art

2010-06-11T20:05:02Z

Skeggox: /* Scale */

Utility Talk:Obsidian/Art

2010-06-11T19:59:13Z

Skeggox: /* Scale */

Utility Talk:Obsidian/Art

2010-06-11T19:58:45Z

Skeggox:

Utility Talk:Obsidian/Art

2010-06-11T07:54:36Z

Skeggox: Created page with 'Let's discuss Obsidian's art here ~~~~'

Let's discuss Obsidian's art here [[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 07:54, 11 June 2010 (UTC)

Utility:Obsidian/Art

2010-06-10T23:26:51Z

Skeggox:

* Textures and models for Obsidian must be renderable by OpenSceneGraph. Use [http://osgedit.sourceforge.net/ OSGEdit] to test it.
* A link to a repository for accepted art will be provided a bit later.
* Non-original art contributed to Obsidian '''must not be copyrighted''', or '''must be distributable publicly under a free-art type of licence'''
* Original art will be accepted on the condition that it is distributable under a free-art type licence (exact licence to be determined later)

If you have suitable art to contribute against an objective, add a list entry in the Candidate section with the same name as the objective, and make it a link to the candidate art files. Multiple candidates per objective is allowed, so that the art director (once we choose one ;) can make the final selection and move them to the Accepted section.

The current art will go towards the primary Obsidian art pack. The style for this art pack is realism - how realistic can we render a Dwarf Fortress map? Textures should be as photo-realistic as possible, models should represent 15th (is that the best time period for DF?) century objects and architecture.

Later we can add additional art packs containing different visual styles (cartoony, gritty, psychedelic, etc.) and architectural styles (fantasy, eastern, gothic, etc.)

==Textures==
The generic versions will be the default textures used when no specific versions exist.
===Requirements===
* If a texture is marked (tintable) it needs to be color-neutral enough to allow for shader-tinting to a DF color (one of the basic 16). This will give us good variety without needing masses of textures.
* Textures should include bump maps
* You can provide hand-tuned mipmap versions if you prefer, otherwise OSG will generate them automatically
* Texture size must be power-of-2 and square: Ideally 512x512 (or larger?)

===Ideas===
* Would it be possible to stamp a design onto both the texture and bump map for a stone type, to achieve the effect of bass-relief engravings?

===Objectives===
====Stone====
* Generic version (tintable)
====Wood====
* Generic version (tintable)
====Metal====
* Generic version (tintable)
====Glass====
* Green (transparent)
* Clear (transparent)
* Crystal (transparent)

===In Progress===
{| border="1"
|-
! Owner
! Objective
! Progress
|-
|}
===Accepted===

==Models==
===Requirements===
* Try to keep a low polycount. Providing multiple LOD versions is highly recommended.
* Animations are allowed, but only if you can get the model to animate correctly in an [http://osgedit.sourceforge.net/ OSGEdit] scene
===Objectives===
====Statue====
* Generic version, (opened and closed)
====Draw bridge====
* Generic version, (opened and closed)
====Door====
* Generic version, (opened and closed)
====Floor hatch====
* Generic version, (opened and closed)
====Flood gate====
* Generic version, (opened and closed)
====Grate====
* Generic version, (opened and closed)
====Cage====
* Generic version, (opened and closed)
====Cage====
* Generic version, (opened and closed)

===In Progress===
{| border="1"
|-
! Owner
! Objective
! Progress
|-
|}

===Accepted===

Utility:Obsidian

2010-06-10T18:41:01Z

Skeggox:

=Obsidian=
[[File:obsidianicon.png|thumb|right]]
Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and raytracers.

Its a modular Lua framework, using Open Scene Graph for rendering and DFHack for talking with Dwarf Fortress.

This [http://www.bay12forums.com/smf/index.php?topic=57920.0 forum thread] has more detail.

=Screen shots=
[[File:obsidian_v_0.01.png|100px|Obsidian V0.01]]
[[File:obsidian_v_0.02.png|100px|Obsidian V0.02]]
[[File:obsidian_v_0.03.png|100px|Obsidian V0.03]]
[[File:obsidian_v_0.04.png|100px|Obsidian V0.04]]

=[[Utility:Obsidian/Art | Art]]=
Obsidian's art will be contributed by the community. Follow the section title to a page with more details on how you can contribute.

=Credits=
* Technical lead programmer - Skeggox
* 3D artists - Djohaal, opsneakie
* Icon design - Janus

=Technical Info=
==[[Utility:Obsidian/Cell definition files | Cell Engine]]==
This is a structured representation of a DF fortress (technically a cellular automata with metadata) in C++. It provides XML and binary serializers by default, as well as Lua bindings. All of the code is generated from XML definition files, which represents all of the information we know about Dwarf Fortress

Utility:Obsidian

2010-06-10T18:40:30Z

Skeggox:

=Obsidian=
[[File:obsidianicon.png|thumb|right]]
Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and raytracers.

Its a modular Lua framework, using Open Scene Graph for rendering and DFHack for talking with Dwarf Fortress.

This [http://www.bay12forums.com/smf/index.php?topic=57920.0 forum thread] has more detail.

=Screen shots=
[[File:obsidian_v_0.01.png|100px|Obsidian V0.01]]
[[File:obsidian_v_0.02.png|100px|Obsidian V0.02]]
[[File:obsidian_v_0.03.png|100px|Obsidian V0.03]]
[[File:obsidian_v_0.04.png|100px|Obsidian V0.04]]

=Credits=
* Technical lead programmer - Skeggox
* 3D artists - Djohaal, opsneakie
* Icon design - Janus

=Technical Info=
==[[Utility:Obsidian/Cell definition files | Cell Engine]]==
This is a structured representation of a DF fortress (technically a cellular automata with metadata) in C++. It provides XML and binary serializers by default, as well as Lua bindings. All of the code is generated from XML definition files, which represents all of the information we know about Dwarf Fortress

==[[Utility:Obsidian/Art | Art]]==
Obsidian's art will be contributed by the community. Follow the section title to a page with more details on how you can contribute.

Utility:Obsidian/Art

2010-06-10T18:40:12Z

Skeggox: Created page with '* Textures and models for Obsidian must be renderable by OpenSceneGraph. Use [http://osgedit.sourceforge.net/ OSGEdit] to test it. * A link to a repository for accepted art will …'

* Textures and models for Obsidian must be renderable by OpenSceneGraph. Use [http://osgedit.sourceforge.net/ OSGEdit] to test it.
* A link to a repository for accepted art will be provided a bit later.
* Non-original art contributed to Obsidian '''must not be copyrighted''', or be '''distributable publicly under a free-art type of licence'''
* Original art will be accepted on the condition that it is distributable under a free-art type licence (exact licence to be determined later)

If you have suitable art to contribute against an objective, add a list entry in the Candidate section with the same name as the objective, and make it a link to the candidate art files. Multiple candidates per objective is allowed, so that the art director (once we choose one ;) can make the final selection and move them to the Accepted section.

The current art will go towards the primary Obsidian art pack. The style for this art pack is realism - how realistic can we render a Dwarf Fortress map? Textures should be as photo-realistic as possible, models should represent 15th (is that the best time period for DF?) century objects and architecture.

Later we can add additional art packs containing different visual styles (cartoony, gritty, psychedelic, etc.) and architectural styles (fantasy, eastern, gothic, etc.)

==Textures==
The generic versions will be the default textures used when no specific versions exist.
===Requirements===
* If a texture is marked (tintable) it needs to be color-neutral enough to allow for shader-tinting to a DF color (one of the basic 16). This will give us good variety without needing masses of textures.
* Textures should include bump maps
* You can provide hand-tuned mipmap versions if you prefer, otherwise OSG will generate them automatically
* Texture size must be power-of-2 and square: Ideally 512x512 (or larger?)

===Ideas===
* Would it be possible to stamp a design onto both the texture and bump map for a stone type, to achieve the effect of bass-relief engravings?

===Objectives===
====Stone====
* Generic version (tintable)
====Wood====
* Generic version (tintable)
====Metal====
* Generic version (tintable)
====Glass====
* Green (transparent)
* Clear (transparent)
* Crystal (transparent)

===In Progress===
{| border="1"
|-
! Owner
! Objective
! Progress
|-
|}
===Accepted===

==Models==
===Requirements===
* Try to keep a low polycount. Providing multiple LOD versions is highly recommended.
* Animations are allowed, but only if you can get the model to animate correctly in an [http://osgedit.sourceforge.net/ OSGEdit] scene
===Objectives===
====Statue====
* Generic version, (opened and closed)
====Draw bridge====
* Generic version, (opened and closed)
====Door====
* Generic version, (opened and closed)
====Floor hatch====
* Generic version, (opened and closed)
====Flood gate====
* Generic version, (opened and closed)
====Grate====
* Generic version, (opened and closed)
====Cage====
* Generic version, (opened and closed)
====Cage====
* Generic version, (opened and closed)

===In Progress===
{| border="1"
|-
! Owner
! Objective
! Progress
|-
|}

===Accepted===

Utility:Obsidian/Cell definition files

2010-05-30T03:51:04Z

Skeggox:

This page contains technical information about the [[Utility:Obsidian | Obsidian visualizer]]

This list of files define the internal representation of the Cell engine, to be exposed to Lua and used by other modules (like the geometry generator or terrain exporters)

==Fortress==
This describes the top level object that holds all of the components like terrain, creatures, etc., as well as static information about the fortress.
<pre>
<class name="Fortress" api="yes">
<ctor/>



<property name="SizeX" type="Int32" default="16">
<get/>
</property>

<property name="SizeY" type="Int32" default="16">
<get/>
</property>

<property name="SizeZ" type="Int32" default="16">
<get/>
</property>

<vector name="Maps" type="Map">
<note>A fortress can have multiple maps, to represent timestamps of the fortress terrain over time</note>
<get_index/>
<size/>
<push_back/>
</vector>

<vector name="Materials" type="Material">
<get_index/>
</vector>

<method name="LoadFromDF">
<return type="Void"/>
</method>
</class>
</pre>

==Map==
This just a a collection of cells that describes the current map. Maps have a timestamp, so a fortress can hold multiple map instances to represent the development of the fortress over time
<pre>
<class name="Map" api="yes">
<ctor/>

<reference name="Fortress" type="Fortress">
<get/>
</reference>

<property name="TimeStamp" type="ROString">
<get/>
</property>

<array name="Cells" type="Cell">
<dimension name="x" size="Fortress.SizeX"/>
<dimension name="y" size="Fortress.SizeY"/>
<dimension name="z" size="Fortress.SizeZ"/>
<get_index/>
<set_index/>
</array>

<property name="OpenSpace" type="Cell">
<note>This is a readonly cell representing the default OpenSpace cell</note>
<get/>
</property>
</class>
</pre>

==Cell==
Each cell holds everything that you need to know about a specific tile in the fortress, including a reference to the terrain type, a reference to any building or construction that occupies that space, as well as lists of items, contaminants, liquids and creatures in that tile.
<pre>
<class name="Cell" api="yes">
<ctor/>

<reference name="Map" type="Map">
<get/>
</reference>

<property name="PosX" type="Int32" default="-1">
<get/>
</property>

<property name="PosY" type="Int32" default="-1">
<get/>
</property>

<property name="PosZ" type="Int32" default="-1">
<get/>
</property>

<reference name="Terrain" type="Terrain">
<note>I'm assuming that the all of the terrain information can be encapsulated in a terrain type. Changing the terrain will be done through the Map object</note>
<get/>
</property>

<reference name="Construction" type="Construction">
<note>I'm assuming only one construction can exist in a cell at a time. Changing the construction will be done through the Map object</note>
<get/>
</list>

<list name="Items" type="Item" reference="yes">
<note>Should the cell own the items, or just reference them?</note>
<get/>
</list>

<reference name="Building" type="Building">
<note>Placing/removing buildings via the Map object will handle attaching/detaching themselves from the cell</note>
<get/>
</reference>

<internal>
<reference name="Top" type="Cell"/>
<reference name="Bottom" type="Cell"/>
<reference name="Left" type="Cell"/>
<reference name="Right" type="Cell"/>
<reference name="Up" type="Cell"/>
<reference name="Down" type="Cell"/>
</internal>
</class>
</pre>

Utility Talk:Obsidian/Cell definition files

2010-05-30T03:50:04Z

Skeggox:

Right, so that is my first off-the-top-of-the-head idea of how the intermediate format/representation will look.
Issues to discuss:
* How to handle items - does the map own the items and each cell has a list of references, or does the cells own the items and then the map can generate a global list on request by iterating over each cell?
* From what I've seen of DFHack's interface, each tile contains designations and flags that describes the terrain in that tile. Duplicating all of that information in each cell will be a space and compatibility nightmare. So I'm going to have a list of terrain types exist separately in the map and each cell just points to the one it currently has. This list will be built up as the tile information is read from DF, using a hash of all of the terrain properties as the unique key. So, can anyone explain how to figure out what a tile's terrain is, so that I can construct the Terrain class?
[[User:Skeggox|No fort is complete without magma... and water... and then some FUN.]] 03:50, 30 May 2010 (UTC)

User:Skeggox

2010-05-30T03:49:36Z

Skeggox: Created page with '==Info== Male, youngish, Computer Engineer, blacksmith, axe-fighter and I have a long beard. Alas, I am too tall to be considered a dwarf, but otherwise I'm close. ==Projects== …'

==Info==
Male, youngish, Computer Engineer, blacksmith, axe-fighter and I have a long beard. Alas, I am too tall to be considered a dwarf, but otherwise I'm close.

==Projects==
[[Utility:Obsidian | Obsidian visualizer]]

Utility Talk:Obsidian/Cell definition files

2010-05-30T03:46:07Z

Skeggox: Created page with 'Right, so that is my first off-the-top-of-the-head idea of how the intermediate format/representation will look. Issues to discuss: * How to handle items - does the map own the i…'

Utility:Obsidian/Cell definition files

2010-05-30T03:37:54Z

Skeggox:

This list of files define the internal representation of the Cell engine, to be exposed to Lua and used by other modules (like the geometry generator or terrain exporters)

==Fortress==
This describes the top level object that holds all of the components like terrain, creatures, etc., as well as static information about the fortress.
<pre>
<class name="Fortress" api="yes">
<ctor/>



<property name="SizeX" type="Int32" default="16">
<get/>
</property>

<property name="SizeY" type="Int32" default="16">
<get/>
</property>

<property name="SizeZ" type="Int32" default="16">
<get/>
</property>

<vector name="Maps" type="Map">
<note>A fortress can have multiple maps, to represent timestamps of the fortress terrain over time</note>
<get_index/>
<size/>
<push_back/>
</vector>

<vector name="Materials" type="Material">
<get_index/>
</vector>

<method name="LoadFromDF">
<return type="Void"/>
</method>
</class>
</pre>

==Map==
This just a a collection of cells that describes the current map. Maps have a timestamp, so a fortress can hold multiple map instances to represent the development of the fortress over time
<pre>
<class name="Map" api="yes">
<ctor/>

<reference name="Fortress" type="Fortress">
<get/>
</reference>

<property name="TimeStamp" type="ROString">
<get/>
</property>

<array name="Cells" type="Cell">
<dimension name="x" size="Fortress.SizeX"/>
<dimension name="y" size="Fortress.SizeY"/>
<dimension name="z" size="Fortress.SizeZ"/>
<get_index/>
<set_index/>
</array>

<property name="OpenSpace" type="Cell">
<note>This is a readonly cell representing the default OpenSpace cell</note>
<get/>
</property>
</class>
</pre>

==Cell==
Each cell holds everything that you need to know about a specific tile in the fortress, including a reference to the terrain type, a reference to any building or construction that occupies that space, as well as lists of items, contaminants, liquids and creatures in that tile.
<pre>
<class name="Cell" api="yes">
<ctor/>

<reference name="Map" type="Map">
<get/>
</reference>

<property name="PosX" type="Int32" default="-1">
<get/>
</property>

<property name="PosY" type="Int32" default="-1">
<get/>
</property>

<property name="PosZ" type="Int32" default="-1">
<get/>
</property>

<reference name="Terrain" type="Terrain">
<note>I'm assuming that the all of the terrain information can be encapsulated in a terrain type. Changing the terrain will be done through the Map object</note>
<get/>
</property>

<reference name="Construction" type="Construction">
<note>I'm assuming only one construction can exist in a cell at a time. Changing the construction will be done through the Map object</note>
<get/>
</list>

<list name="Items" type="Item" reference="yes">
<note>Should the cell own the items, or just reference them?</note>
<get/>
</list>

<reference name="Building" type="Building">
<note>Placing/removing buildings via the Map object will handle attaching/detaching themselves from the cell</note>
<get/>
</reference>

<internal>
<reference name="Top" type="Cell"/>
<reference name="Bottom" type="Cell"/>
<reference name="Left" type="Cell"/>
<reference name="Right" type="Cell"/>
<reference name="Up" type="Cell"/>
<reference name="Down" type="Cell"/>
</internal>
</class>
</pre>

Utility:Obsidian/Cell definition files

2010-05-30T03:37:00Z

Skeggox: Added the cell definition file

=Cell definition files=
This list of files represent the internal representation of the Cell engine, to be exposed to Lua and used by other modules (like the geometry generator)

==Fortress==
This describes the top level object that holds all of the components like terrain, creatures, etc., as well as static information about the fortress.
<pre>
<class name="Fortress" api="yes">
<ctor/>



<property name="SizeX" type="Int32" default="16">
<get/>
</property>

<property name="SizeY" type="Int32" default="16">
<get/>
</property>

<property name="SizeZ" type="Int32" default="16">
<get/>
</property>

<vector name="Maps" type="Map">
<note>A fortress can have multiple maps, to represent timestamps of the fortress terrain over time</note>
<get_index/>
<size/>
<push_back/>
</vector>

<vector name="Materials" type="Material">
<get_index/>
</vector>

<method name="LoadFromDF">
<return type="Void"/>
</method>
</class>
</pre>

==Map==
This just a a collection of cells that describes the current map. Maps have a timestamp, so a fortress can hold multiple map instances to represent the development of the fortress over time
<pre>
<class name="Map" api="yes">
<ctor/>

<reference name="Fortress" type="Fortress">
<get/>
</reference>

<property name="TimeStamp" type="ROString">
<get/>
</property>

<array name="Cells" type="Cell">
<dimension name="x" size="Fortress.SizeX"/>
<dimension name="y" size="Fortress.SizeY"/>
<dimension name="z" size="Fortress.SizeZ"/>
<get_index/>
<set_index/>
</array>

<property name="OpenSpace" type="Cell">
<note>This is a readonly cell representing the default OpenSpace cell</note>
<get/>
</property>
</class>
</pre>

==Cell==
Each cell holds everything that you need to know about a specific tile in the fortress, including a reference to the terrain type, a reference to any building or construction that occupies that space, as well as lists of items, contaminants, liquids and creatures in that tile.
<pre>
<class name="Cell" api="yes">
<ctor/>

<reference name="Map" type="Map">
<get/>
</reference>

<property name="PosX" type="Int32" default="-1">
<get/>
</property>

<property name="PosY" type="Int32" default="-1">
<get/>
</property>

<property name="PosZ" type="Int32" default="-1">
<get/>
</property>

<reference name="Terrain" type="Terrain">
<note>I'm assuming that the all of the terrain information can be encapsulated in a terrain type. Changing the terrain will be done through the Map object</note>
<get/>
</property>

<reference name="Construction" type="Construction">
<note>I'm assuming only one construction can exist in a cell at a time. Changing the construction will be done through the Map object</note>
<get/>
</list>

<list name="Items" type="Item" reference="yes">
<note>Should the cell own the items, or just reference them?</note>
<get/>
</list>

<reference name="Building" type="Building">
<note>Placing/removing buildings via the Map object will handle attaching/detaching themselves from the cell</note>
<get/>
</reference>

<internal>
<reference name="Top" type="Cell"/>
<reference name="Bottom" type="Cell"/>
<reference name="Left" type="Cell"/>
<reference name="Right" type="Cell"/>
<reference name="Up" type="Cell"/>
<reference name="Down" type="Cell"/>
</internal>
</class>
</pre>

Utility:Obsidian/Cell definition files

2010-05-30T03:35:31Z

Skeggox: Added the map definition file

Utility:Obsidian/Cell definition files

2010-05-30T03:34:05Z

Skeggox: Added the fortress definition file

Utility:Obsidian/Cell definition files

2010-05-30T02:40:18Z

Skeggox: Created page with '=Cell definition files= This list of files represent the internal representation of the Cell engine, to be exposed to Lua and used by other modules (like the geometry generator) …'

Utility:Obsidian

2010-05-30T02:35:35Z

Skeggox:

=Obsidian=
[[File:obsidianicon.png|thumb|right]]
Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and raytracers.

Its a modular Lua framework, using Open Scene Graph for rendering and DFHack for talking with Dwarf Fortress.

This [http://www.bay12forums.com/smf/index.php?topic=57920.0 forum thread] has more detail.

=Screen shots=
[[File:obsidian_v_0.01.png|100px|Obsidian V0.01]]
[[File:obsidian_v_0.02.png|100px|Obsidian V0.02]]
[[File:obsidian_v_0.03.png|100px|Obsidian V0.03]]
[[File:obsidian_v_0.04.png|100px|Obsidian V0.04]]

=Credits=
* Technical lead programmer - Skeggox
* 3D artists - Djohaal, opsneakie
* Icon design - Janus

=Technical Info=
==Cell Engine==
This is a structured representation of a DF fortress (technically a cellular automata with metadata) in C++. It provides XML and binary serializers by default, as well as Lua bindings. All of the code is generated from XML definition files, which represents all of the information we know about Dwarf Fortress
*[[Cell definition files]]

Utility:Obsidian

2010-05-27T18:35:21Z

Skeggox: /* Credits */

Utility:Obsidian

2010-05-26T21:37:35Z

Skeggox: /* Obsidian */

File:Obsidianicon.png

2010-05-26T21:37:03Z

Skeggox:

Utility:Obsidian

2010-05-26T08:30:02Z

Skeggox: /* Credits */

=Obsidian=
Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and raytracers.

Its a modular Lua framework, using Open Scene Graph for rendering and DFHack for talking with Dwarf Fortress.

This [http://www.bay12forums.com/smf/index.php?topic=57920.0 forum thread] has more detail.

=Screen shots=
[[File:obsidian_v_0.01.png|100px|Obsidian V0.01]]
[[File:obsidian_v_0.02.png|100px|Obsidian V0.02]]
[[File:obsidian_v_0.03.png|100px|Obsidian V0.03]]
[[File:obsidian_v_0.04.png|100px|Obsidian V0.04]]

=Credits=
* Technical lead programmer - Skeggox
* 3D artists - Djohaal, opsneakie

File:Obsidian v 0.04.png

2010-05-25T00:34:54Z

Skeggox: Obsidian now has a DFHack module and can attach to Dwarf Fortress. Although only parts of the API and Maps classes are bound, more will be added shortly

Obsidian now has a DFHack module and can attach to Dwarf Fortress. Although only parts of the API and Maps classes are bound, more will be added shortly

Utility:Obsidian

2010-05-25T00:33:55Z

Skeggox: /* Screen shots */

File:Obsidian v 0.03.png

2010-05-24T20:46:32Z

Skeggox: This shows the Open Scene Graph viewer in action, with an example glider model and diagnostic displays

This shows the Open Scene Graph viewer in action, with an example glider model and diagnostic displays

File:Obsidian v 0.02.png

2010-05-24T20:45:37Z

Skeggox: This demonstrates how to load and use a module in Obsidian - in this case the DevIL image manipulation library

This demonstrates how to load and use a module in Obsidian - in this case the DevIL image manipulation library

Utility:Obsidian

2010-05-24T20:44:56Z

Skeggox:

Utility:Obsidian

2010-05-24T20:37:29Z

Skeggox: /* Screen shots */

=Obsidian=
Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and raytracers.

Its a modular Lua framework, using Open Scene Graph for rendering and DFHack for talking with Dwarf Fortress.

This [http://www.bay12forums.com/smf/index.php?topic=57920.0 forum thread] has more detail.

=Screen shots=
[[File:obsidian_v_0.01.png|thumb|left|Obsidian V0.01]]
[[File:obsidian_v_0.02.png|thumb|left|Obsidian V0.02]]
[[File:obsidian_v_0.03.png|thumb|left|Obsidian V0.03]]

=Credits=
* Technical lead programmer - Skeggox

File:Obsidian v 0.01.png

2010-05-24T20:35:11Z

Skeggox: This shows the Obsidian console and render window up and running, with the Lua script loading and error reporting functionality demonstrated.

This shows the Obsidian console and render window up and running, with the Lua script loading and error reporting functionality demonstrated.

Utility:Obsidian

2010-05-24T20:33:37Z

Skeggox:

=Obsidian=
Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and raytracers.

Its a modular Lua framework, using Open Scene Graph for rendering and DFHack for talking with Dwarf Fortress.

This [http://www.bay12forums.com/smf/index.php?topic=57920.0 forum thread] has more detail.

=Screen shots=
*[[Image:obsidian_v_0.01.png]]
*[[Image:obsidian_v_0.02.png]]
*[[Image:obsidian_v_0.03.png]]

=Credits=
* Technical lead programmer - Skeggox

Utility:Obsidian

2010-05-24T20:31:00Z

Skeggox: Created page with '=Obsidian= Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and…'

v0.31:Utilities

2010-05-24T20:27:50Z

Skeggox: /* 3D Visualizers */

{{AV}}
{{Quality|Exceptional}}
Please only list utilities that are known to work with the newest version here.

Here are third party applications useful for Dwarf Fortress.
__TOC__
== [http://dffd.wimbli.com/ Dwarf Fortress File Depot] ==
The Dwarf Fortress File Upload Service - an excellent place to store mods, community games, tilesets and other files. Courtesy of [[User:Janus|Janus]]; for files related to Dwarf Fortress only.

== 3D Visualizers ==

=== [[Utility:Stonesense|Stonesense]] ===
[[File:stonesense.jpg|208px|thumb|right|Stonesense Screenshot]]
''by Jonask, Solifuge, Kaypy and Japa''

Stonesense is a third party real-time visualizer that lets you view your Dwarf Fortress world in a classic isometric perspective.

More information is available in [http://www.bay12games.com/forum/index.php?topic=43260.0 this forum thread].

Stonesense Slate now supports v0.31.04 - [http://stonesense.googlecode.com/files/Stonesense_Slate_RC1.rar get it here]

=== [[Utility:Obsidian|Obsidian]] ===
''by Skeggox''

Obsidian is a toolset for converting DF maps into a renderable scene, manipulating the result, and displaying it directly in 3D or exporting to 3rd party renderers and raytracers.

Its a modular Lua framework, using Open Scene Graph for rendering and DFHack for talking with Dwarf Fortress.

This [http://www.bay12forums.com/smf/index.php?topic=57920.0 forum thread] has more detail.

== [http://dffd.wimbli.com/file.php?id=645 Reveal] ==

Reveal (or Reveal.exe as it is commonly referred to) is a program that runs alongside Dwarf Fortress and shows all "unexplored" or "undug" tiles of the map (in fortress mode). To reveal entire map designate the entire bottom level to be mined and then remove designation before running reveal (Not required in the latest version using the parameters below, simply start the .exe file.). Playing on revealed map might ''(read "will")'' cause some bugs (like not being able to build magma buildings or a tower-cap farm, losing all plants/trees on the map, and a lot more). '''Using Reveal has been known to corrupt saved game folders.''' and, as such, it is highly recommended to only use Reveal to preview a biome's layout and then restart without running Reveal.

There are two versions of Reveal, one for Vista and newer, one for XP and older.

The new version of Reveal.exe (Reveal2) is in public beta, you can find it here [http://dffd.wimbli.com/file.php?id=1044 Reveal2]. Please report problems in [[User_talk:0x517A5D|0x517A5D's Talk page]].

Pasting the following code into reveal2.ini makes it work for the newest (DF2010) version of Dwarf Fortress:

<pre>
;; DF2010 31.02
[4BBDF378]
map_data=0x016ad718
map_x_count=0x016ad738
map_y_count=0x016ad73c
map_z_count=0x016ad740
</pre>
[4BB45F99] can be substituted in for 31.01.

For 31.04, the following works:
<pre>
; .31.04
[4BF014FA]
dwarf_fortress=0x00A551C0
map_data=0x016BAAC4
map_x_count=0x016BAAE4
map_y_count=0x016BAAE8
map_z_count=0x016BAAEC
map_data_designation_offset=0x29C
</pre>

However, do '''not''' save your game, it can mess up many things including civilizations (Giant Toad and Cave Crocodile civilizations, you will also embark with those if it should occur.)

==[http://www.bay12games.com/forum/index.php?topic=39229 Dwarf Therapist]==

Dwarf Therapist gives you an advanced GUI to manage and check dwarf job allocations, military assignments (40d), statistics (such as attributes, personality traits and happiness), plus sort dwarves by various criteria (eg. profession, migration wave etc.) and generally manage the Dwarven Resources of your fortress in a very convenient way.

Version 5.1 is out (4/24/10). This version supports DF build 3.01.03.

New dedicated support forum: http://code.google.com/p/dwarftherapist/

==[http://www.bay12games.com/forum/index.php?topic=50643.0 Dfterm]==

Dfterm is a tool to run dwarf fortress via terminals remotely. multiple people can connect and watch or join in.

Main article here: [[Dfterm]].

== [http://www.bay12games.com/forum/index.php?topic=41916.0 DFHack] ==

DFHack is a Dwarf Fortress memory access library and a set of basic tools using this library. The library is a work in progress, so things might change as more tools are written for it. The current (0.3.1.4) release only supports the new DF 0.31.01, 0.31.02 and 0.31.03 versions. It consists of some of the more useful DFHack tools.

Code and binary releases are available from the [http://github.com/peterix/dfhack/downloads Github site].

=== DFhack tools for DF 2010 ===
==== dfcleanmap ====
Cleans all the bloodsmears that get scattered all over the map.
==== dfliquids ====
Allows creating liquids (water and magma), making them flow or preventing them from flowing. Newly also allows making obsidian walls. It's a command-prompt style utility where you type in very simple commands. Replaces the older magma_create tool.

==== dfprospector ====
Lists all available minerals on the map and how much of them there is.
==== dfreveal ====
Reveals the whole map. Newly can also hide what it revealed. Use with caution, releases [[HFS]]! Same warnings as to the original Reveal tool apply.

==== dfvdig ====
Designates a whole vein for digging. When using the '-x' option, it will dig stairs into other z-levels. Point the cursor at a vein and run this thing :)

== DF Map Compressor / DF Map Archive ==

*[http://shadowlord13.googlepages.com/dfmap-index.html SL's DF Map Compressor - Website]
*[http://mkv25.net/dfma/ Dwarf Fortress Map Archive]

The DF Map Compressor encodes multiple bitmaps exported from Dwarf Fortress into a single, very compressed, .fdf-map file. The fdf-map file can then be shared with your friends by uploading to the DF Map Archive that features an online viewer (written in Flash).

The map compressor was created by Shadowlord in May 2007. Extract from the website :
:"The '''DF Map Compressor''' is a program I made to encode Dwarf Fortress fortress or world map images into a much smaller format than is possible with normal image formats. Here's a quick summary of how it works: It determines the size of your tiles from your DF font file (or asks you), splits the map up into tiles, identifies duplicate tiles, writes out every unique tile image, and then writes out a list of ID#s for each tile position which points to the tile image for that tile. What it outputs is piped through the LZMA compressor (the one used in 7-zip), to compress it further. The .df-map file which it writes out is usually less than 100 KB in size. (By comparison, a PNG of the same map can exceed 2 megabytes, depending on how well you compress it, whether you change the color depth, and whether you are using a graphical tileset or detailed font)."

Read more about the [[User:Markavian/DF_Map_Archive|DF Map Archive]] on Markavian's User page.

== [[User:Soundandfury/DF_Designer|DF Designer]] ==
DF Designer, by [[User:Soundandfury|soundnfury]] is a fort layout planning tool. It enables you to work out your designs before you start to build, and even see how they look in 3-D.
It's written in C with SDL, and both Linux and Windows builds are available. The source code is freely available under the GPL.
Since DF Designer does not 'talk to' Dwarf Fortress, it is version-independent.

== Modding tools ==
=== [http://dffd.wimbli.com/file.php?id=2068 Custom Workshop Workshop] ===
WYSIWYG editor for designing the raws for a custom workshop.
(Not all raws, just the tiles and colors) Lets you see how it will look at each stage of construction. Comes with the default 16x16 CURSES font built in, but you can load any .BMP formatted DF font you like, keeping in mind that if its bigger than 16x16 it won't fit.

Accommodates up to 32x32 workshops, not that there's any reason for such a large workshop, right?

== Raw tile tools ==
=== [http://dffd.wimbli.com/file.php?id=2113 Raw tile selector] ===
Provides an easy to use graphical interface to select which tiles and colors should be displayed for plants, stones and small creatures.

Made to ease the job of creators of tilesets with edited raws. It will also be useful for users that dislike decisions made by tileset creators or users that could not find the edited raws for a tileset.

Currently for windows only.

=== [http://dffd.wimbli.com/file.php?id=2178 Raw tile merger] ===
Provides an easy to use interface to change the tile and color data of raws to match the data of another set of raw files.

Made to ease the job of creators of tilesets with edited raws when new versions of df are released. The edited raws for your tileset for a new df version can now be created with a few clicks.

== [http://winmerge.org/ WinMerge] ==
Winmerge allows you to compare the contents of folders or files. It highlights any differences between files and allows you to merge them. It is most useful for modders or users of mods. If you compare modified raw files with unmodified ones you can quickly see any differences.

== World Map / World Gen Tools ==
=== [http://www.bay12forums.com/smf/index.php?topic=57428 PerfectWorldDF] ===
Very detailed Windows program to help create customize world gens.
<br>[http://www.bay12forums.com/smf/index.php?topic=57428 Bay 12 forum link]
<br>[http://dffd.wimbli.com/file.php?id=2354 Dwarf Fortress File Depot link (may be old version)]
<br>[http://dffd.wimbli.com/who.php?id=1314 Dwarf Fortress File Depot listing for the author]