TGEA 1.7.0 Beta 1 Bug (Maybe) - Atlas Problems
by Jeff Faust · in Torque Game Engine Advanced · 03/20/2008 (11:01 am) · 9 replies
Not sure if I'm looking at any bugs here, but would like to compare notes.
Has anyone had success converting existing atlas terrain (blended) or creating new atlas terrain for TGEA 1.7 Beta 1?
While the terrain in the AtlasDemo works (even when moved to a different project), I've had problems making my existing terrain work. (My terrain works in TGEA 1.0.3.)
First of all, the engine always looks in the wrong path for the terrain textures:
scriptsAndAssets/data/terrains/old_project_folder_name/data/terrains/blends/texture_name
When I fake it out and place the textures where it's looking, the terrain usually loads, but I get large squares of strange lighting (or strange lightmapping) that is not the same for every load.
As yet, attempts to recreate the terrain from source materials using calls to atlasGenerateBlenderTerrain(), etc. has not yielded good results and also still produces the path problem.
It's encouraging that the arcticBlended.atlas terrain used in AtlasDemo is identical to the one in TGEA 1.0.3 and that it does not seem to have path problems, but I can't seem to get such nice behavior out of my own terrain.
Has anyone had any luck with this?
Has anyone had success converting existing atlas terrain (blended) or creating new atlas terrain for TGEA 1.7 Beta 1?
While the terrain in the AtlasDemo works (even when moved to a different project), I've had problems making my existing terrain work. (My terrain works in TGEA 1.0.3.)
First of all, the engine always looks in the wrong path for the terrain textures:
scriptsAndAssets/data/terrains/old_project_folder_name/data/terrains/blends/texture_name
When I fake it out and place the textures where it's looking, the terrain usually loads, but I get large squares of strange lighting (or strange lightmapping) that is not the same for every load.
As yet, attempts to recreate the terrain from source materials using calls to atlasGenerateBlenderTerrain(), etc. has not yielded good results and also still produces the path problem.
It's encouraging that the arcticBlended.atlas terrain used in AtlasDemo is identical to the one in TGEA 1.0.3 and that it does not seem to have path problems, but I can't seem to get such nice behavior out of my own terrain.
Has anyone had any luck with this?
About the author
Recent Threads
#2
03/20/2008 (11:53 am)
I haven't tried importing in any new terrains, but I have gotten atlas terrain in no problem, but I had to also do what you did and make subdirs inside of data/terrains/ to get the textures loading. Now the terrains work fine if I use a lightmapdimension. If you set lightmapdimension to 0 though where it would previously use the lightmap in the atlas file it appears to now just make the terrain full bright and uses no lightmap, which causes some ugly looking terrain. I usually get one patch when it first loads of like a purple square but that goes away once I move and doesn't come back. This only seems to happen with LightmapDimensions = 0 to me though. 
#3
03/23/2008 (4:49 am)
Same here, with lightmap dimensions set to 0 it either won't load or comes up with lovely blue squares :)
#4
03/23/2008 (4:05 pm)
Same also here, I'm using atlas blended terrain with custom lightmaps. Setting lightmap dimension to 0 produces same symptoms and setting it to anything else will simply use an engine generated lightmap instead.
#5
- I have not observed problems with the winter atlas terrain from AtlasDemo.
- Existing atlas terrain can have problems resolving the path to texture files. This seems to depend on how the paths were specified when the terrain was originally created. This problem can be temporarily remedied by placing the textures where the atlas loader looks for them.
- Existing atlas terrain with pre-made L3DT lightmaps and lightmapDimension=0 are way to bright.
- Existing atlas terrain with non-zero lightmapDimension is close to correct, but frequently renders with large rectangles of false lighting. The false lighting is intermittent and seems to alternate between 3 or 4 possible variations sometimes producing correct results.
- Existing atlas terrain with lightmapDimension=1024 can produce large areas of bright pink terrain. This does not happen with the winter atlas terrain from AtlasDemo but it does happen with terrain that looks good with a 1024-sized lightmap setting in TGEA 1.0.3.
- Attempting to regenerate atlas terrain in TGEA 1.7 using atlasOldGenerateChunkFileFromRaw16(), importOldAtlasCHU(), atlasGenerateTextureTOCFromTiles(), and atlasGenerateBlenderTerrain() produces runtime errors or terrain with very strange textures with stark primary coloring. All this with scripts and materials that are verified to work in TGEA 1.0.3.
03/23/2008 (4:18 pm)
Here is an updated summary of my current adventures with atlas in TGEA 1.7 open beta 1 (blended terrain only):- I have not observed problems with the winter atlas terrain from AtlasDemo.
- Existing atlas terrain can have problems resolving the path to texture files. This seems to depend on how the paths were specified when the terrain was originally created. This problem can be temporarily remedied by placing the textures where the atlas loader looks for them.
- Existing atlas terrain with pre-made L3DT lightmaps and lightmapDimension=0 are way to bright.
- Existing atlas terrain with non-zero lightmapDimension is close to correct, but frequently renders with large rectangles of false lighting. The false lighting is intermittent and seems to alternate between 3 or 4 possible variations sometimes producing correct results.
- Existing atlas terrain with lightmapDimension=1024 can produce large areas of bright pink terrain. This does not happen with the winter atlas terrain from AtlasDemo but it does happen with terrain that looks good with a 1024-sized lightmap setting in TGEA 1.0.3.
- Attempting to regenerate atlas terrain in TGEA 1.7 using atlasOldGenerateChunkFileFromRaw16(), importOldAtlasCHU(), atlasGenerateTextureTOCFromTiles(), and atlasGenerateBlenderTerrain() produces runtime errors or terrain with very strange textures with stark primary coloring. All this with scripts and materials that are verified to work in TGEA 1.0.3.
#6
03/24/2008 (5:55 am)
Has anyone any idea on how to get DDS-textures working on blended terrain? I mean the standard auto-mip mapping is really ruining my textures on lonfer distances. If I recall correctly someone mentioned that TGEA 1.07 Beat shoud offer real support for DDS.
#7
OUT.col = 2.0 * lm * (o.r * t1 + o.g * t2 + o.b * t3 + o.a * t4);
... why is there a 2.0 multiplier in the beginning? If you remove it the brigthness of the ligthmap is correct (makes sense).
03/24/2008 (7:44 am)
I checked out the atlasBlenderPS20P.hlsl and found something interesting; the blending is done according to this formula:OUT.col = 2.0 * lm * (o.r * t1 + o.g * t2 + o.b * t3 + o.a * t4);
... why is there a 2.0 multiplier in the beginning? If you remove it the brigthness of the ligthmap is correct (makes sense).
#8
OUT.col = 2.0 * lm * (o.r * t1 + o.g * t2 + o.b * t3 + o.a * t4);
... why is there a 2.0 multiplier in the beginning? If you remove it the brigthness of the ligthmap is correct (makes sense).
03/24/2008 (8:00 am)
I checked out the atlasBlenderPS20P.hlsl and found something interesting; the blending is done according to this formula:OUT.col = 2.0 * lm * (o.r * t1 + o.g * t2 + o.b * t3 + o.a * t4);
... why is there a 2.0 multiplier in the beginning? If you remove it the brigthness of the ligthmap is correct (makes sense).
#9
03/24/2008 (8:17 am)
The 2 * lm comes from the original Synapse Lighting Kit and how it did high dynamic range lighting. If you look in that code you'll see that the lightmap lighting was divided by 2. If things don't match anymore i'm guessing it no longer does that.
Associate Jeff Faust
Faust Logic, Inc.
I'm pretty sure now that the path problems come from the arguments I passed to atlasGenerateBlenderTerrain() when the terrain was originally created.