Four problems with atlas 2

#1 1) I added the following lines of code to atlasImportTiles.cpp

dSprintf(buff, 512, tileMask, imgX, imgY);
         GBitmap *bmp = GBitmap::load(buff);

         if(!bmp)
         {
            Con::errorf("atlasGenerateTextureTOCFromTiles - unable to open tile '%s'! Aborting!", buff);
            return;
         }

// added the following two lines to pre reverse the rgb channels ;)
	 bmp->convertToBGRx();
	 bmp->sgAlreadyConverted = false;

         // Create a chunk to store this data in.
         AtlasTexChunk *atc = new AtlasTexChunk;
         atc->mFormat = (AtlasTexChunk::TexFormat)outFormat;
         atc->bitmap = bmp;

I'm not sure that's a good way to fix it but it does fix it.

2,3,4) Wish I could help but I have the same problems too.

#2 Fix for problem number 2:

in C:\Torque\TSEms4\tse\engine\atlas\runtime\atlasClipMapUniqueCache.cpp line 116

Change this for(S32 i = mAitToc->getTreeDepth()-1; i >= mLevelOffset; i--)



to this for(S32 i = mAitToc->getTreeDepth()-1; i > mLevelOffset; i--)
//i >= mLevelOffset becomes i > mLevelOffset

i dont think that this is the real fix but i can now at least load files with leaf sizes greater than 256px.
I loaded a file with a 512px leaf size just fine but when i tried 1024px half of the terrain turned black. As I walked closer to the black area it started to get textured.

#3 Hey Afrim,
The RGB swap issue has been well documented (by myself and others) in MS3.5. You can look for a thread about it called "Red/Blue Channel swap in texture" if you are curious. The most obvious way to avoid the swap is to create the texture .atlas file from the main.cs file, right at the top before the engine loads. Also, in photoshop, you can record a series of actions, then play them on all files in a folder. Essentially, create a new action (on the history tab window), record your work on one file, and then play they action on all the files using the ""Batch Processing" tool. I can walk you through it more precisely if you need help. I've done as many as 4096 files at once, doing a channel swap and rotation.

Granted, my knowledge all pertains to MS3.5 at the moment. I just got back from vacation and haven't touched MS4 yet, so I don't know if your color swap is even the same issue. Hopefully I'll have some time in the next week or so to get caught up on all the fun, then I can be of more help.

#4 Your method worked fine in MS3.5 but it doesn't seem to work in MS4. I'm too lazy to try and figure out what changed. I have a main.cs that I use to generate terrains and it works fine in MS3.5 but not MS4.

Photoshop costs money and I am a cheap ass monkey :)

#5 Do you have the correct shaders in? Otherwise it'll likely look less than stellar.

I'm a bit worried you're having RGB swapping issues, as I did a significant amount of work to prevent that from happening. Are you sure you're using a clean checkout? What does the body of your AtlasTexChunk::process() look like? (in atlas/resource/atlasTexChunk.cpp IIRC)

#6 I'm pretty sure I have the correct shaders. I copied them from the water demo scripts. I'm also confident that I have the latests source as of a week ago.

Just did an update and it appears some things were modified. I will test later and see if the RGB/BGR thing works correctly. I guess things are still in flux so I should be more diligent about updating from cvs.

#7 If the problem continues, a screenshot or two would be pretty useful in helping me figure out what's up!

#8 @Ben this is the body of the AtlasTexChunk::process() function

void AtlasTexChunk::process()
{
}

while you are here, what do you think about the other problems especialy number 2?
The same problem is also discussed here www.garagegames.com/mg/forums/result.thread.php?qt=50369

As alexis mentioned I have the latest TSE as of a week ago when everyone discovered that MS4 was up on CVS.

#9 I still have the problem. this is at the top of my main.cs file

atlasOldGenerateChunkFileFromRaw16("MyGame/testterrain/hf.RAW", 1024, 10.0, 1.0/60, "MyGame/hf.chu", 1, 6);
importOldAtlasCHU("MyGame/hf.chu", "MyGame/geometry.atlas");
atlasGenerateTextureTOCFromTiles( 32, "MyGame/testterrain/texture_x%dy%d", "MyGame/texture.atlas", 1 );
atlasGenerateUniqueTerrain("starter.fps/test.atlas", "MyGame/geometry.atlas", "MyGame/texture.atlas");
quit();

screenshot

screenshot


one of the texture images


I can post a zip of all the images and terrain I use if you want me too.

#10 Yup that's exactly what I was getting! Not only that but I also have to flip the image vertically in photoshop so that it aligns correctly with the geometry in the engine. Documentation in TDN says to rotate 90 degrees unless you are using latest beta version of L3DT, which I am. Then again that can be an L3DT problem.

#11 Same for me! So +1

