L3DT to Atlas plugin, some questions

[piratelord]

While I don't need to actually use this plugin, I thought I'd give it a go.

First thing I noticed is that it gave me an error message about my heightmap not being ^2 since that's what atlas requires.
As far as I understood it, this is wrong. Atlas requires a ^2+1 RAW file, which is what I had in L3DT. The +1 being the 1 pixel overlap from the adjacent tile.

Where does L3DT get all it's defaults in the advanced window? Are they calculated?
I don't actually understand most of them, since they bare no resemblance to the variables that you enter via script in TGEA.

GG's documentation on Atlas is a bit lacking and also assumes you know how it works, so I'm just trying to get my head around what the plug in is doing.

Here's the code I use:
atlasOldGenerateChunkFileFromRaw16("LegendAtlas/data/terrains/Gurth1.raw", 4096, 2, 1000/65536, "LegendAtlas/data/terrains/Gurth1.chu", 0.8, 5);
importOldAtlasCHU("LegendAtlas/data/terrains/Gurth1.chu", "LegendAtlas/data/terrains/Gurth1_geometry.atlas");
atlasGenerateTextureTOCFromLargeJPEG("LegendAtlas/data/terrains/Gurth1.jpg", 5, "LegendAtlas/data/terrains/Gurth1_texture.atlas");
atlasGenerateUniqueTerrain("LegendAtlas/data/terrains/Gurth1.atlas", "LegendAtlas/data/terrains/Gurth1_geometry.atlas", "LegendAtlas/data/terrains/Gurth1_texture.atlas");

I tell it it's a 4096 map, and supply a 16bit 4097 RAW file as instructed by GG. I give it an error factor of 0.8 and a depth of 5 (from trial and error).
Then I just tell it what image to use, and also use a depth of 5, since as I understand it, you need to texture each depth of the atlas file.


There were two reasons I wanted to test this plugin, one was for the final file size, which using L3DTs default settings produced a 40meg file, compared with my 210meg file.
The 2nd is due to this strange problem I've got http://i141.photobucket.com/albums/r75/ ... emSeam.jpg

If you can shed any light Aaron, that would be amazing.

[Aaron]

Hi Piratelord,

I can't comment on the meaning of any of the advanced settings. They're the ones that Ben specified, and the default values are his.

The 2^n requirement was what I was told. If it doesn't cause any problems, I'll enable 2^n+1 as well.

Oh, and I've got no clue when it comes to the Atlas code. Sorry.

Edit:

The texture seam: Hmmm...it looks like it's wrapping around. Do you have texture tiling enabled in OpenGL/DX/whatever is used by Atlas? Does this happen with the plugin too?

Cheers,
Aaron.

[piratelord]

Hi Aaron,

Ah, seems I know more then you then. How accurate that information I know is another matter

Strange thing that texture seam. It doesn't appear on the final texture file, so it seems atlas is doing something odd. Again, I don't know if that's due to my information being wrong, or something else.

[Aaron]

Hi Piratelord,

I recall seeing something like that seam back when L3DTVi2 was originally developed. The problem then, IIRC, was the U/V coordinates were wrapping from one back to zero at the xmax/ymax edges of the textures. Hence we got a narrow band of texture pixels from the other side of the texture tile. This makes sense with your pic too, since the blue band through your beach would come from the underwater sand at the other side of that texture tile. Massaging the U/V mapping in the renderer fixed the problem.

Cheers,
Aaron.

[piratelord]

I'm now wondering if in fact the raw file should indeed be ^2, but if you are using tiles, you must have 1 overlapping pixel, not increase the image to ^2+1.

Something I'll have to test, just a bit of a pain if that's the case.

[Aaron]

Hi Piratelord,

You certainly don't need to add a pixel row/column if you're heightfield is tiled when using the plugin. It has direct access to all the data, so you don't need to re-pack for its sake.

Cheers,
Aaron.

[fafhrd]

The +1 pixel was originally included simply because that's the way Terragen output raw files. It wasn't a requirement for any other reason. Once L3DT was discovered, Ben no longer cared about Terragens format. So... +1 pixel is only still required if you're using the old (atlas1) .chu format as an intermediary to the .atlas format. The plugin (when it ever works properly:)) bypasses chu, and writes directly to .atlas.

[piratelord]

Hmmm, is there anyway of creating the atlas file directly without using CHU? It's amazing how inconsistant the atlas routine is!

I could use the L3DT to Atlas routine, but the trouble is that I have to first do some adjustments to the generated texture map before using in Atlas, so while it's great that that tool is available, it's not really much use.

I'm after any method that will get the size of our atlas files down. Current estimate is 2.5gig of atlas files....


So, what should I be doing in Atlas/L3DT then?

Currently I export a 4097 RAW for atlas, and also use this file in L3DT, throw the final texture into photoshop, crop the canvas (since the edge pixels are untextured), do our other changes, resave the image, and then use the above code to make a atlas file.

Don't you need the overlapping 1 pixel in the atlas file to ensure that multiple tiles join up correctly?