Isn't there a performance hit invovled associated with the use of a lightmap
(calculated by the application) which is applied during a texturing pass
compared to using the vertex normals for shading? Vertex-shading is done in
hardware but can result in a lower resolution than lightmaps. Lightmaps
require an extra texturing pass, but at a potential higher resolution? Does
anyone have any experience performance-wise conparing between these two
approaches?
Allan
----- Original Message -----
From: "David Yazel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 4:00 AM
Subject: Re: [JAVA3D] multitexturing and OpenGL Extensions
> 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".
===========================================================================
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".
