Does L3DT work with TSE?

[andyhodges]

Is there a way to "smooth" portions of the terrain? There are a couple places where the terrain stops, unvealing a stretched part of the texture on its side.

-Andy

[DeathTwister]

WOW,

I just read Aarons post:

DeathTwister wrote:
but I am still wondering why we do not have a plugin in L3DT that will allow us to export it all out neat and clean to the exact files we need to bring into TSEA

Testing it now.

I just got all warm and fuzzy inside and all of a sudden I can't wait hahahahahahaha, your the man Aaron and I Vote you person of the Year World wide, well our worlds anyway /chuckles....

Have a ETA yet? or am I pushing???????? /drools.....

DeathTwister

[andyhodges]

Well I think I messed up. Or, something I overlooked. But is there a way to cut holes in the terrain in order to place interior objects in TSE? I have a building that's both upstairs and downstairs. The terrain appears inside of it.

Is there a work around?

-Andy

[Aaron]

Hi Andy,

On resolution, I see that my texture is 8192x8192 in resolution to help clean up any blurs. Is there a limit set to this?

There is presently a limit of 32x, but I can increase this if desired. After all, it's your hard-drive The image below, being the one I most often bandy about for high-res textures, was made using 16x texture resolution:



And here is what it looked like at 1x:



(eew!)

However, ultra high-res textures require some serious texture level-of-detail technology, because so much data is in view at any time (potentially 100's of MBs to GBs). To my understanding, this is built-in with Atlas.

In any case, there comes a point when it is more efficient to splat textures rather than handle super-sized pre-calculated textures. Just where that point lies will be renderer/implementation-dependent, so it's probably something that needs experimentation.

Is there a way to "smooth" portions of the terrain?

There's currently no way to smooth terrain in L3DT. Does anyone want to write a plugin? If not, I'll do it sometime next year.

Well I think I messed up. Or, something I overlooked. But is there a way to cut holes in the terrain in order to place interior objects in TSE? I have a building that's both upstairs and downstairs. The terrain appears inside of it.

Hmmm...tricky. One approach would be to depress the terrain under the building's footprint. However, you would need to provide a little filler-mesh to cover the edges of the pit where it separates from the building due to the relative coarseness of the terrain grid.

I've e-mailed Ben on his thoughts about actually clipping the terrain in Atlas. Some sort of volumetric cliping would be ideal, but it a workable solution would be to use a boolean mask map to clip terrain vertices. Either way, such clipping would also come in handy for things like caves, overhangs or tunnels, where a mesh would be used to fill-in the gaps.

Cheers,
Aaron.

[andyhodges]

Aaron , on that image that has the 16k x 16k, what settings did you use? Did you only increase the high-resolution in the texture setting or "attribute maps", or both?

Also, how big were your images to start with? 256k? 1024k?

-Andy

[Aaron]

Hi Andy,

I'm pretty sure that was from before the high-res attributes map, so it's just a just a high-res light map (16x) and a high-res texture map (16x). Per-pixel land types for the texture appears to be disabled, judging by the blurry snow/rock interface.

I don't recall if I was using the standard 'arctic' climate or a variant with more texture layers on the rocks. If I did have another layer, it probably would have been a layer using the same settings as the base layer (res=1), but with the layer res set to 4.

Cheers,
Aaron.

[DeathTwister]

Hi All,

Hmmm...tricky. One approach would be to depress the terrain under the building's footprint. However, you would need to provide a little filler-mesh to cover the edges of the pit where it separates from the building due to the relative coarseness of the terrain grid.

I've e-mailed Ben on his thoughts about actually clipping the terrain in Atlas. Some sort of volumetric cliping would be ideal, but it a workable solution would be to use a boolean mask map to clip terrain vertices. Either way, such clipping would also come in handy for things like caves, overhangs or tunnels, where a mesh would be used to fill-in the gaps.

Oh Hell ya /smiles and dances a jig.............need some solusion to that one, thank you very much for working on that.

DeathTwister

[andyhodges]

I just found out why I can't get "detail textures" to work in L3DT. It's not actually L3DT at all, since it shows up correctly in the viewer.

It's gotta be TSE. I read somewhere (and I can't remember) how you can resolve this with a code change in TSE.

Also, in order to make my terrains look less blurr in TSE, I have increased the UV scales. Is this dangerous? Some of them default at 0.5 and others are 1.0. If I move it up to 50.0000 it shows more detail.

PLUGIN - Does the new plugin you're working on work with Atlas editor directly?

-Andy

[andyhodges]

Here's a screenshot of my project. See how the cliffs drop down and smear the texture? And, the ground doesn't have "detail" either. I even deleted everything and went through that tutorial (chapter 1) step by step, exactly. The only difference I made was increasing the resolutions to 4k x 4k. Didn't help.

Any ideas?

[DeathTwister]

You know I may be wrong, but that looks like the Atlas paging is not working right. If it is a strait line? it may well not be you at all, but the atlas emgine. I been hearing there are still bugs in it, that may be one of them. Just a thought, sorry to see the trouble your having. I will be doing the same thing here next week, although I hope that is not one of them I am doing /wry smiles. Good luck Bro, you may want to post on GG as well with that one if Aaron has no fix.

DT

[Aaron]

Hi Andy,

