Page 1 of 1

Some new Ideas

PostPosted: Tue Sep 09, 2008 5:26 am
by Nickadimos
Ok...

Through all my playing with l3dt, im talking daily since march I still cant get it to do exactly what i want..

For 1 The numbers dont match up;

For example... The curvature calculation. Doesnt do much, the only way to get it to is to raise it to really large numbers to overtake the other parts like Gradient and water and salinity..

So, programming this yourself on a piece of paper then translating it to l3dt, the math doesn't work.

1.) I propose, that instead of using strait numbers, you use slopes and curves to determine the placement of textures/land types.

Little picture diagrams of the degree angle for the rocks for example.

I move my curve around to show say, a perfect rainbow shape, the calculator finds areas that match that first. Then places the texture

Sharp inclines like a /\ is areas that I want rocks.

areas like this 7\ I want rocks on the incline but grass on the top.

stuff like that, then I use the other scores to determine witch texture, like water and such for shapes that match.

2.) Im finding it very difficult to have areas or lands that have both Sea water and lake water.
Usually it ends up mostly seawater, even if it is far inland. or I end up with lake-mud in the ocean.

If I lower my lakemud numbers at all the other land types will overtake it easy, so i got to have a high numbers, which ultimately the sea (most usually) ends up on land.

3.) The texture system, I love your texture system, but I find that it is lacking and I have the feeling it is mostly for spring development not for rpgs or 1st person shooters.

the truth behind your texture making jewel is the fact that the textures are so tightly bound to the heightmap, and the bounds of the total texture I am making in the last calc.

I understand your method however, you have to have a way to map it and make it part of the map to match perfectly and the only way to do this is pixel to pixel..

There is another way though.
I noticed that you have the texture splatting as part of your system here. With the alpha maps and such. This is great and all, but it is useless to anyone that doesnt have a way to get those texture splats into thier GE. And frankly my understanding of them is minimal, using them is even less.

The way to fix this is to generate UV coordinates of your attribute map and use that data to place your textures at the scale you would like instead of totally regenerating the whole thing the way yours does now. THEN renderbake all that to a texture.

Yours is kind ova in between mishmash of a couple different methods ive seen in the past.

don't get me wrong yours is the best ive seen, but if I want to see the blades of grass from my texture on a HUGE 128 by 128 map, I have to make an absolutely HUGE HUGE texture, when all this could have been solved by using the texture data in the first place. cutting and blending where they come together then saving THAT as your image.

I understand this is probably confusing, i know it is to me, but truly, I shouldn't have to make a 16kx16k texture on my 16x16x1 design map just to see my blades of grass, when I could use that small texture in any modeling program and have it tile and shift perfectly (A LOT MORE WORK THOUGH) and be able to see my grass for 1/16 the file size.

4.) All in all your program was totally worth the purchase, mainly for the design map part though. it makes it easy to design the rough outline of the area and I can translate from grid maps easily so thanks for that!! YAY

Thank you for making L3dt. PLEASE PLEASE correct me or show me the way that I might be missing!

p.s. with the strata overlays, does it only use the first row of pixels?

Thanks
Terry

PostPosted: Tue Sep 09, 2008 9:13 am
by Nickadimos
Here is a few examples in blender...

All of these are on a 64mx64m plane, with 4096 quads.

The l3dt version is on a 4x4 map with a horiz. of 1.

The Texture is a mix of another grass texture with your Grass1.jpg

It is 256kx256k texture.

All of these are rendered ON THE FLY in both Blender and L3DT

Here is the 4px per meter, it is exactly what you would see in l3dt at a resolution of 4.

Image

This is the l3dt version at 4px per meter. a 1024x1024 tex

Image

Here is the same area and everything except at 8px per meter.

Image

Here is the 8px per meter l3dt 2048x2048 tex

Image

It doesnt get much better and doubles the file size.

Here it is at 16 px per meter.

Image

Here is the l3dt 16.. 4096x4096 tex..
(it always seems to do that to me when I go anywhere over 8.... the lines I mean)

Image

There has to be a way to have a happy medium here.. a way to get all this generated like it does, but not be sooooo HUUUGE!

