


Texture transforms 
« View previous topic :: View next topic » 
Author 
Message

cmusch 
Posted: Thu Aug 16, 2007 7:49 pm Post subject: Texture transforms 


Joined: 02 Aug 2007 Posts: 33

Hello!
Today I started implementing exporting the texture transforms from Grome, and, frankly, I cannot quite understand why things are the way they are. What is the purpose of 5 different fields in the sTextureMapping struct if none of them directly gives me all the information I need?
Ok, here is my line of reasoning:
First of all, I thought it would be as simple as get the texture matrix, mulitply it with the vertex position, and have my texture coordinate. Then I discovered two things:
1) only rotation around the y axis ("spin") are taken into account in the texture matrix.
2) depending on whether or not H and V rotation are both set to zero, the scaling factor has a different meaning. Without H and V, it is the number the texture is tiled over the terrain (the tiling parameters from the UI), with rotation it is the factor to multiply the vertex coord with in order to get the texcoord.
Variations of these problems exist for all the other fields, e.g. the planes are only valid if a HV rotation is set etc...
So in my understanding I have to
) determine whether the HV rotation is zero. If so, correct the texture matrix scaling using the terrain dimension and scale, and use it.
) If HV are different from zero, don't correct the scaling, construct a rotation matrix and multiply it with the texture matrix, and use that.
Why make life so difficult? I think the 5 fields describing the texture transform could be put to much better use....
btw, any hint on the date the new version is done?
regards
chris 

Back to top 


cmusch 
Posted: Thu Aug 16, 2007 8:03 pm Post subject: 


Joined: 02 Aug 2007 Posts: 33

Another thing I don't understand: why is texture spin (rotation around y axis) designated as rotation.z? 

Back to top 


ALicu 
Posted: Fri Aug 17, 2007 3:56 pm Post subject: 


Joined: 12 Feb 2007 Posts: 1327

Hi, I wish things can be a little simpler there.
Using OpenGL, Grome is using both the tex gen planes (which are multiplied with the vertex positions to obtain custom orientation) and after that the texture matrix (to apply the scale and spin).
The same thing can be obtained in DirectX with D3DTSS_TCI_CAMERASPACEPOSITION mode and a single textures matrix (but which must be multiplied with the inverse of the worldview matrix and if you don't have vertex shaders you need to do it on the CPU).
sTextureMapping is the way it is because the final texture matrix really depends on your coordinate system. So by using scale, rotation and offset you can construct the final matrix in any coordinate system you want.
Now, if you are using OpenGL, sTextureMapping is giving you two final (transformed) members: texgen_planes and tex_matrix. Both are for OpenGL coordinate system (right handed, Y up) and can be used to set the tex gen planes (for U and V) and texture matrix.
Now if you are using DirectX, you need to construct the texture matrix from scale, rotation and offset. Let me know if this is the case and I can send you the code to setup the exact matrix.
Your assumptions about these members are in general right:
 Only spin is taken into the matrix because, again Grome is using OpenGL. The X and Z rotations are used when generating the tex gen planes.
 The scaling factor greatly depends if you are using or not rotation. If you are not using, the scaling it is in texture space. If you are using rotation, is in world space (because when you are using rotation you are using vertex coordinates positions to generate the texture coordinates which are in world space). So it makes sense after all.
 The planes are valid when HV is set because they are used only for that, for custom texture mapping orientation.
Anyway, let me know what coordinate system and API are you using and I can give you the exact code to use.
Regards,
Adrian L. 

Back to top 


cmusch 
Posted: Sat Aug 18, 2007 8:20 am Post subject: 


Joined: 02 Aug 2007 Posts: 33

Hi!
It is my opinion that the plugin API should not be designed based on how Grome handles terrain textures internally. The separation of texgen planes and texture matrix only arises because of how the OpenGL fixed functionality pipeline works. My application is shaderbased, and I need just one texture matrix which I multiply with the vertex coordinate in order to obtain the texcoord.
I don't complain that the texplane and texmatrix fields exist, they might be convenient for somebody who sets up texture rendering the way you do. I simply miss a consistent description of the texture mapping which is not influenced by adhoc requirements like the ones you describe.
Of course, given the knowledge on how the fields work exactly, it is not a problem to retrieve the needed information, I just think it's not very clean API design...
regards
chris 

Back to top 






Page 1 of 1 

You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum



