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)

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)

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)