A few more examples.

Here is 24px per meter.

Image

Here is 32px per meter.

Image

PLEASE TELL ME WHAT IM DOING WRONG HERE!!!!! WHY CAN I GET SWEET TEXTURES IN BLENDER AND NOT IN YOURS!!!! HELP!

Re: Some new Ideas

PostPosted: Tue Sep 09, 2008 11:11 am
by Aaron
Hi Terry,

Whoa, lots to answer here; I'm not sure I'll be able to respond to it all in one go, but I'll try to answer everything over the next few days, as time permits.

Nickadimos wrote:So, programming this yourself on a piece of paper then translating it to l3dt, the math doesn't work.


Partly true. I haven't published the full algorithm, so you can't calculate results independently...unless of course you reverse-engineered the algorithm. The exact form of the land type placement algorithm is one of L3DT's 'secret sauces' that I don't intend to release.

Nickadimos wrote:1.) I propose, that instead of using strait numbers, you use slopes and curves to determine the placement of textures/land types.


I take it you're talking about a nicer user interface for the land type editor; the land type placement algorithm must, of course, work with straight numbers. If so, then yes, I've got that on my to-do list already. The land type editor gets a rewrite every few releases.

I can visualise the sort of interface you're talking about, but to be brutally honest, I think it may not be possible to translate that into functional, fast, and robust code.

...or perhaps we just need a programmer that's smarter/more creative than myself. Interested parties may, without too much ado or overheads, write a new (better) land type editor using the plugin API. I'm sure such a plugin would sell rather well, if only someone were to write it.

Nickadimos wrote:2.) Im finding it very difficult to have areas or lands that have both Sea water and lake water.


If you're using a small horizontal scale (<5m/vertex) you may need to tweak the salinity modelling coefficients to ensure a faster drop-off as a function of distance from the sea. To do this, increase the salinity linear loss parameter in the water table modelling wizard (it's under 'salin->loss param'). You'll have it about right when the values in the salinity map drop to zero in your lakes.

With your salinity map thus set up, you should find it easier to discriminate between salt/freshwater land types. I'm not going to say it will be 'easy' however. It took me several days work to balance the fresh/saltwater land types in the 'temperate (coastal)' algorithm, and I don't pretend to claim that I've got it perfectly right for all maps.

Nickadimos wrote:don't get me wrong yours is the best ive seen, but if I want to see the blades of grass from my texture on a HUGE 128 by 128 map, I have to make an absolutely HUGE HUGE texture, when all this could have been solved by using the texture data in the first place. cutting and blending where they come together then saving THAT as your image.


The best way I can figure it, you're talking about doing some sort of masked texture splatting, and then saving the result as a texture image. If so, that's exactly what L3DT's texture algorithm does at present.

-- Edit --

I've re-read what you said over a cup of hot Milo, whilst trying to think like a Blender user. In that light, I wanted to change my interpretation of your statement somewhat and elaborate some more:

I understand that you want to use the small base textures and have them tile and repeat over the terrain. This is how it works in Blender, after all. This exact approach is also used in both L3DT's pre-calculated texture generator, and in runtime texture splatting. The only difference is that the the pre-calculated textures are blended and saved, whereas the splatted textures are blended and rendered to screen, but not saved. It sounds like you want to use texture splatting.

-- End edit --

If you want high detail in your terrain textures in your game engine, you have three options:
  1. Precalculate your texture at crazy-high resolution. This is what Enemy Territory: Quake Wars uses.
  2. Blend your textures at render-time using texture splatting. This is what almost all commercial FPS games do.
  3. Procedurally generate your textures in your game engine using a fractal/perlin algorithm. Very few, if any, games use this approach any more.
There is no fourth way; either your texture is pre-generated (approach 1), or it's generated at render time (2 and 3). For FPS, most indie and commercial game engines use #2 (texture splatting), and for very good reasons.

If you must pre-calculate your texture, the only way you can achieve high detail is to have high pixel density. This means HUGE HUGE textures. The textures for ET:QW were something like 32,768x32,768 pixels in size.

