L3DT users' community
Large 3D terrain generator

Progress on v2.4 beta3

Important stuff.

Postby Aaron » Mon May 29, 2006 2:05 pm

DeathTwister wrote:When we import our terrains into TSE for those that have TSE that is. Does the bump mapping follow into TSE natuerly? I would think it wouldn't and is L3DT specific, but I am not sure how TSE interpolates all the info when it comes in. I wouild think, correct me if I am wrong please as I am a newbie here, that we would add the bumping with a bump map overlay like in TGE? Does it do it that way as well in TSE? besides the other ways you are talking about Josh?


Yes and no. You get the bump-mapping that L3DT bakes onto the light-map and texture. You don't get any of the run-time bump-mapping that TSE/TGE does - you have to set that up yourself.
User avatar
Aaron
Site Admin
 
Posts: 3691
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby DeathTwister » Mon May 29, 2006 8:08 pm

yup yup ,

got lots of work to do, posted 2 shots on other post of inside TSE screen shots.

http://www.bundysoft.com/phpBB2/viewtopic.php?p=1033#1033

Hmmm, cant wait for the new build you are working on, looking forward to it Aaron, any day now I am thinking /smiles......

DT :twisted:
User avatar
DeathTwister
Dearly missed
 
Posts: 562
Joined: Thu Dec 15, 2005 12:30 pm
Location: Klamath, CA.

Postby Joshua » Mon May 29, 2006 11:28 pm

aaron wrote:Hi Joshua,
I'm not quite sure I understand you here. Baking on the normal-map detail can be done now (bump-mapping, yes?), but surely parallax-mapping is view-dependent, so you have to do that at run-time. Have I misunderstood?

You're not too far astray! Parallax mapping simply adds a heightmap to the Alpha channel of a normal map, and then off-sets UV coordinates so that the surface occuls itself. Of course it requires a real-time element (the shader, which could be found in various places on the web, in various forms), but the asset generation is what I was suggesting:
Generate a tangent (if the terrain is deformable) or world (more efficient) space normal map that contains the finest detail level for the terrain's diffuse texture (and not any actual terrain information), including blades of grass and pebbles and such, and create a heightmap that displays the same surface detail as a grayscale heightmap. This texture map could be loaded into any normal/parallax map solution, and we'd see the individal blades of grass occulling each other, and each pebble would look as if it had geometric properties.

Here's an example of Parallax Occulsion Mapping:
http://www2.ati.com/stream/radeonx1k/AT ... p-v1.1.mpg


aaron wrote:That's just a matter of switching the grass textures for dirt/moss and baking-on the appropriate detail/bump-map. I'll make a demo climate for this after I've got beta3 out the door.

Awesome. :wink:



aaron wrote:This is what I'm aiming for with the 'temperate' climate (with reference to this image). Further improvements are possible, of course, as I've only spend a few minutes tweaking the grass textures.

If anyone can pull it off, I've no doubt it's you.


aaron wrote:Sounds quite reasonable. Hopefully this won't stray too far into the megatexturing thread, but could you discuss the benefits of using a high-res unique texture for the close-up dirt/moss when compared to splatting the same thing? I would have thought that since the close-up ground texture is only visible over a very small distance (<20m), and is largely obscured by grass geometry, splatting would look pretty good. Just curious.

Well admittedly, this technique is implied to have full textures being displayed rather than splats, but the concept could apply to any technique where LODing comes into play.

Splatting, by it's very nature looks good:
http://www.cbloom.com/3d/splatting/index.html

This is especially true up-close where high resolution splat textures can show off as much detail as the developers pack into them. You can also attach normal/parallax maps to each splat texture to easily add extra implied detail, without too much complexity.

One downside to the technique though, is that it is very expensive for the GPU. As a result, some limitations are usually put into effect. One technique is to splat only very close to the camera (or world-position), and then alpha blend into a low resolution (which it must be to fit entirely into video memory) standard diffuse texture to represent the rest of the world.

