View Issue Details

IDProjectCategoryView StatusLast Update
0003135The Dark ModCodingpublic14.04.2019 15:03
Reportertels Assigned Toduzenko  
PrioritynormalSeverityfeatureReproducibilityN/A
Status assignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0003135: Add per-pixel material definitions ("material maps")
DescriptionCurrently 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 InformationAn 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).
TagsNo tags attached.

Activities

nbohr1more

nbohr1more

22.05.2012 02:44

developer   ~0004605

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.
tels

tels

23.05.2012 16:30

developer   ~0004617

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.
nbohr1more

nbohr1more

23.05.2012 22:51

developer   ~0004618

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.

user81

28.03.2018 10:30

  ~0010233

@nbohr1more, can this be closed?
nbohr1more

nbohr1more

28.03.2018 18:45

developer   ~0010319

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.
duzenko

duzenko

11.04.2019 19:39

developer   ~0011723

Last edited: 11.04.2019 19:40

View 2 revisions

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?

VanishedOne

VanishedOne

12.04.2019 19:31

developer   ~0011726

Last edited: 13.04.2019 08:15

View 2 revisions

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:

duzenko

duzenko

13.04.2019 08:14

developer  

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
} 
ppm.txt (1,714 bytes)
duzenko

duzenko

13.04.2019 08:15

developer   ~0011727

Extracted comment content to the attached file
duzenko

duzenko

13.04.2019 08:17

developer   ~0011728

Last edited: 13.04.2019 08:17

View 2 revisions

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

VanishedOne

VanishedOne

13.04.2019 15:57

developer   ~0011730

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.
VanishedOne

VanishedOne

13.04.2019 15:57

developer  

metal_pattern_overwood_hit.tga (12,322 bytes)
VanishedOne

VanishedOne

13.04.2019 15:58

developer  

hitmaptest.map (5,667 bytes)
duzenko

duzenko

13.04.2019 17:14

developer   ~0011731

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?
VanishedOne

VanishedOne

13.04.2019 17:51

developer   ~0011734

Last edited: 13.04.2019 17:52

View 2 revisions

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.

duzenko

duzenko

14.04.2019 07:54

developer   ~0011735

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.
nbohr1more

nbohr1more

14.04.2019 08:12

developer   ~0011736

Last edited: 14.04.2019 08:13

View 4 revisions

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.

stgatilov

stgatilov

14.04.2019 13:03

developer   ~0011737

Last edited: 14.04.2019 13:07

View 3 revisions

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...

duzenko

duzenko

14.04.2019 14:54

developer   ~0011738

Started a forum thread
http://forums.thedarkmod.com/topic/19959-per-pixel-material-definitions-material-maps/
VanishedOne

VanishedOne

14.04.2019 15:03

developer   ~0011739

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.

Issue History

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 user81 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