Nickadimos wrote:I noticed that you have the texture splatting as part of your system here. With the alpha maps and such. This is great and all, but it is useless to anyone that doesnt have a way to get those texture splats into thier GE. And frankly my understanding of them is minimal, using them is even less.


I suggest you look into splatting more closely. If you want high texture detail, but don't want large precalculated textures, then you'll need splatting. As I said before, most commercial/indie game engines use splatting for high texture detail, and those that don't are even more complex (i.e. ET:QW's megatexture renderer).

Nickadimos wrote:I understand this is probably confusing, i know it is to me, but truly, I shouldn't have to make a 16kx16k texture on my 16x16x1 design map just to see my blades of grass, when I could use that small texture in any modeling program and have it tile and shift perfectly (A LOT MORE WORK THOUGH) and be able to see my grass for 1/16 the file size.


Your modelling programs, with their tiling and shifting of a small texture, are doing runtime texture blending. If you do this with more than one base texture (e.g. grass and dirt), it is called "texture splatting".

Grass is normally done with either splatting, or a detail map (both run-time rendering tricks, rather than pre-calculated). Here's why:

A blade of grass is, say, 5mm wide. That means that to represent a blade of grass in a pre-generated texture, you must have a pixel density of at least 1 pixel per 5mm. That's simple information limit stuff. If you have some other way to represent a feature smaller than a pixel, please let me know. Anyway, if your map is a square kilometre (typical FPS size), algebra says you'll need a texture that's two million by two million pixels to be able to render a resolvable blade of grass.

This assumes of course that the resolution is constant across your map, as it is with most currently available game engines.

Nickadimos wrote:p.s. with the strata overlays, does it only use the first row of pixels?


First column. I made the default sand strata texture 10 pixels wide only so that it could be more easily seen; only the leftmost column of pixels are used for texture blending.

Cheerio,
Aaron.

PostPosted: Tue Sep 09, 2008 11:18 am
by Aaron
Hi Terry,

I'll answer the rest of your second post as soon as I can, but I'll answer this part now:

Terry wrote:Here is the l3dt 16.. 4096x4096 tex..
(it always seems to do that to me when I go anywhere over 8.... the lines I mean)


To render 16x textures in Sapphire, you need to use a texture tile size of 1024, and for 32x it has to be 2048. Alternatively, you can reduce Sapphire's ROAM patch size, which will render a little slower but not require you to re-tile the texture. This is documented in the Sapphire user-guide.

Edit: Oh, another thing I'll point out before I wink-out for the night:

Terry wrote:All of these are rendered ON THE FLY in both Blender and L3DT


That's not quite true. The scenes may both be rendered in real time, but the textures are not both generated on the fly. The texture in Sapphire is pre-calculated by L3DT, whereas Blender is tiling a repeated texture. Thus, Blender is splatting, albeit with a single layer and an alpha map that is 100% opacity everywhere.

Cheerio,
Aaron.

PostPosted: Tue Sep 09, 2008 2:50 pm
by Aaron
Hi Terry,

Here's what I get when I run the texture generator at different resolutions, going from 1x up to 32x in multiples of two:

1x:
Image
2x:
Image
4x:
Image
8x:
Image
16x:
Image
32x:
Image

I hope you'll agree that the texture detail does indeed improve as you move from lower to higher resolutions, and every step up is noticeably better than the previous render.

I think the principal reason you didn't see much of an improvement in your Sapphire renders was that you were very close to the texture surface, and thus the texels appeared huge even at high resolutions. In contrast, your Blender renders you were a long way away, so you could easily see the change in size of the texels. Please remember that each time you halve the distance between the camera and the textured surface, you have to double the resolution of the texture to maintain the same visible detail. At some distance from the terrain texture, the required size of the texture will become impractically large (depending on your renderer, disk, etc), and you have to switch to splatting to achieve higher detail. The general consensus amongst game developers seems to be that for first-person games, where the camera is roughly 1.5-2m above the texture surface, splatting is the way to go.

Okie dokie, that's about it for my reply. Have I missed anything?

Cheerio,
Aaron.