Texture coordinate transform? Topic is solved

[jwwalker]

Does HLMS have any way to apply a matrix transform to texture coordinates, or would I need to roll my own somehow?

[dark_sylinc]

Unlit: Yes. See setEnableAnimationMatrix & setAnimationMatrix (they can also be set from scripts)

PBS: Only detail maps support offset and scale. Anything more complex needs to be custom made, there's HlmsPbsDatablock::mUserValue where you can put custom values; and you can override the macros UV_* (e.g. UV_DIFFUSE, UV_DETAIL_WEIGHT, etc) in UvModifierMacros_piece_ps.any for applying your custom operations.

[jwwalker]

I got UV transformation to work in the lit case. When setting up the data block, I say

Code: Select all

block->setUserValue( 0, Ogre::Vector4( uvTrans[0] ) );
block->setUserValue( 1, Ogre::Vector4( uvTrans[1] ) );

And then I added a media file in the Hlms/Pbs/Any folder containing:

Code: Select all

@piece( custom_ps_functions )
@insertpiece( Common_Matrix_DeclLoadOgreFloat4x3 )
@end

@piece( custom_ps_uv_modifier_macros )
#undef UV_DIFFUSE
#define UV_DIFFUSE( p ) mul( float4( (p), 1.0, 0.0 ), makeOgreFloat4x3( material.userValue[0], material.userValue[1], material.userValue[2] ) ).xy
@end

There's one thing that puzzles me. The makeOgreFloat4x3 macro produces a result of type mat3x4 in GLSL and float3x4 in Metal. It shouldn't make sense to multiply a vector of 4 numbers on the left of a 3x4 matrix, but somehow it works.

[dark_sylinc]

There's one thing that puzzles me. The makeOgreFloat4x3 macro produces a result of type mat3x4 in GLSL and float3x4 in Metal. It shouldn't make sense to multiply a vector of 4 numbers on the left of a 3x4 matrix, but somehow it works.

It's row major vs columns major. It's a convention.

Multiplying MxN * NxO matrix in column major is the same as doing in OxN * NxM in row major. That doesn't mean matrices are commutative, it just means matrices are read in the opposite order.

In this case you can either do 4x3 * 3x1 (in one convention) or you can do 1x3 * 3x4 (the opposite convention).

The macros are supposed to keep conventions consistent across languages

[jwwalker]

Yes, I am aware that each 3D software system needs to decide how to lay out a matrix in memory (row major or column major), and also whether to think of a point or vector as a row or column, and that those are two independent choices. What was confusing me was more a matter of notation: I didn't realize that mat3x4 in GLSL, and float3x4 in Metal, are matrices with 3 columns and 4 rows. Being trained as a mathematician, that just seems so wrong to me; a 3x4 matrix is supposed to have 3 rows and 4 columns, never mind how you store it in computer memory.

[jwwalker]

Slight improvement to my uvtrans_piece_ps.any media file:

Code: Select all

@piece( custom_ps_uv_modifier_macros )
#undef makeOgreFloat4x3
@insertpiece( Common_Matrix_DeclLoadOgreFloat4x3 )
#undef UV_DIFFUSE
#define UV_DIFFUSE( p ) mul( float4( (p), 1.0, 0.0 ), makeOgreFloat4x3( material.userValue[0], material.userValue[1], float4(0.0, 0.0, 0.0, 0.0) ) ).xy
@end

The custom_ps_functions piece wasn't always coming in when I needed it.