Another limitation is the amount of textures that you can "splat between" on any given area. I've heard that you use over 10 texture blends at a single location, whereas anything over 4 or 5 in a real-time splatting situation quickly becomes expensive. As a result an L3DT user must find a way to smoothly transition between the rather cruder up-close splatted world with the pregenerated, more complex L3DT generated terrain.

And what happens if you decide that the diffuse texture that you've managed to cram into video memory isn't impressive enough (Oblivion is an example of this problem. While this shot is nice and polished, any time there isn't foliage covering up their second level of detail the terrain looks horrible)? Developers must then design some sort of LODing system to swap out parts of textures to represent the terrain after the "splatting level" at varying levels of detail. Of course they couldn't fit all of this into memory at any one time, and we're front and center where megatextures begins.

So in short, splatting does look great, and while it doesn't offer uniqueness it certainly can contain and blend a good level of detail.

However it is a resource hog, and as a result many crippling limitations must be added to the equation to get it working correctly.

A nested chunk based image solution (not necessarily Megatextures, we're actually using GeoClipMaps) on the other hand, allows you to use those same complex algorithms that you used to create your beautiful terrains exactly as they are, and intelligently displayed so as to consume less resources and in some implementations require no shaders whatsoever. As a result, we have more control over the solution, and the final results. We can touch up individual areas (more frequently visited roads lets say) by hand. And unlike splatting, our total image detail size has very few limits. With GeoClipMapping, two researchers got a 40GB texture of the US working real-time seamlessly at 60 FPS (http://research.microsoft.com/~hoppe/). The amount of detail we want to incorporate can scale much more easily as well. With simple user settings, we can easily toggle the highest clipmap size to scale too, so that a game project can scale up as the graphics cards do, to a degree.

The real challenge is developing the art pipeline tools such as L3DT which can create terrain and textures that contain the level of detail needed. I've heard people complain in various forums that Carmack's terrains in his screenshots weren't earth-shattering (although I think they are actually rather good). This has nothing to do with his technology but rather his art creation pipeline.

There is no terrain package out there that can do this to the level demanded by the next-generation of game titles. We worked with a middleware company for terrain for a brief while that I won't name. Basically for over 50,000 USD they would incorporate their solution of terrain rendering, including texturing that would scale with full LOD implementation. The one problem they had, was that their highest detailed terrain was not up to snuff. Our character models literally, looked misplaced in such a low-detail enviornment.

Perhaps you can imagine the excitement me and my dev team felt when we stumbled upon your product, Aaron. I really think that your efforts are the most promising that we've seen and as I've said, if anyone can take the texturing to the next level it's L3DT.

So was that reply long enough? :twisted:
Last edited by Joshua on Mon May 29, 2006 11:46 pm, edited 2 times in total.
Joshua
Luminary
 
Posts: 59
Joined: Thu May 04, 2006 8:57 am

Postby Joshua » Mon May 29, 2006 11:31 pm

DeathTwister wrote:Is that plugin at their website? what is the name again? I want it /smiles..have a link by chance handy?

DT

http://developer.nvidia.com/object/photoshop_dds_plugins.html
Joshua
Luminary
 
Posts: 59
Joined: Thu May 04, 2006 8:57 am

Postby monks » Tue May 30, 2006 10:17 pm

Thanks for the link DT to the image rectifier- the texture thing- that's a pretty clever app to do that. 8)
How you getting on with the texture library?

As you can probably tell I've lost track of this thread- things move so quickly, so apologies to folks for 'disappearing' mid-convo :lol: I think I must be flitting between 8 different forums (fora) :roll:

The new grass shots: Aaron, the second is definately an improvement. I think I'm being a little unfair here- as I'm really judging the textures from a rendering (raytracing) perspective, which is barmy. I'd be interested to see slightly darker (ie more lush) greens.
The noise is more complex in the grass texture- like you said Aaron, less 'splodgy'.

Joshua wrote:
Oblivion takes an unrealistic but interesting approach. The texture that goes below grass isn't supposed to represent grass, but it's green. This extends into the distance while the geometry-based grass fades away.


That's a feature that WCS (World Construction Set) has. You can use 3D objects all the way if you like, (or 2D images even), but you get the option of replacing flat textures at user-definable (optimal) distances. you even get complex fade control. It works well- I'd generally employ it further away than in the Oblivion shot, but it's a completely different enviroment in terms of user interaction, and renderer load.
Project Offset got a mention I see- drool 8)

monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Postby Aaron » Wed May 31, 2006 7:22 am

Hi Monks,

monks wrote:I'd be interested to see slightly darker (ie more lush) greens.


The next release has an interface that allows you to re-balance the textures of land types in L3DT, so 'greener greens' are easy to do.

Cheers,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3691
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby Joshua » Wed May 31, 2006 9:19 am

That definately sounds interesting. :wink:
Joshua
Luminary
 
Posts: 59
Joined: Thu May 04, 2006 8:57 am

Postby DeathTwister » Wed May 31, 2006 3:13 pm

Hay all,

Monks Wrote:
Thanks for the link DT to the image rectifier- the texture thing- that's a pretty clever app to do that. Cool
How you getting on with the texture library?


HEHe, No Problimo brother, any time I can help.

I will post on the texture blog here in a few after going through all the posts this morning here. Hehe men am I bizzy all of a sudden, chit be flying everywhere, and that not a bad thing atm, ROTFL 8).

