Yes thats one of the problems with a lot of terrain algorthms (ROAM, etc).
Most of these techniques concentrate on the geometry and don't handle the
texturing very well. They work great until you try to texture them. If you
go and see all the great screenshots of terrain engines at www.flipcode.com
you will find that all of them use one big texture over a small world. This
technique breaks down over a larger world. Pixel shaders is another way to
do it, and better, but its not yet supported in Java3d, and not very well
supported in hardware.
The multi-texturing does let you hide the pixel stretching though. You
don't *really* need a super high density ground texture to produce nice
results. For grins I quadrupled the density of our ground textures and the
result was certainly better, but not amzaingly so.
Try using multi-texturing on a stretchy base texture and I think you will be
pleased.
David Yazel
----- Original Message -----
From: Michael Nischt <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 28, 2001 9:42 PM
Subject: Re: [JAVA3D] multitexturing and OpenGL Extensions
also thanks again to you david,
but i guess every of your pre-generated base-texture is on one primitve,
because of using a quadtree.
but i am not, i got ONE HUGE primitive wich is only partly rendered at frame
(changing the indexCounts and indexCoordinates), so still my problem still
iexists:
if i would use one texture on the landscape, the texture won't be culled and
i have to use one about 2048x2048 pixels, otherwise i would see only huge
pixels..
this is why i tought of using many smaller textures on this primiteve - not
layered, all aside another..
greetings
Michael Nischt
------------------------------
e-mail: [EMAIL PROTECTED]
homepage: http://zero.atariflys.de
---------------------------------------------------------------
----- Original Message -----
From: "David Yazel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 2:55 AM
Subject: Re: [JAVA3D] multitexturing and OpenGL Extensions
> 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".
===========================================================================
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".
===========================================================================
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".