I have to flip the textures generated by the latest l3dt vertically and then swap the red and blue channels in PhotoShop - else I get the same problem as reported by the others. Damn irritating

#12 Flipping vertically is a fact of life, I think. My knowledge is still related to MS3.5, but I've always always always flipped my imagery vertically, and rotated my geometry 90 degrees clockwise. It's just part of my processing pipeline.

As for the texture channel swapping... what happens if you run the import tiles command after the engine is loaded (from the console line, not the top of main.cs)? Does that have any effect? In MS3.5 (I believe), there was some code that swapped RGB to BGR for the sake of working with L3DT (or something), but I would have assumed that would have been cleaned up when Ben rewrote the atlas generation routines.

#13 I have running the commands in all possible ways but the RGB swapping still happens.

#14 My personal fix for the RGB channel swap was to modify the shader so it would draw correctly. It's too crazy (IMO) to be modifying images in photoshop as I know sooner or later I will forget to change one ;^) Not to mention then the bug gets fixed and all your textures are messed up and you have to rebuild them all.

In my equivalent of atlasSurfaceP.hlsl I made a change like below. It assumes you don't need the alpha channel value at all, or rather that it is always equal to 1.0.

...
   float4 diffuseColor = tex2D(diffuseMap, IN.texCoord)

   // --- Swap the Red and Green channels using the Alpha as scratch space
   diffuseColor.a = diffuseColor.r;
   diffuseColor.r = diffuseColor.g;
   diffuseColor.g = diffuseColor.a;
   diffuseColor.a = 1.0;
...

#15 Well nuts. I spent like a week testing with L3DT and making sure that you could import art from it with zero changes and that it would work properly.

At least this is reproducing on my end! I'm going to take a look - I think I have an idea what the issue is.

(For issue 2 - don't use big tiles! It slows down paging and rendering and is harder on memory allocation! Also, there are certain maximum sizes for the tiles which may cause you problems. Check atlasChunk.h for the constants.)

#16 Yup - definitely happening. Which is pretty lame as I totally tested the heck out of this case. Grr!

So, I get to revisit all of my assumptions now. I'll post as I find out more.

#17 Well, I fixed the color swapping. Now to fix the texture alignment. (BTW, this fix was to change the order of the copy in line 341 of AtlasClipMapImageCache_TextureTOC::bitblt().)

I also optimized the copy, since it appears a swap is no longer required, and because the original copy was pretty slow/lame. So now should run a bit faster. (The inner loop is about half the size, and does minimal copying of data.)

#18 And fixed the image swap. WTF!

Anyway - line 201 of atlasImportOld.cpp should read:

texCoord[i].set(pos[i].y / terrainSize.y, pos[i].x / terrainSize.x);

The code for the bitblt should read (atlasClipMapUniqueCache.cpp, line 347 or thereabouts):

else if(cnotes[i].atc->bitmap->bytesPerPixel == 3)
            {
               // Do a fast little copy
               const U8 *curIn = bmpBits;
               const U8 *endIn = (bmpBits + (cnotes[i].colEnd - cnotes[i].colStart) * 3);
               U32 *curOut = (U32*)outBits;

               while(curIn < endIn)
               {
                  *curOut = (*(U32*)curIn) & 0x00FFFFFF;
                  curIn+=3;
                  curOut++;
               }
            }
            else

So I've no idea why all this stuff broke, but those are the fixes. Next CVS update should have them in it. Applying these changes should mean you can import L3DT data w/ no modifications (at least, I can do that now and I couldn't before).

#19 There is also a setting in L3DT , export to raw, InvertY: true. I'll bet some of us are running one setting, others another.

#20 Ben Garney wrote:

Quote:(For issue 2 - don't use big tiles! It slows down paging and rendering and is harder on memory allocation! Also, there are certain maximum sizes for the tiles which may cause you problems. Check atlasChunk.h for the constants.)

Ben I must be confused about getting a higher resolution terrain. How would I go about getting more detail into a smaller area. As I said before, I have tried importing an 8k by 8k texture but I dont see much of a difference in resolution.

Say I want to use an 8k by 8k texture on a 1k by 1k height map. The tree depth of the geometry must match the tree depth of the texture correct? To get smaller tiles out of a large texture I need to increase the tree depth of the texture. But If I increase the tree depth of my 1k by 1k height map it tells me to try and use a lower number like 3 for better performance. What is the optimal balance and is it possible for the texture to be independent of the geometry.

I would like my 1 meter by 1 meter world unit to be textured by at least a 512px tile. From first person point of view, on a high resolution monitor even that looks pixilated.

In other words, I don't want to have to increase my poly count just to get a higher resolution texture. My terrain could be a flat square with like 2 polys. What is the best way to go about this other than making it a dif?