View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003135 | The Dark Mod | Coding | public | 21.05.2012 15:57 | 14.04.2019 15:03 |
Reporter | tels | Assigned To | duzenko | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | assigned | Resolution | open | ||
Product Version | |||||
Target Version | Fixed in Version | ||||
Summary | 0003135: Add per-pixel material definitions ("material maps") | ||||
Description | Currently every surface can only have one material associated with it - be it stone, wood, glass etc. This means combined surfaces (think woodbeams + plaster) can only be wood, or plaster, but not both. This has drawbacks on reactions to the material. If f.i. the player shoots an arrow at a wooden beam, the arrow would break if the surface is tagged "stone". OTOH, if the surface is tagged "wood", the arrow would also stick in plaster. | ||||
Additional Information | An 1,2, 4 etc bit image, with color-coded pixels (1, 2, etc) would need to be specified in the material shader. The shader would also need to supply a list of materials that are associated with each number (1=stone, 2=wood etc). | ||||
Tags | No tags attached. | ||||
Per vertex materials with interpolation would probably be more feasible? If brushes could have vertex blending you could rewrite the material parser to pair surfaces with vertex colors and have audio cross-fade work like vertex blending. Mind, this is still a lot of CPU side management and memory overhead but perhaps not so much more than tracking all that clip texture geometry with surface attributes. On further consideration for per-pixel mapping, if this were not applied to all areas but only special use cases, it might be pretty nifty too. |
|
The way it works in Quake 4 (and I understand it) is that if there is no material map, the default mateterial is used (straw, stone, wood) but if there is a material map, it is consulted at the pixel that was hit. Just like specular maps etc the material map does not need to be of the same resolution than the underlying texture. This system is quite simple to implement. Whatever you wrote with vertex interpolation etc. does not make any sense to me. A triangle has 3 vertexes, but it can have an arbitrarily complex texture painted on - think "leather armor with metal belt buckle and bits of skin exposed". That would be 3 materials alone that could appear on a single triangle. Currently, all these different surfaces need to be sep. into different meshes just so the game can decide wether something collided with metal, leather or skin. |
|
Yes, there would be cases where a single texture represents many materials but "if vertex blending ever becomes more wide-spread" then interpolating a value between vertices would be a good second tier solution too. The texture artist could "paint" a wood texture onto an otherwise stone surface with stone texture and blend the two therefore the same interpolation needed to resolve the gradient in one case (vertex blending) might possibly work to communicate values in the other case (surface blending). Yeah, until such time that vertex blending is used in any other mission than NHAT 3/3 then this is a pretty moot point. | |
@nbohr1more, can this be closed? | |
This is still an open ticket but it seems to be an impractical solution. You would need to transform the image map onto the collision data which is akin to texturing on a GPU. CPU's are very slow at such things. If someone were to move our physics engine to the GPU, or if they made a compute shader specifically for this purpose then this might be a more feasible concept. Suspended. |
|
The 'collision point' position never hits the GPU. I think we have everything we need to calculate this on CPU. Right, CPU texturing is slow but we only need to fetch one sample per collision and that can't be a problem. Can we have a test map? |
|
I think we'll need a test material to go in the test map. Maybe we could lift one from Quake 4 for testing purposes? Q4 uses the keyword materialImage for this: https://modwiki.dhewm3.org/Texturing#q4-hit-maps We'd need to assign colours to material types. This is the Q4 list (it loads them from an external file), which has partial overlap with TDM's: |
|
ppm.txt (1,714 bytes)
materialType none { description "Akin to a void, no decals are left on this surface and no effects are spawned" rgb 0,0,0 } materialType solidmetal { description "Heavy duty metal - such as girders" rgb 102,102,102 } materialType flesh { description "Exposed skin" rgb 204,102,102 } materialType hollowmetal { description "Thin metal plate - such as air ducts or computer covering" rgb 70,70,70 } materialType dirt { description "Dirt" rgb 140,100,60 } materialType sand { description "Fine ground rock normally found in deserts" rgb 255,255,160 } materialType gravel { description "Loosely ground rough pebbles" rgb 200,170,95 } materialType glass { description "Translucent" rgb 255,255,255 } materialType concrete { description "Solid rock like material used in construction" rgb 170,170,170 } materialType water { description "" rgb 140,170,220 } materialType gelatinousfluid { description "" rgb 120,40,140 } materialType oil { description "" rgb 240,30,40 } materialType bpglass { description "Bulletproof glass" rgb 150,40,80 } materialType rock { description "Naturally exposed rock" rgb 90,70,64 } materialType rubber { description "" rgb 40,40,40 } materialType plastic { description "" rgb 130,200,120 } materialType armor { description "kevlar" rgb 100,90,170 } materialType electronics { description "" rgb 250,170,90 } materialType monstermetal { description " Monster metal... metal for monsters... " rgb 60,52,157 } |
|
Extracted comment content to the attached file | |
What I would like here is a e.g. wall with a per-pixel material. Then in a test map player shoots an arrow at that wall and it should either stick or break |
|
Okay, let's try modifying the metal_pattern_overwood material. Currently it has the wood surface type (even though the textures have /metal/ in their paths), which means arrows stick in the metal plates. I've made a basic hitmap for it. It's black and white; change it to whatever colours you want. This is the material def. currently used: textures/darkmod/door/metal/metal_pattern_overwood { qer_editorimage textures/darkmod/door/metal/metal_pattern_overwood_ed wood bumpmap textures/darkmod/door/metal/metal_pattern_overwood_local diffusemap textures/darkmod/door/metal/metal_pattern_overwood specularmap textures/darkmod/door/metal/metal_pattern_overwood_s { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/darkmod/door/metal/metal_pattern_overwood rgb 0.15 * parm11 } // TDM Ambient Method Related { if (global5 == 1) blend add map textures/darkmod/door/metal/metal_pattern_overwood scale 1, 1 red global2 green global3 blue global4 } { if (global5 == 2) blend add program ambientEnvironment.vfp vertexParm 0 1, 1, 1, 1 // UV Scales for Diffuse and Bump vertexParm 1 1, 1, 1, 1 // (X,Y) UV Scale for specular vertexParm 2 global2, global3, global4, 1 fragmentMap 0 cubeMap env/gen1 fragmentMap 1 textures/darkmod/door/metal/metal_pattern_overwood_local // Bump fragmentMap 2 textures/darkmod/door/metal/metal_pattern_overwood // Diffuse fragmentMap 3 textures/darkmod/door/metal/metal_pattern_overwood_s // Specular } } If you put that in a .mtr file in /materials/ you can override the existing one and edit it as required. |
|
metal_pattern_overwood_hit.tga (12,322 bytes) |
|
hitmaptest.map (5,667 bytes) |
|
Added support of materialImage keyword in revision: 8169 My problem now is: I can't see where the game makes decision if an arrow should break or stick depending on the material in the source code. I hope to God it's not scripted somewhere? |
|
Try finding what handles the active_surfaces spawnarg in the projectile defs. It's set to umpteen surftypes for broadheads but only wood for rope arrows, so I'd guess it has something to do with it. |
|
Found it. Apparently our collision manager operates its own separate data set, that only includes vertex positions. What's worse, it deals with polygons rather than triangles, so there's no simple way to map collision point to a particular 3D model triangle. To traverse the materialImage texture we need vertex texture coordinates. It turns out my statement "we have everything we need to calculate this" was wishful thinking. We either need to add texture coords to collision manager data or try to find the model triangle based on its distance to collision point. |
|
It's a similar issue as to why we cannot use the projection images (textures) directly in the AI light scan. If the game side had access to this data, AI would more accurately know when dead bodies are illuminated etc. We might even be able to make the lightgem calc itself cheaper ala the tdm_lg_weak algorithm. |
|
I think using textures is an entirely wrong way of doing this. The issue is completely unrelated to graphics. Even collision models are sometimes different from render models. The correct way would be to set groups of triangles/vertices in collision meshes. I won't be surprised if groups are already supported for collision models and in mesh formats. The proper workflow is: 1) Collision manager detects an arrow hit. 2) We take contact point: it hits either face, edge, or vertex of the mesh. Just choose some nearby vertex (or face) and check which group it belongs to. 3) Lookup that group in some {group->material} mapping, and handle hit physics/sounds based on the result. UPDATE: But in fact what I am writing here is already how things work: a portion of object of every material is put into its own surface... |
|
Started a forum thread http://forums.thedarkmod.com/topic/19959-per-pixel-material-definitions-material-maps/ |
|
That would work for e.g. Epi's microscope (which uses a "metal" material but has the microscope sitting on what's visually a wooden block; a moveable version would need a .cm added anyway). And I suppose the principle could be extended to vertex blended terrain meshes by checking whether the vertex colour or the inverse vertex colour would be dominant at the collision point. But I'm not clear on how it could work for something like textures/darkmod/door/metal/metal_pattern_overwood -- that's a material applied to big, rectangular, often flat surfaces. Ditto the woodbeams + plaster example in the bug description. | |
Date Modified | Username | Field | Change |
---|---|---|---|
21.05.2012 15:57 | tels | New Issue | |
22.05.2012 02:44 | nbohr1more | Note Added: 0004605 | |
23.05.2012 16:30 | tels | Note Added: 0004617 | |
23.05.2012 22:51 | nbohr1more | Note Added: 0004618 | |
28.03.2018 10:30 |
|
Note Added: 0010233 | |
28.03.2018 18:45 | nbohr1more | Note Added: 0010319 | |
28.03.2018 18:45 | nbohr1more | Status | new => suspended |
11.04.2019 19:39 | duzenko | Note Added: 0011723 | |
11.04.2019 19:40 | duzenko | Note Edited: 0011723 | View Revisions |
12.04.2019 19:31 | VanishedOne | Note Added: 0011726 | |
13.04.2019 08:13 | duzenko | Assigned To | => duzenko |
13.04.2019 08:13 | duzenko | Status | suspended => assigned |
13.04.2019 08:14 | duzenko | File Added: ppm.txt | |
13.04.2019 08:15 | duzenko | Note Edited: 0011726 | View Revisions |
13.04.2019 08:15 | duzenko | Note Added: 0011727 | |
13.04.2019 08:17 | duzenko | Note Added: 0011728 | |
13.04.2019 08:17 | duzenko | Note Edited: 0011728 | View Revisions |
13.04.2019 15:57 | VanishedOne | Note Added: 0011730 | |
13.04.2019 15:57 | VanishedOne | File Added: metal_pattern_overwood_hit.tga | |
13.04.2019 15:58 | VanishedOne | File Added: hitmaptest.map | |
13.04.2019 17:14 | duzenko | Note Added: 0011731 | |
13.04.2019 17:51 | VanishedOne | Note Added: 0011734 | |
13.04.2019 17:52 | VanishedOne | Note Edited: 0011734 | View Revisions |
14.04.2019 07:54 | duzenko | Note Added: 0011735 | |
14.04.2019 08:12 | nbohr1more | Note Added: 0011736 | |
14.04.2019 08:12 | nbohr1more | Note Edited: 0011736 | View Revisions |
14.04.2019 08:13 | nbohr1more | Note Edited: 0011736 | View Revisions |
14.04.2019 08:13 | nbohr1more | Note Edited: 0011736 | View Revisions |
14.04.2019 13:03 | stgatilov | Note Added: 0011737 | |
14.04.2019 13:03 | stgatilov | Note Edited: 0011737 | View Revisions |
14.04.2019 13:07 | stgatilov | Note Edited: 0011737 | View Revisions |
14.04.2019 14:54 | duzenko | Note Added: 0011738 | |
14.04.2019 15:03 | VanishedOne | Note Added: 0011739 |