v50 Steam/Premium information for editors
- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
This notice may be cached—the current version can be found here.
Editing Utility Talk:Obsidian/Art
Jump to navigation
Jump to search
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 9: | Line 9: | ||
* 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) | * 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. | + | * 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.4 (4ft/10ft) rendering units. I would also prefer that we base our rendering unit length on 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) | * 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) | * 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) | ||
− | |||
− | |||
− | |||
− | |||
== Procedurally Generated Models == | == Procedurally Generated Models == | ||
Line 30: | Line 26: | ||
* 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) | * 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) | --[[User:Crunch|Crunch]] 17:03, 11 June 2010 (UTC) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Textures == | == 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) | 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) | ||
− | |||
− |