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".
