We are doing the same thing as Philip recommends. But the base textures we
are generating uniquely for all landscape patches according terrain maps,
normals, blends, paths, roads and various and sundry other techniques. In
fact it takes an hour on a 700 MHz machine to generate all the textures for
a 12.8 km x 12.8 km area. We then stitch the texture patches together and
resize them to build the various quadtree levels. These also are
pre-generated. So for each 263.84 square km land chunck we generate 5,461
textures for a grand total of 23 MB of textures. And our world will have 9
such land chunks weighing in at 207 mb with a total area of 1,474 square
kilometers, or 530 square miles.
Its the technique we have chosen after much debate and testing and there
many other ways to do it. It is possible for us to deform the world in
real time, but because such actions would be done in a highly localized area
its still possible to do it in real time and not kill performance. But our
deformation requirements are for things like small holes and excavations and
represent an extremely small part of the world.
But don't necessarily emulate us. Our technique has met with some citicism
on some of the game development boards, so there are many different
opinions.
Dave Yazel
----- Original Message -----
From: Michael Nischt <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 28, 2001 8:11 PM
Subject: Re: [JAVA3D] multitexturing and OpenGL Extensions
many thanks again Philip,
your answer was very clear and detailed..
so i guess i'll stuck with 2-3 detail textures (i don't need a lightmap,
cause lighting is done by vertex normals..)
but i still don'T know how to texture my terrain now:
is it possible in java3D to blend those 2-3 detail textures together
depending on the height value..?
if not perhaps depending the vertex color ?
till now i generate a unique texture from the height-data and four
detail-textures for every part in the map:
______________________
| | | | |
|__12_|__13_|__14_|__15_|
| | | | |
|__8__|___9_|__10_|__11_|
| | | | |
|__4__|___5_|__6__|__7__|
| | | | |
|__0__|___1_|__2__|__3__|
here every part'S texuture is generated with following algo.
(in my app i got 128x 128 parts each with a big stride)
but is this necesary, because every textures is mixed from only four..?
how do you apply your terrain textures ?
greetings
Michael Nischt
------------------------------
e-mail: [EMAIL PROTECTED]
homepage: http://zero.atariflys.de
---------------------------------------------------------------
....
for(int y=0; y < height; y++)
for(int x=0; x < width; x++)
{
heightValue = heightmap[(y*width)+x];
for(int i=0; i < cnt; i++)
{
texFactors[i] = getTexFactor((cnt-(i+1))*part,
heightValue+1.0f);
colorBits = textures[i].getRGB(x,y);
red[i] = (colorBits & 0x00ff0000) >> 16;
green[i] = (colorBits & 0x0000ff00) >> 8;
blue[i] = colorBits & 0x000000ff;
}
for(int i=0; i < cnt; i++)
{
mixedRed += texFactors[i] * red[i];
mixedGreen += texFactors[i] * green[i];
mixedBlue += texFactors[i] * blue[i];
}
mixedColorBits = mixedRed << 16 | mixedGreen << 8 | mixedBlue;
mixedImage.setRGB(x,y, mixedColorBits);
mixedRed = mixedGreen = mixedBlue = 0;
}
return mixedImage;
}
...
----- Original Message -----
From: Philip Taylor
To: [EMAIL PROTECTED]
Sent: Friday, June 29, 2001 1:31 AM
Subject: Re: [JAVA3D] multitexturing and OpenGL Extensions
its not the size of the texture. fetching texels is relatively cheap.
its the number of passes, and for how many pixels in the scene. consider
that each additional pass burns fill-rate.
so if you do this for an object that affects most of the pixels in the
render-target, like terrain, then your fill rate cost equation is
effectively base-fill-rate/2*number-of-passes. that chews up fill-rate fast.
if its only for characters, and only for the main ones, then you can
probably get away with this since the number of pixels in the render-target
affected by the character primitive draws isnt such a large percentage of
the entire render-target to burn fillrate at quite the same ratio.
think about how you plan to use multi-texture. its hard to see how 4
layers of texture arent sufficient in most cases:
base texture
lightmap texture
detail texture 1
detail texture 2
2 layers of detail texture allows you to apply noise/grain textures for
ground, rock, vegetation at 2 differing pixel frequencies. which is usually
enough to simulate variation across the pixels at an acceptable level of
quality unless you are flying/moving right up on the ground/grass...in which
case you need to think if your camera controls need to be that fine or if
you need to burn more fill rate for visual quality.
think about why anything more than 4 layers of texture would be required
to get the effect you are after. it might be with bump-mapping, specular,
etc that you do need multiple passes. but think it thru. its really about
what you are trying to achieve, and efficiently using the hw resources to
accomplish that task.
and thats before we get to texture renderstate changes, which arent cheap
and you will have a lot of them in cases like this - but in this case the
loss of fill-rate due to inordinate number of passes dominates the cost
equation.
final note - Gary Tarolli, ex of 3Dfx, used to show a "Borg cube" demo
where he built up 8 layers of multi-texture, the last 4 or 5 being detail
textures at different frequencies ( tiling at 2x 3x, 5x, 9x, etc number of
times across each face ) which produced quite a huge amount of visual
variation and depth. what could you possibly be doing that would need more
layers of texture than that? how does that contribute to the visual quality
of the scene, and at what cost?
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
