New Rendering not looking good

#1 I had the same problem. For me it seems there's a problem in MS 3.5 with the Atlas 1 shaders, but I could't figure out the problem and switched back to the MS 3 code.

#2 Hmm, looks like a bug has crept in somewhere. That second shot is only showing the detail texture.

#3 Check the client/scripts/shaders.cs file. I think they added new atlas2 shaders in there. check the demo app for the shaders.

#4 These are using the old Atlas 1 CHU and TQT files. Will the Atlas2 shader work for those?

#5 Are you bringing over the new atlas shaders? They HAVE moved.

You need to import the CHU and TQT files to the atlas2 file formats.

The old Atlas code is present and should run but similarly I updated the scripts to point to new shader locations.

#6 Ok, I'll look for the new shader locations. I have tried importing the CHU and TQT files to Atlas2 but I always get an "Invalid Chunk Tail Sentinel" error (see my post in the Bugs section).

If you would like my files for test I will gladly give them to you.

#7 I can reproduce it, just haven't gotten to fixing it yet. (It's 2 hours into the work week. :P)

Will look at it later today.

#8 Ok thanks Ben. I have to keep reminding myself that you guys are 2 hours behind me (can't you fix it in 2 hours? :) )!

#9 Are you 100% sure you're running that with the correct Atlas shaders?

#10 Ok I refreshed/rebuilt everything just to be sure. Now when I try to load the mission with the old Atlas1 files it says "Error Allocating Memory" and shuts down.

#11 What's the callstack?

Did you apply the MaxChunkSize fix, and if so, what does that line look like for you now?

#12 I'm not sure if its correct but I did the math and my 8192 x 8192 works out to 64 * 1024 * 1024, so that's what I changed it to. I still get the error, but here's the callstack. However, if you fix that Atlas2 "black and blue" problem, this will be a moot point.

>	TSE_DEBUG.exe!PlatformAssert::processAssert(PlatformAssert::Type assertType=Fatal, const char * filename=0x00cc7a4c, unsigned int lineNumber=190, const char * message=0x00cc7a8c)  Line 109 + 0x18	C++
 	TSE_DEBUG.exe!Memory::memoryError()  Line 190 + 0x23	C++
 	TSE_DEBUG.exe!Memory::allocPage(unsigned int pageSize=2628124308)  Line 202	C++
 	TSE_DEBUG.exe!Memory::allocMemPage(unsigned int pageSize=2628124276)  Line 943 + 0x9	C++
 	TSE_DEBUG.exe!Memory::alloc(unsigned int size=2628124208, bool array=true, const char * fileName=0x00cdac24, const unsigned int line=140)  Line 1043 + 0x9	C++
 	TSE_DEBUG.exe!operator new[](unsigned int size=2628124208, const char * fileName=0x00cdac24, const unsigned int line=140)  Line 1338 + 0x13	C++
 	TSE_DEBUG.exe!AtlasTQTFile::loadDDS(const unsigned int level=0, Point2I pos={...})  Line 140 + 0x17	C++
 	TSE_DEBUG.exe!AtlasResource::processThreadTexRequests()  Line 648 + 0x32	C++
 	TSE_DEBUG.exe!AtlasResource::loaderThread()  Line 692 + 0xc	C++
 	TSE_DEBUG.exe!loaderThunk(void * arg=0x01dcf910)  Line 238	C++
 	TSE_DEBUG.exe!Thread::run(void * arg=0x01dcf910)  Line 85 + 0xb	C++
 	TSE_DEBUG.exe!ThreadRunHandler(void * arg=0x033022e8)  Line 54 + 0x1a	C++
 	kernel32.dll!7c80b50b() 	
 	kernel32.dll!7c8399f3()

#13 You should only have needed to change it to around 8 megs - it only needs to store one tile at a time, max, and DDS gives you ~4:1 compression.

It's trying to allocate 2+gigs of ram to load a DDS file. Either a corrupt file, or you have a mixed up setting somewhere. :)

What are the exact calls you're using to create your files?

#14 It's an 8192 heightfield, square size 4, vertical scale 3000 / 65536, error 30, depth 3. I'll try re-creating the CHU and TQT when I get home. Possibly with a deeper tree? The reason I was running it at 3 is I was trying to keep the poly count as high as I could because the terrain looked so "pointy." I've had the EM as low as 6 with these files but at that level the Depth needed to be 8 and that caused a lot of "seams" in the texture of the terrain.

#15 It's loading texture data here, so (in general) your geometry settings don't matter. Just what the TQT file is doing (or how you're importing the texture data if you're not bringing it from a TQT).

#16 I created the TQT with the same depth as the CHU file. I'm just using the standard Atlas1 code to instance the terrain in the mission. I don't think I'm understanding what your asking.

#17 Oh right. D'oh!

What I'm saying is that the texture paging code is seperate from the geometry paging code so I don't need to know anything about your geometry, just your texture data.

#18 Ok then. I created the TQT with a depth of 3. Actually now that I think of it, I think I created it with a depth of 4 due to your new code limited the individual tile size to 1024.

#19 (Changing the limit is pretty easy - there's a constant to change in bitmapPNG.cpp)

From a source texture of 8k by 8k, eh? Interesting.

What happens if you import it to atlas2 - just color swapping, or more heinous behavior?

#20 You mean importing the TQT directly? I haven't done that for Atlas2. I've only done my Atlas2 testing my going back to the JPG and creating the texture from there (atlasGenerateTextureTOCFromLargeJPEG). What's the console function to import a TQT? Maybe I'm really missing something but I don't see any documentation on how the old TQT file can be imported/converted. Is this where atlasConvertTextureTOC comes in?