To me it looks like the two tiles at that edge are following one another, but one is scaled higher than the other. This could be the old 'mosaic walls' bug:

http://www.bundysoft.com/docs/doku.php?id=l3dtvi2:buglist:mosaicwalls

One cause for the tile scales to become de-synched is when L3DT forgets to 'unify' the tile scaling of the heightfield after a calculation. Normally this is automatic, but it's possible I've missed a calculation. The manual option is (I think) 'utilities->unify mosaic scales'.

I apologise for being a bit slow here, but could you describe the export path you used? Was the heightfield exported as tiled RAW files? Were the tiles edited in some way?

I just found out why I can't get "detail textures" to work in L3DT. It's not actually L3DT at all, since it shows up correctly in the viewer.

Ah, that's kind of different. The viewer applies it's own detail texture. In fact, now that you remind me, that's the way detail maps are usually done; you modulate your relatively low resolution texture with a high resolution detail map at render-time to make it look pretty up close. I think, from vague memory, that the detail map in L3DTVi2 is baked on at 64x resolution relative to the heightfield (it might be higher). This has to be done in the renderer, and not L3DT, because the sort of resolutions required to look good (e.g. 64x, 128x, 256x) would result in colossal texture sizes. For instance, a 1024x1024 heightfield with a 128k x 128k texture might just fit on a DVD (~48Gb if bitmap, pro'ly a few GB if JPEG'd). Instead, you make your 4x or 8x texture (48Mb to 192Mb bitmap), and apply a detail map (a few hundred kBs) at 128x. The results are normally quite passable, and that's why the technique is so widely used.

Now, making the super-large textures as mentioned above is in fact a technique that is becoming more popular in recent times, or perhaps less outrageous, due to advances in mip/clipmapping for handling very large maps (see the hoopla over 'megatextures'.) Anyway, the massive unique texturing capabilities of Atlas can support textures of this scale, and at high framerates, but you still have to deal with the distribution problem that the map files are gigabyte+ per level.

Also, in order to make my terrains look less blurry in TSE, I have increased the UV scales. Is this dangerous? Some of them default at 0.5 and others are 1.0. If I move it up to 50.0000 it shows more detail.

Ah, that would presumably be the way to set your detail map scaling. I'm not sure you would want to modify your U/V coordinates for your texture, as then features in the texture would no longer match the features in the heightfield, but if you add a detail texture in modulation mode (however that's done in TSE), and set the U/V scales to ~50, you should be cooking on gas. You're right in that there is a danger, though. If you make the scaling too large, you will in all likelihood start to see features in the detail map repeating into the distance. This is the eternal problem in using small, tiling textures across large surfaces. The approach used in L3DTVi2 is to apply the detail map twice (I can't remember, maybe 64x and 128x, I dunno). This masks the repeating fairly well.

Just for completeness; the reason detail maps are also supported in L3DT was that I found when testing 16x/32x textures, I needed to apply some additional detail at the mid resolutions (~8x) to make it less bland. The grass land types, and I think the snow as well, have a detail map at around 8x res.

PLUGIN - Does the new plugin you're working on work with Atlas editor directly?

To be honest, I don't know. My fields of responsibility are building the UI, making sure L3DT provides the right data to the plugins, and providing the right functions to the plugin API to manipulate the data. The actual Atlas-specific bits are being written way over in Oregon by the Atlas gurus, and taking Gandalf's advice, I "do not meddle in the affairs of wizards." Anyway, I think it's probably better that I refrain from discussing the particular details of the plugin until GarageGames have released it for testing.

Cheers,
Aaron.

[andyhodges]

Arron, just a quick followup.

The mosiac bug, I was using L3DT Professional - v2.4b (build 20) which is dated December 9th according to the "About" box.

I uninstalled this, then installed the latest "Stable" version, re-ran the same project and it cleared up the Mosiac bug problem.

I don't know if your latest dev build has the Mosiac bug, but I just wanted to let you know.

-Andy

[Aaron]

Hi Andy,

Thanks for the info. I'll look into whether there is a problem specific to the later builds, but I think this will be common to all of them. Loading the heightfield mosaic and saving it again, or running other calculations on it, may have fixed the problem in v2.4b (as it's supposed to). What I think has happened is that one calculation that you've used didn't call UnifyScales at the end as it should have. If we can work out which calculation, then I can fix it.

If I may shift blame for a moment (;)), this is really a bug in L3DTVi2 in that it doesn't support different scales in different tiles. You won't see these tile-edge in L3DT because it properly handles the scaling in tiles. Anyway, that doesn't matter much, as we have to work with the renderer we have, so I have to fix this on my side.

Cheers,
Aaron.

[trollfiddler]

Hi lads,

Just to say that every time this has happened to me it's because I have forgotten to change the size, the squaresize or the vertSize params in the atlas chunk generation. Most often the size (e.g. when I make a 2048 terrain after doing some 1024 ones).

Cheers,

Dave.

[jack.dingler]

Just some tidbits I've come across when reading the TSE forums...

16x texture sizes may require more memory than the atlas engine can allocate.

There will be a means to cut holes in the maps, in a some later release of TSE.

There will also be a map editor and texture patiner in some future release.

SO I'm guess that if megatextures are never well supported, a blurry texture might provide a guide for painting in textures using tools that GG will provide.