Rotating textures for Atlas terrain in TGEA 1.7.0
by Konrad Kiss · in Torque Game Engine · 05/27/2008 (9:20 am) · 11 replies
Hi. I have been working with the extremely awesome Grome Pro terrain editor for a while just to realize, that one of the coolest features - vertically rotated textures - will not display right on an Atlas terrain within TGEA 1.7.0.
This is responsible for making ultra-realistic steep cliffs and mountain sides, because the texture is not applied from the top, rather it is rotated to fit the average normals of the cliff side (or ~ 90 degrees).
I've made some pics to show you what I mean:
So I've decided to make some modifications to the engine be able to add horizontal and/or vertical rotation to any terrain texture by setting the degree of rotation within the AtlasInstance object in the mission file.
I wanted to ask you guys what you think of the idea, and if you know where I should start - I'm fairly new, and figured I'd save some time if I asked.
Any comment/help is much appreciated.
Edit: fixed pic link
This is responsible for making ultra-realistic steep cliffs and mountain sides, because the texture is not applied from the top, rather it is rotated to fit the average normals of the cliff side (or ~ 90 degrees).
I've made some pics to show you what I mean:
So I've decided to make some modifications to the engine be able to add horizontal and/or vertical rotation to any terrain texture by setting the degree of rotation within the AtlasInstance object in the mission file.
I wanted to ask you guys what you think of the idea, and if you know where I should start - I'm fairly new, and figured I'd save some time if I asked.
Any comment/help is much appreciated.
Edit: fixed pic link
About the author
http://about.me/konrad.kiss
#2
The importers store all normals as Point3F(0,0,1).
It might be easier to adjust the texture coordinates for each vertex.
05/27/2008 (11:35 am)
@Konrad Kiss - It may help you to know that the current importers for atlas terrains don't appear to store any useful information about the normals.The importers store all normals as Point3F(0,0,1).
It might be easier to adjust the texture coordinates for each vertex.
#3
...oh and good luck!
05/27/2008 (11:41 am)
Great idea.. much better quality..let me know if you get anywhere...oh and good luck!
#4
Anyway, for now, I'll leave the normals out, and just go for a similar approach I've seen in Grome - that is for each texture, you'd only be able to set horizontal, vertical rotation, and maybe spin.
Later on it'd be nice to find the optimal rotation - based on normals of the affected faces, and using their average to automatically get the best rotation - ie. one that "loses" the least pixels to steep faces. That'd be one that has the same normal as the average of the affected faces. From that it'd be relatively easy to get the rotations. However, I think it'd be better if this would be provided by the editors, since the terrain affected by the texture can be better managed there, and since it's a static value, there's no need to put the automatic rotation calculation into the engine.
I hope someone from Grome is reading this. :) Addig this would not take much time, and texture positioning would totally rock.
So for now, I just want the rotation to work, and while I'm at it, I'm also looking for a few tips about where to look / modify code. Once it's done, I'll make it a resource, of course.
05/27/2008 (11:51 am)
@Bill - Thanks for the info. This is exactly why I started this thread. :)Anyway, for now, I'll leave the normals out, and just go for a similar approach I've seen in Grome - that is for each texture, you'd only be able to set horizontal, vertical rotation, and maybe spin.
Later on it'd be nice to find the optimal rotation - based on normals of the affected faces, and using their average to automatically get the best rotation - ie. one that "loses" the least pixels to steep faces. That'd be one that has the same normal as the average of the affected faces. From that it'd be relatively easy to get the rotations. However, I think it'd be better if this would be provided by the editors, since the terrain affected by the texture can be better managed there, and since it's a static value, there's no need to put the automatic rotation calculation into the engine.
I hope someone from Grome is reading this. :) Addig this would not take much time, and texture positioning would totally rock.
So for now, I just want the rotation to work, and while I'm at it, I'm also looking for a few tips about where to look / modify code. Once it's done, I'll make it a resource, of course.
#5
05/27/2008 (11:53 am)
@Barry - Thanks, just keep visiting this thread for updates, I'm hoping to finish in a few days.
#6
I also think if you could do it , it would have to be with blended terrain only.
05/27/2008 (12:01 pm)
@Konrad Kiss - I think the clipmapping code would be the place to start.I also think if you could do it , it would have to be with blended terrain only.
#7
05/27/2008 (1:12 pm)
@Bill - Thanks. atlasClipMapBatcher, right? Yes, it will be for blended only.
#9
I don't know how this can be implemented in Atlas but I suspect that it will work only for blended terrain. What I can help you with is to explain how this feature is implemented in Grome.
For each layer (texture) you have the texture mapping planar but the plane can have any orientation (can be horizontal (the standard one), vertical from north to south, from west to east, or at any angle and spin). But it is always planar and doesn't vary with the terrain surface (applying it differently for each face will not work that easily, we would need to implement an unwrap algorithm).
Finding the best plane angle based on average orientation is also tricky since you will need a way to detect the terrain faces covered by that texture (you need to go thru the texture mask (coverage) and detect what faces are touched by that layer texture).
To actually get the mapping coordinates working it is very easy. You need to create the texture coordinates based on the vertex positions (since the terrain surface is a regular grid). Basically you need to take the vertex x,y,z and apply some transformation to obtain the planar texture coordinates. The transformation can be obtained from the Grome SDK (look for sTextureChannel:: sTextureMapping in the iTerrainMaterialLayer.h in the SDK). I can also send you the code to compute them (texgen_planes and tex_matrix).
To apply them in the engine, with OpenGL, just use tex gen planes to automatically create the texture coordinates based on the vertex positions. You also need to use the texture matrix to apply spinning, offset and texture scaling (tiling). For a good example, you can look at the output produced by the OSG (Open Scene Graph) exporter from Grome (in SDK/Plugins/ExpOSG/ExpOSG.cpp). In the SDK you also have the full source code of the exporter. There you can find the exact steps necessary to produce the correct texture transformation for any orientation. You just need to know a little OpenGL (OSG scene graph is based on OpenGL states).
If you need DirectX states (there you need to apply texture matrix and D3DTSS_TCI_CAMERASPACEPOSITION texture generation mode) let me know. I can send you a sample code for that.
Best Regards,
Adrian L.
Quad Software
05/28/2008 (12:10 am)
Hi Konrad,I don't know how this can be implemented in Atlas but I suspect that it will work only for blended terrain. What I can help you with is to explain how this feature is implemented in Grome.
For each layer (texture) you have the texture mapping planar but the plane can have any orientation (can be horizontal (the standard one), vertical from north to south, from west to east, or at any angle and spin). But it is always planar and doesn't vary with the terrain surface (applying it differently for each face will not work that easily, we would need to implement an unwrap algorithm).
Finding the best plane angle based on average orientation is also tricky since you will need a way to detect the terrain faces covered by that texture (you need to go thru the texture mask (coverage) and detect what faces are touched by that layer texture).
To actually get the mapping coordinates working it is very easy. You need to create the texture coordinates based on the vertex positions (since the terrain surface is a regular grid). Basically you need to take the vertex x,y,z and apply some transformation to obtain the planar texture coordinates. The transformation can be obtained from the Grome SDK (look for sTextureChannel:: sTextureMapping in the iTerrainMaterialLayer.h in the SDK). I can also send you the code to compute them (texgen_planes and tex_matrix).
To apply them in the engine, with OpenGL, just use tex gen planes to automatically create the texture coordinates based on the vertex positions. You also need to use the texture matrix to apply spinning, offset and texture scaling (tiling). For a good example, you can look at the output produced by the OSG (Open Scene Graph) exporter from Grome (in SDK/Plugins/ExpOSG/ExpOSG.cpp). In the SDK you also have the full source code of the exporter. There you can find the exact steps necessary to produce the correct texture transformation for any orientation. You just need to know a little OpenGL (OSG scene graph is based on OpenGL states).
If you need DirectX states (there you need to apply texture matrix and D3DTSS_TCI_CAMERASPACEPOSITION texture generation mode) let me know. I can send you a sample code for that.
Best Regards,
Adrian L.
Quad Software
#10
Thank you for your help! For now, I'll experiment with translations, I'll try to do it on the engine level to not have to worry about whether Direct3D or OpenGL is used by the client. I did not mean to apply a texture to each face, that'd require some serious texture morphing, and I still need to grow up to that.
I'll bug you if I get stuck though. :) Thank you again, I appreciate your help! And keep up the great work & support with Grome, it is definitely the best piece of software I have ever bought!
For now I'll just concentrate on the Torque side of the problem. If it's ready to accept rotation values for spin / vertical / horizontal, then I'll check the Grome to TGEA exporter and make it so when it exports the mission file, I'll make it include the set rotation, and possibly a commented out recommended rotation for each texture by checking the faces for each texture through the distribution layers - just like you said.
I hope I'll get around through the transformation matrices somehow, it will be a good excercise.
Thanks again,
Konrad
05/28/2008 (12:39 am)
Adrian,Thank you for your help! For now, I'll experiment with translations, I'll try to do it on the engine level to not have to worry about whether Direct3D or OpenGL is used by the client. I did not mean to apply a texture to each face, that'd require some serious texture morphing, and I still need to grow up to that.
I'll bug you if I get stuck though. :) Thank you again, I appreciate your help! And keep up the great work & support with Grome, it is definitely the best piece of software I have ever bought!
For now I'll just concentrate on the Torque side of the problem. If it's ready to accept rotation values for spin / vertical / horizontal, then I'll check the Grome to TGEA exporter and make it so when it exports the mission file, I'll make it include the set rotation, and possibly a commented out recommended rotation for each texture by checking the faces for each texture through the distribution layers - just like you said.
I hope I'll get around through the transformation matrices somehow, it will be a good excercise.
Thanks again,
Konrad
#11
The only ones I'm aware of that support it inherently are the neoaxis engine, on a per-layer basis, and the Turbine engine as used in Lord of The Rings Online.
It eliminates one of the things that has made me a non-fan of height-mapped terrain versus hand-modeled terrain, that annoying stretching as you illustrate in your post.
Hopefully this something that will someday become standard.
06/01/2008 (5:45 am)
That's something I wish more game engines would adopt, texture mapping on all 3 axis of a heightmap terrain.The only ones I'm aware of that support it inherently are the neoaxis engine, on a per-layer basis, and the Turbine engine as used in Lord of The Rings Online.
It eliminates one of the things that has made me a non-fan of height-mapped terrain versus hand-modeled terrain, that annoying stretching as you illustrate in your post.
Hopefully this something that will someday become standard.
Torque Owner Andrew Nare