Utility Talk:Obsidian/Art

Let's discuss Obsidian's art here 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. --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. 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. 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? 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... 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.--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. 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). 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. 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. No fort is complete without magma... and water... and then some FUN. 19:58, 11 June 2010 (UTC)

--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 --Djohaal was here. 03:00, 13 June 2010 (UTC)

• Oh, god. FML. --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 :) No fort is complete without magma... and water... and then some FUN. 17:34, 16 June 2010 (UTC)

Textures

Here's a neat free 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. --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 --Djohaal was here. 02:42, 13 June 2010 (UTC)