Bumpy Atlas Terrain... here's my latest attempt...
by Ves · in Torque Game Engine Advanced · 09/03/2007 (10:46 pm) · 52 replies
Well it was a huge pain, and I had to bump some shaders to 3.0 to get this to work (though I really think that's a mistake and it probably will all work in 2.0 shaders). I extended the base atlas shader (the clipmap pass shader) to include the bumpmapping. I had to move the lightmapping from the blended image cache section to this clipmap section as well. This is gross and no where near as elegant as I would like it but I did get it to work.
I also had to modify the atlas vertex format as well, as I needed the tangent on a vertex basis. I actually calculated the Binomial in the shader like everyone suggests but I think that might be the source of some the funky artifacts I get. I didn't modify atlas output yet as I am just verifying if this will work right now. So for the interum there is a stutter on loading a clipmap section as it calculates the tangents for all of the verticies at that point (thanks to some barrowed and modified code from the tmesh section).
Anyway here are some screens...
This is a great example of why you SHOULDN'T bump map everything in sight
i5.photobucket.com/albums/y153/vesuvias/whenbumpmaps_gowrong.jpg
high specular but it does move with the sun and player position
i5.photobucket.com/albums/y153/vesuvias/highspec_bump.jpg
Way too exagerated a bump map but its a good example bump
i5.photobucket.com/albums/y153/vesuvias/bumpy2.jpg
I actually like this one... specular is too high but its snow :)
i5.photobucket.com/albums/y153/vesuvias/bumpy1.jpg
The shaders I am using were adapted from mr noolness in this thread www.garagegames.com/mg/forums/result.thread.php?qt=36211, I am just using the standard normal mapping shader but I am pretty sure I can get the relief mapping one to work.
I set everything up so that I could followup with some code that actually uses different bump maps based on the terrian opacity map. So that will be my next goal. I may end up rewriting how terrains are blended though. I need to think on this somemore. I would really rather the opacity and lightmap be the only textures that are runtime merged via the clipmapping functions. Shaders should take care of the individual blending and bumpmapping I think. I may take a step even further back and try to get that to work. when I clean this up and if no one else has done a better one I will post a resource on what I did. Till then, comments and suggestions are welcome.
Ves
**Edited to replace images with image links... to save page loads....
I also had to modify the atlas vertex format as well, as I needed the tangent on a vertex basis. I actually calculated the Binomial in the shader like everyone suggests but I think that might be the source of some the funky artifacts I get. I didn't modify atlas output yet as I am just verifying if this will work right now. So for the interum there is a stutter on loading a clipmap section as it calculates the tangents for all of the verticies at that point (thanks to some barrowed and modified code from the tmesh section).
Anyway here are some screens...
This is a great example of why you SHOULDN'T bump map everything in sight
i5.photobucket.com/albums/y153/vesuvias/whenbumpmaps_gowrong.jpg
high specular but it does move with the sun and player position
i5.photobucket.com/albums/y153/vesuvias/highspec_bump.jpg
Way too exagerated a bump map but its a good example bump
i5.photobucket.com/albums/y153/vesuvias/bumpy2.jpg
I actually like this one... specular is too high but its snow :)
i5.photobucket.com/albums/y153/vesuvias/bumpy1.jpg
The shaders I am using were adapted from mr noolness in this thread www.garagegames.com/mg/forums/result.thread.php?qt=36211, I am just using the standard normal mapping shader but I am pretty sure I can get the relief mapping one to work.
I set everything up so that I could followup with some code that actually uses different bump maps based on the terrian opacity map. So that will be my next goal. I may end up rewriting how terrains are blended though. I need to think on this somemore. I would really rather the opacity and lightmap be the only textures that are runtime merged via the clipmapping functions. Shaders should take care of the individual blending and bumpmapping I think. I may take a step even further back and try to get that to work. when I clean this up and if no one else has done a better one I will post a resource on what I did. Till then, comments and suggestions are welcome.
Ves
**Edited to replace images with image links... to save page loads....
#42
I've tried the $pref::Atlas::clipMapSize = 1024; setting earlier when I altered the atlasBlender texCoord multiplier from 128.0 to 256.0 and the blended result got blurry -- and it fixed the problem (well, the at least the difference was clearly noticeable).
10/03/2007 (7:26 am)
Humm....I've tried the $pref::Atlas::clipMapSize = 1024; setting earlier when I altered the atlasBlender texCoord multiplier from 128.0 to 256.0 and the blended result got blurry -- and it fixed the problem (well, the at least the difference was clearly noticeable).
#43
When I adjust the texCoord I can see the tile pattern increasing/decreasing just the overall quality stays the same.
10/03/2007 (8:00 am)
I think I was running the adjusted clipMapSizes previously, though I had tagged it as "1024"; rather than just 1024; - so may have, or may not have been working? When I adjust the texCoord I can see the tile pattern increasing/decreasing just the overall quality stays the same.
#44
1. Convert RAW file to CHU file.
2. Covnert CHU file to Atlas geometry file.
3. Convert Light map texture to Atlas file.
4. Convert Opacity map texture to Atlas file.
5. Combine geometry, light, and opacity Atlas files with source texture tiles into a Blended Terrain.
As far as I can see you are performing steps 3 and 4 several times when you don't need to.
First, if your Opacity and Light maps are 1 large, single texture (just 1 PNG or JPG file) then you should be using the "fromLargeJPG" command, not the "fromTiles" command. The "fromTiles" command was designed for use when the image has been broken up into many smaller "tile" images, like L3DT's "mosaic map" feature. If that has been done, the images will be named with a base name and some coordinate values, so you'll have a series of files called "LightMap_x3y4") or some such. If this is not the case for you, then don't bother using the "fromTiles" import function. The "fromLargeJPG" function actually does the "cutting up" of the image into tiles for you, and then stores them in the Atlas Texture TOC that is created. So in your case, I think your import commands can be shortened to:
10/03/2007 (9:42 am)
Your Atlas creation commands seem.... strange Pug. You seem to be doing the same step several times and I'm not sure why. Creating a Blended terrain includes the following steps:1. Convert RAW file to CHU file.
2. Covnert CHU file to Atlas geometry file.
3. Convert Light map texture to Atlas file.
4. Convert Opacity map texture to Atlas file.
5. Combine geometry, light, and opacity Atlas files with source texture tiles into a Blended Terrain.
As far as I can see you are performing steps 3 and 4 several times when you don't need to.
First, if your Opacity and Light maps are 1 large, single texture (just 1 PNG or JPG file) then you should be using the "fromLargeJPG" command, not the "fromTiles" command. The "fromTiles" command was designed for use when the image has been broken up into many smaller "tile" images, like L3DT's "mosaic map" feature. If that has been done, the images will be named with a base name and some coordinate values, so you'll have a series of files called "LightMap_x3y4") or some such. If this is not the case for you, then don't bother using the "fromTiles" import function. The "fromLargeJPG" function actually does the "cutting up" of the image into tiles for you, and then stores them in the Atlas Texture TOC that is created. So in your case, I think your import commands can be shortened to:
// Bring up a dos window to display current status. This lets you see immediately how the import/generation process is going.
enableWinConsole(true);
// Enable logging so we get a console.log. This is useful if something goes wrong - we can check the log for errors.
setLogMode(6);
// Generate geometry from a raw 16 bit heightfield.
atlasOldGenerateChunkFileFromRaw16("GameData/data/terrains/build01/terrain.raw", 2048, 1.0, 0.0042, "GameData/data/terrains/build01/Geom.chu", 1.5, 4);
// Import from old CHU format to .atlas.
importOldAtlasCHU("GameData/data/terrains/build01/Geom.chu", "GameData/data/terrains/build01/Geometry.atlas");
// Import data from some Unique Terrian Texture. - the first number sets how much to tile the texture
//atlasGenerateTextureTOCFromLargePNG("GameData/data/terrains/build01/Opacity.png", 4, "GameData/data/terrains/build01/OpacityTex.atlas");
atlasGenerateTextureTOCFromLargeJPEG("GameData/data/terrains/build01/Lightmap.jpg", 4, "GameData/data/terrains/build01/Lightmap.atlas");
// Finally, combine into a unique-textured terrain. Notice how this command is grouped
// onto multiple lines, to make it easier to read and understand. The first four parameters
// (the .atlas files) are the output file we are generating, and the three input files we
// need (geometry data, opacity data, and lightmap data).
atlasGenerateBlenderTerrain(
"GameData/data/terrains/build01.atlas",
"GameData/data/terrains/build01/Geometry.atlas",
"GameData/data/terrains/build01/OpacityTex.atlas",
"GameData/data/terrains/build01/Lightmap.atlas",
// This is the size of the virtual texturemap the blender will be producing. This directly affects how much the source images are tiled, so it is
// hardcoded into the terrain. This must be a power of 2 - if you get it wrong the engine will nicely let you know and suggest some alternatives
32768,
// These are the source textures that the blender will be using. List them in the REVERSE order that L3DT shows in the alpha map export
// wizard. If you specify too few, then your terrain may cause the engine to crash.
"GameData/data/terrains/textures/tile1",
"GameData/data/terrains/textures/tile2",
"GameData/data/terrains/textures/tile3",
"GameData/data/terrains/textures/tile4"
);
echo("done"); 
#45
@Ves:
You could always store 4 sub textures per larger actual texture then just offset UVs to access the correct sub texture? You get all texture reads from the same texture as a bonus (gains on some cards), and you could bump
up your texture count 4x too/
10/03/2007 (10:59 am)
Quote:
This monster shader reached the texture register limit last night as I am now passing a texture in for all 16 of the avialable registers for shader V 2.0. Thats :
4 diffuse textures (one per clipmap level)
4 lightmap textures (one per climpmap level)
4 opacity textures (one per clipmap level)
4 Bumpmap textures (one per terrian type)
@Ves:
You could always store 4 sub textures per larger actual texture then just offset UVs to access the correct sub texture? You get all texture reads from the same texture as a bonus (gains on some cards), and you could bump
up your texture count 4x too/
#46
I really like how i5.photobucket.com/albums/y153/vesuvias/bumpy1.jpg looks.
I wonder if it would be possible to multi-pass the specular by giving just a specular mask texture and doing the effect in SM1.x. That would be awesome for snow/ice levels. Even for other levels a very low level of specular might boost the realism quite a bit.
10/03/2007 (11:25 am)
Cool work guys.I really like how i5.photobucket.com/albums/y153/vesuvias/bumpy1.jpg looks.
I wonder if it would be possible to multi-pass the specular by giving just a specular mask texture and doing the effect in SM1.x. That would be awesome for snow/ice levels. Even for other levels a very low level of specular might boost the realism quite a bit.
#47
Edit: Forget all that .cs file conversion stuff. You can and will mess something up. Make a new climate in L3DT with just 4 textures and let Aaron/Ben do their automagical exporting for you. Sure, it says unique only, but with this codework from Ves, that no longer matters.
10/03/2007 (3:57 pm)
Blurry textures are most likely caused by setting your horizontal res too high. Atlas still looks great (geo wise) witha setting of 10-20, and gives a nice, massive terrain, but it simply won't texture properly. Make a small terrain with a horizontal setting of 1-2 (meters per pixel) and notice an incredible difference in quality!Edit: Forget all that .cs file conversion stuff. You can and will mess something up. Make a new climate in L3DT with just 4 textures and let Aaron/Ben do their automagical exporting for you. Sure, it says unique only, but with this codework from Ves, that no longer matters.
#48
Still, I can't see why im suffering from blurred textures unless im doing something colossally wrong? My Clipmap size is set to 1024 in prefs, for OUT.tex1 = input.masterTex ive tried 256, 512, 1024 - no difference.
Only thing I have noticed is my Atlas build is running a much older EXE, when I try a stock 1.3 is crashes on doing Lightmaps - still not sure if that would make any difference? (just managed to do one compile with it, same blur)
Ive yet to install Ves's resource, wanted to get this working first.
10/04/2007 (2:28 am)
Mark Dynna: Thanks, well the reason my script was slightly odd was it came from an old TDN page, and when I adjusted it to use "FromLarge" is would crash - so suspect I must have done a type (yours is working great)Still, I can't see why im suffering from blurred textures unless im doing something colossally wrong? My Clipmap size is set to 1024 in prefs, for OUT.tex1 = input.masterTex ive tried 256, 512, 1024 - no difference.
Only thing I have noticed is my Atlas build is running a much older EXE, when I try a stock 1.3 is crashes on doing Lightmaps - still not sure if that would make any difference? (just managed to do one compile with it, same blur)
Ive yet to install Ves's resource, wanted to get this working first.
#49
main.cs (0): Unable to find function atlasGenerateTextureTOCFromLargePNG
Any suggestions?
10/06/2007 (6:42 am)
Right, just found the reason why I was using my originally odd compiling script, it was because when you have "atlasGenerateTextureTOCFromLargePNG" for the Opacity map it comes up with:main.cs (0): Unable to find function atlasGenerateTextureTOCFromLargePNG
Any suggestions?
#50
You can't specify a depth, but you were specifying a 0 depth to begin with so it shouldn't be a problem. You just need it in an atlas format.
I'll try to explain the blurry texture thing the best I can but it has to do with how blended textures are clipmapped in the blended terrains. The code work in this resource circumvents that whole issue by simply doing everything in one pass (thus we get a monster shader) but it also completely breaks texture clipmapping.
What happens is the initial diffuse texture is prepared on a chunk by chunk basis. The exact workings of what happens is in atlasClipMapBlenderCache.cpp in the doRectUpdate method. But to sum up basically each Chunk gets its own private texture map. Which seems nice at first but it will eat texture memory for breakfast. Everytime doRectUpdate is called we construct a flat quad that would encompass the whole screen (virtual screen since we are rendering to a texture). Then we blit in our opacity data that is relivent to this chunk (think of each chunk as mapping perfectly to a rectangular area on the original opacity map). This opacity data is passed into the shader along with each of the 4 blender textures. The blend is then done in the shader and the results are mapped to this chunks texture. Now its important to note that performance isn't harmed as much by this pass since it does not happen every frame. doRectUpdate is only called when the chunk needs to update its texture clipmap. When I was observing this it happened around once a second for each chunk when I moving consistently in a direction.
Every Frame we render atlas terrian which happens in atlasclipmapbatcher.cpp. That step involves multiply passes in stock tgea. A diffuse pass which takes the chunk's texture which we rendered above and then applies it to the acutal atlas geometry. A detail pass which multiplies the defuse by a detail texture. A dynamic lightmap pass which will render a whole pass for each seperate dynamic light (there is a limit though). And finally a Fog pass for fog effects. If you have AFX for TGEA there is also an AFX pass for rendering zodiacs.
The key point to understand is that we take the texture map that is unique to the chunk and stretch it out and fit it across the entire chunk. When we stretch that texture out to cover the whole chunk we don't get as much resolution as we think we should. Say we have set the virtual texture size big enough to produce a 512x512 texture for each chunk, say also that each chunk represents a 32x32 section of our heightmap (we will never EVER get 32x32 actual verts out of this though, but thats a different discussion). Assume that we specified a horizontal spacing of 1m to make things easy:
32x32 = 1024 meter in that area
512x512 = 262144 pixels to cover that area
What that means is that for each meter we are coverd by roughly 262144/1024 = 256 pixels which is a 16x16 texture for 1 square meter. That is not what we are used to expecting from a blended terrian texture buts its not too bad either. Say we increase the horizontal spacing to 10m and now that 16x16 texture section covers a 10x10m^2 area (Yuk!!!).
The 128 multiplier I mentioned before effects the texture tiling before its rendered to texure in the doRectUpdate pass. It has effect only on the tiling not the acutal resolution which is still constrained by the virtual texture size.
It's probably necessary for me to admit that the images I am producing are looking good not just because of bumpmapping but also because I am COMPLETELY circumventing the chunks personal texture render step. I don't lose resolution there because I instead render directly to the terrain every frame.
It's personal opinoun but I HATE that clipmap step for the final diffuse texture. Admitiedly the opacity map and lightmap may get some benefit from the clipmapping but blended terrrain is supposed to gain benefit from high res texture maps that look great closeup.
I hope someone finds that explanation useful, I am no expert so I reserve the right to have royally missed a major aspect of the innerworking of the atlas blended stuff :). That was a little longer than I wanted it to be but I figured I should fess up to the other reason why things were looking good in some shots.
Ves
10/06/2007 (8:45 pm)
PuG: Try atlasConvertTextureTOC(inFile, outFile, format) the format options are: 0=JPEG,1=PNG,2=DDS. You can't specify a depth, but you were specifying a 0 depth to begin with so it shouldn't be a problem. You just need it in an atlas format.
I'll try to explain the blurry texture thing the best I can but it has to do with how blended textures are clipmapped in the blended terrains. The code work in this resource circumvents that whole issue by simply doing everything in one pass (thus we get a monster shader) but it also completely breaks texture clipmapping.
What happens is the initial diffuse texture is prepared on a chunk by chunk basis. The exact workings of what happens is in atlasClipMapBlenderCache.cpp in the doRectUpdate method. But to sum up basically each Chunk gets its own private texture map. Which seems nice at first but it will eat texture memory for breakfast. Everytime doRectUpdate is called we construct a flat quad that would encompass the whole screen (virtual screen since we are rendering to a texture). Then we blit in our opacity data that is relivent to this chunk (think of each chunk as mapping perfectly to a rectangular area on the original opacity map). This opacity data is passed into the shader along with each of the 4 blender textures. The blend is then done in the shader and the results are mapped to this chunks texture. Now its important to note that performance isn't harmed as much by this pass since it does not happen every frame. doRectUpdate is only called when the chunk needs to update its texture clipmap. When I was observing this it happened around once a second for each chunk when I moving consistently in a direction.
Every Frame we render atlas terrian which happens in atlasclipmapbatcher.cpp. That step involves multiply passes in stock tgea. A diffuse pass which takes the chunk's texture which we rendered above and then applies it to the acutal atlas geometry. A detail pass which multiplies the defuse by a detail texture. A dynamic lightmap pass which will render a whole pass for each seperate dynamic light (there is a limit though). And finally a Fog pass for fog effects. If you have AFX for TGEA there is also an AFX pass for rendering zodiacs.
The key point to understand is that we take the texture map that is unique to the chunk and stretch it out and fit it across the entire chunk. When we stretch that texture out to cover the whole chunk we don't get as much resolution as we think we should. Say we have set the virtual texture size big enough to produce a 512x512 texture for each chunk, say also that each chunk represents a 32x32 section of our heightmap (we will never EVER get 32x32 actual verts out of this though, but thats a different discussion). Assume that we specified a horizontal spacing of 1m to make things easy:
32x32 = 1024 meter in that area
512x512 = 262144 pixels to cover that area
What that means is that for each meter we are coverd by roughly 262144/1024 = 256 pixels which is a 16x16 texture for 1 square meter. That is not what we are used to expecting from a blended terrian texture buts its not too bad either. Say we increase the horizontal spacing to 10m and now that 16x16 texture section covers a 10x10m^2 area (Yuk!!!).
The 128 multiplier I mentioned before effects the texture tiling before its rendered to texure in the doRectUpdate pass. It has effect only on the tiling not the acutal resolution which is still constrained by the virtual texture size.
It's probably necessary for me to admit that the images I am producing are looking good not just because of bumpmapping but also because I am COMPLETELY circumventing the chunks personal texture render step. I don't lose resolution there because I instead render directly to the terrain every frame.
It's personal opinoun but I HATE that clipmap step for the final diffuse texture. Admitiedly the opacity map and lightmap may get some benefit from the clipmapping but blended terrrain is supposed to gain benefit from high res texture maps that look great closeup.
I hope someone finds that explanation useful, I am no expert so I reserve the right to have royally missed a major aspect of the innerworking of the atlas blended stuff :). That was a little longer than I wanted it to be but I figured I should fess up to the other reason why things were looking good in some shots.
Ves
#51
I am trying to up the number of textures but I am running into problems. It's more complicated than it seems on the surface. The problem with UV offsets is that they bleed into other textures at the boundries when tiling. We could surround the texture offset area with a 1 pixel boundry but that makes our photoshop prep step a bit more complicated. It makes the texture coord calculation a little more complicated which in turn makes the parrlax shader step more costly (as there are multiple texcoord retirievals when using it). Not huge but definatly more cumbersome.
I tried using a 3D texture to avoid these issue all togeather but that won't work since pixel blending is applied across ALL dimensions. If there was a way to apply blending across just XY and not Z in the texture then I would be golden but I don't know how to do that with current shader tech.
The real issue is adding entries to the opacity map. That will need to change in some way to mean a color lookup as opposed to a straight alpha like multiply.
I am currently trying to take a different approach. I think I will try and read in the design map from L3DT when creating the atlas file. That contains info about what texture set is used in each design square on the design map (a design square represents a 64x64 pixel area of the heightmap). That texture set can change on a square by square basis and I could emulate the change on a chunk by chunk basis. So while an individual chunk couldn't have more than 4 different textures and 4 different bumps, the entire landscape would only be limited by texture memory as each chunk could use a different set. And the great thing is that it wouldn't require any extra code in the already bloated pixel shader.
@Ben
I don't see why you couldn't do this, as specular is just an additive operation (not a multiply by diffuse then add to diffuse type operation). I am curious what that would look like. That may be how WoW does thier specular on thier terrain now that I think about it. For the life of me I could never figure out what they were doing as it looks so different from full on bumpmapped terrain but it still showed specular. I'd have to see it but it sounds very plausible. You might even be able to bury the specular map in the texture alpha channel.
Ves
10/06/2007 (9:30 pm)
Quote:You could always store 4 sub textures per larger actual texture then just offset UVs to access the correct sub texture? You get all texture reads from the same texture as a bonus (gains on some cards), and you could bump
up your texture count 4x too/
I am trying to up the number of textures but I am running into problems. It's more complicated than it seems on the surface. The problem with UV offsets is that they bleed into other textures at the boundries when tiling. We could surround the texture offset area with a 1 pixel boundry but that makes our photoshop prep step a bit more complicated. It makes the texture coord calculation a little more complicated which in turn makes the parrlax shader step more costly (as there are multiple texcoord retirievals when using it). Not huge but definatly more cumbersome.
I tried using a 3D texture to avoid these issue all togeather but that won't work since pixel blending is applied across ALL dimensions. If there was a way to apply blending across just XY and not Z in the texture then I would be golden but I don't know how to do that with current shader tech.
The real issue is adding entries to the opacity map. That will need to change in some way to mean a color lookup as opposed to a straight alpha like multiply.
I am currently trying to take a different approach. I think I will try and read in the design map from L3DT when creating the atlas file. That contains info about what texture set is used in each design square on the design map (a design square represents a 64x64 pixel area of the heightmap). That texture set can change on a square by square basis and I could emulate the change on a chunk by chunk basis. So while an individual chunk couldn't have more than 4 different textures and 4 different bumps, the entire landscape would only be limited by texture memory as each chunk could use a different set. And the great thing is that it wouldn't require any extra code in the already bloated pixel shader.
@Ben
Quote:I wonder if it would be possible to multi-pass the specular by giving just a specular mask texture and doing the effect in SM1.x. That would be awesome for snow/ice levels. Even for other levels a very low level of specular might boost the realism quite a bit.
I don't see why you couldn't do this, as specular is just an additive operation (not a multiply by diffuse then add to diffuse type operation). I am curious what that would look like. That may be how WoW does thier specular on thier terrain now that I think about it. For the life of me I could never figure out what they were doing as it looks so different from full on bumpmapped terrain but it still showed specular. I'd have to see it but it sounds very plausible. You might even be able to bury the specular map in the texture alpha channel.
Ves
#52
Tried the adjustment you suggested:
atlasConvertTextureTOC("Test/Assets/Terrain/Build/Opacity.png", "Test//Assets/Terrain/Build/OpacityTex.atlas", 1);
and comes back with:
atlasConvertTextureTOC - Opening input atlas file 'Test/Assets/Terrain/Build/Opacity.png'...
atlasConvertTextureTOC - Locating texture TOC...
atlasConvertTextureTOC - cannot load texture TOC from atlas file 'Test/Assets/Terrain/Build/Opacity.png'!
----
Side quick question, tried using a 4097 size Raw file and keep getting a Overflow, LerfHeightfield error then crash.
Regards,
10/08/2007 (6:09 am)
Hi Ves, thanks for the reply and information! think I understand some of it though need to re-read :)Tried the adjustment you suggested:
atlasConvertTextureTOC("Test/Assets/Terrain/Build/Opacity.png", "Test//Assets/Terrain/Build/OpacityTex.atlas", 1);
and comes back with:
atlasConvertTextureTOC - Opening input atlas file 'Test/Assets/Terrain/Build/Opacity.png'...
atlasConvertTextureTOC - Locating texture TOC...
atlasConvertTextureTOC - cannot load texture TOC from atlas file 'Test/Assets/Terrain/Build/Opacity.png'!
----
Side quick question, tried using a 4097 size Raw file and keep getting a Overflow, LerfHeightfield error then crash.
Regards,
Torque Owner PuG
Using 512 res texture tiles.
What im currently using to compile the blended Atlas:
// Bring up a dos window to display current status. This lets you see immediately how the import/generation process is going. enableWinConsole(true); // Enable logging so we get a console.log. This is useful if something goes wrong - we can check the log for errors. setLogMode(6); // Generate geometry from a raw 16 bit heightfield. atlasOldGenerateChunkFileFromRaw16("GameData/data/terrains/build01/terrain.raw", 2048, 1.0, 0.0042, "GameData/data/terrains/build01/Geom.chu", 1.5, 4); // Import from old CHU format to .atlas. importOldAtlasCHU("GameData/data/terrains/build01/Geom.chu", "GameData/data/terrains/build01/Geometry.atlas"); // Import a tiled opacity map we generated with L3DT. Note we save it in PNG format to prevent artifacts in the blend results. atlasGenerateTextureTOCFromTiles(1, "GameData/data/terrains/build01/Opacity.png", "GameData/data/terrains/build01/OpacityTex.atlas", 1); // Import a tiled lightmap we generated, as well. We store these in JPEG as a little error is not going to be noticeable. //atlasGenerateTextureTOCFromTiles(16, "GameData/data/terrains/build01/Lightmap.jpg", "GameData/data/terrains/build01/Lightmap.atlas", 0); // Import data from some Unique Terrian Texture. - the first number sets how much to tile the texture //atlasGenerateTextureTOCFromLargePNG("GameData/data/terrains/build01/Opacity.png", 4, "GameData/data/terrains/build01/OpacityTex.atlas"); atlasGenerateTextureTOCFromLargeJPEG("GameData/data/terrains/build01/Lightmap.jpg", 4, "GameData/data/terrains/build01/Lightmap.atlas"); // Import a tiled opacity map we generated with L3DT. Note we save it in PNG format to prevent artifacts in the blend results. //atlasGenerateTextureTOCFromTiles(4, "GameData/data/terrains/build01/Opacity", "GameData/data/terrains/build01/OpacityTex.atlas", 1); // Import a tiled lightmap we generated, as well. We store these in JPEG as a little error is not going to be noticeable. //atlasGenerateTextureTOCFromTiles(16, "GameData/data/terrains/build01/lightmap", "GameData/data/terrains/build01/Lightmap.atlas", 0); // Finally, combine into a unique-textured terrain. Notice how this command is grouped // onto multiple lines, to make it easier to read and understand. The first four parameters // (the .atlas files) are the output file we are generating, and the three input files we // need (geometry data, opacity data, and lightmap data). atlasGenerateBlenderTerrain( "GameData/data/terrains/build01.atlas", "GameData/data/terrains/build01/Geometry.atlas", "GameData/data/terrains/build01/OpacityTex.atlas", "GameData/data/terrains/build01/Lightmap.atlas", // This is the size of the virtual texturemap the blender will be producing. This directly affects how much the source images are tiled, so it is // hardcoded into the terrain. This must be a power of 2 - if you get it wrong the engine will nicely let you know and suggest some alternatives 32768, // These are the source textures that the blender will be using. List them in the REVERSE order that L3DT shows in the alpha map export // wizard. If you specify too few, then your terrain may cause the engine to crash. "GameData/data/terrains/textures/tile1", "GameData/data/terrains/textures/tile2", "GameData/data/terrains/textures/tile3", "GameData/data/terrains/textures/tile4" ); echo("done");