DT :twisted:
User avatar
DeathTwister
Dearly missed
 
Posts: 562
Joined: Thu Dec 15, 2005 12:30 pm
Location: Klamath, CA.

Postby Aaron » Thu Jun 01, 2006 11:59 am

Hi Joshua,

Thankyou for the info. It's cleared up a number things for me.

Joshua wrote:Generate a tangent (if the terrain is deformable) or world (more efficient) space normal map that contains the finest detail level for the terrain's diffuse texture (and not any actual terrain information), including blades of grass and pebbles and such, and create a heightmap that displays the same surface detail as a grayscale heightmap.


Can do. I'll pop it on the to-do list.

Joshua wrote:I've heard that you use over 10 texture blends at a single location, whereas anything over 4 or 5 in a real-time splatting situation quickly becomes expensive.


Ten is probably a low estimate nowadays. The latest 'temperate' climate has 25 land types, with each land-type having 2-4 textures each (there's no limit on this number either, except available RAM). So, in a worst-case with the temperate climate, you could have 75-odd textures in a small area if your attributes map is crazy (and it can be, if you want it to be).

From my perspective, it's actually quite nice not to have to seriously fret about reducing calculation-time or memory usage, since it's all off-line. That's not to say that I don't care about resources – but I only care enough to keep things usable. However, I imagine splatting requires a lot of careful optimisation to shave-off unnecessary cycles, since it's so hard on the GPU. Is clip-mapping huge textures more forgiving here? Certainly you need clever algorithms to properly manage your texture cache, but is it, for example, necessary to really worry about in-lining functions or re-writing critical code in assembly? (that sort of stuff gives me the willies). To put it another way, is the coding for clip-mapping less 'voodoo' than for splatting?

Joshua wrote:Basically for over 50,000 USD they would incorporate their solution of terrain rendering, including texturing that would scale with full LOD implementation. The one problem they had, was that their highest detailed terrain was not up to snuff.


Glarfgh...[please excuse me whilst I recover my jaw from the floor]. That does seem a bit steep.

Joshua wrote:So was that reply long enough? :twisted:


Indeed, very informative. Thank-you very much.

Cheers,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3691
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Previous

Return to Announcements

Who is online

Users browsing this forum: No registered users and 1 guest

cron