gdalgorithms-list

RE: [Algorithms] Bullets on walls

[Jay S. <Ja...@va...>]

This was the first thing I tried for the bullet holes in Half-Life.  It's
really, really slow.  Once you have 3 or 4 bullet holes on a wall and a
player walks up to the wall you are redrawing the entire screen 5 or 6 times
(or more if you have complex materials).  This just doesn't scale if you
expect to have several decals on a single surface.  It's much better to clip
the decal polygons and draw them with polygon offset.

Jay

> -----Original Message-----
> From: Jaimi McEntire [mailto:ja...@al...]
> Sent: Thursday, July 20, 2000 1:01 PM
> To: gda...@li...
> Subject: RE: [Algorithms] Bullets on walls
> 
> 
> In d3d, this is the way I do it:
> 
> Create decals with a one pixel transparent border.
> Then, set the texture address mode to "Clamp".
> Calculate new UV coordinates for your decal based on the wall, instead
> of the Decal - then redraw the entire wall with your decal texture and
> new UV coordinates.
> This way you do not have to clip at all. I would assume you could
> do the same in OpenGL.
> 
> Jaimi
> 
> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of
> Tiziano Lena
> Sent: Thursday, July 20, 2000 2:19 PM
> To: gda...@li...
> Subject: [Algorithms] Bullets on walls
> 
> 
> Hi!
> I added wallmarks in my 3d engine but when I fire on the 
> border of a wall I
> would like to clip the wallmark to the wall.
> 
> I have some ideas but I think they are a bit slow... (manual clipping,
> texgen, stencil?)
> 
> How do you do this?
> 
> Thanks for any help!
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] Bullets on walls

[Steve W. <Ste...@im...>]

Now you know why only the most efficient 3D engines provide battle damage.
Stephen has indicated the industry standard for adding damage to a texture.
It's not too expensive if you find the most efficient place to code it in
your engine...it's just an extra UV calc and blt, or discover a new way.  In
either way it's one of the features that really makes a difference...cause
without it it's like shooting blanks...think about some of the other
references with that phrase...and you'll see why it's unthinkable to go
without it.  :)

R&R

> From: Stephen J Baker [mailto:sj...@li...]
> 
> On Thu, 20 Jul 2000, Jaimi McEntire wrote:
> 
> > In d3d, this is the way I do it:
> > 
> > Create decals with a one pixel transparent border.
> > Then, set the texture address mode to "Clamp".
> > Calculate new UV coordinates for your decal based on the 
> wall, instead
> > of the Decal - then redraw the entire wall with your decal 
> texture and
> > new UV coordinates.
> > This way you do not have to clip at all. I would assume you could
> > do the same in OpenGL.
>  
> Doesn't this get a bit expensive when someone fires of an entire
> clip of ammo at one wall - and then walks right up to it to
> examine the damage?  Seems like each bullethole would be another
> complete overwrite of the entire wall...bye-bye pixel-fill rate!
> 
> 
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] Bullets on walls

[Tom F. <to...@mu...>]

For D3D (and probably OpenGL), a good alternative is to move the near & far
clip planes a bit further away for those tris. You only need to move the
near clip plane if using Z-buffering. If using W-buffering, you'll need to
move both.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Neal Tringham [mailto:ne...@ps...]
> Sent: 21 July 2000 10:56
> To: gda...@li...
> Subject: Re: [Algorithms] Bullets on walls
> 
> 
> 
> Giovanni Bajo <ba...@pr...> writes:
> > In DirectX, there is a ZBIAS stuff that let you set a priority order
> > (integer) when Z matches. It is a renderstate. But looking 
> at the caps, it
> > is not supported in every boards I have tried. I heard it is an old
> thingie
> > of first Voodoo boards.
> 
> Yes, the support for zbias seems to be rather inconsistent.
> 
> > I had not found something similiar in OpenGL.
> 
> You may want to look at the 1.1 glPolygonOffset function.
> 
> 
> Neal Tringham (Sick Puppies)
> 
> ne...@ps...
> ne...@em...
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] Bullets on walls

[Angel P. <ju...@bi...>]

No, neither glPolygonOffset or moving the near clipplane will have the same
functionality as the non-existent glDepthFunc( GL_ALMOST_EQUAL )
because these two approaches will not fix the problem with the wallmark
not getting clipped at wall corners.


> For D3D (and probably OpenGL), a good alternative is to move the near &
far
> clip planes a bit further away for those tris. You only need to move the
> near clip plane if using Z-buffering. If using W-buffering, you'll need to
> move both.
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
>
> > -----Original Message-----
> > From: Neal Tringham [mailto:ne...@ps...]
> > Sent: 21 July 2000 10:56
> > To: gda...@li...
> > Subject: Re: [Algorithms] Bullets on walls
> >
> >
> >
> > Giovanni Bajo <ba...@pr...> writes:
> > > In DirectX, there is a ZBIAS stuff that let you set a priority order
> > > (integer) when Z matches. It is a renderstate. But looking
> > at the caps, it
> > > is not supported in every boards I have tried. I heard it is an old
> > thingie
> > > of first Voodoo boards.
> >
> > Yes, the support for zbias seems to be rather inconsistent.
> >
> > > I had not found something similiar in OpenGL.
> >
> > You may want to look at the 1.1 glPolygonOffset function.
> >
> >
> > Neal Tringham (Sick Puppies)
> >
> > ne...@ps...
> > ne...@em...

[Algorithms] Scorch marks on arbitrary geometry (was: Bullets on walls)

[Noel L. <ll...@ho...>]

So, after the interesting thread about putting bullets on
walls, I was wondering what people usually do to put
scorch marks (or any other decals) on arbitrary geometry.

It seems that most methods work well for regular or
"known" geometry: height fields, quads, etc.

The two ways I could think of so far are:
- Use projective textures. I haven't used this before. What kind
   of performance hit does it involve?

- Try to "face-map" the geometry we want to scorch to use
   texture coordinates from 0.0 to 1.0 in a regular way, and then
   draw it again with the scorched texture. This is particularly
   tricky if the geometry isn't face-mapped to start with, and especially
   if we want to do it without modifying the geometry at all (would need
   to find a texture transform that maps the original uvs into what we
   need).

How are people doing that today in games? Any recommendations
or ideas would be most welcome.
Cheers.


--Noel
ll...@ho...

RE: [Algorithms] Bullets on walls

[Tom F. <to...@mu...>]

We know. Nothing on the planet supports something like ALPMOST_EQUAL as far
as I know (and even if it did, that still has problems when things walk
beside the walls).

You will have to either clip the decals to the wall geometrically; draw the
wall poly with clamp texture mode & the right UVs; or composite the decals
onto a wall-shaped poly, as suggested. If drawing individual decals, which
seems a popular method, then you will need some sort of Z-bias
functionality, which is what glPolygonOffset and moving the clip planes
gives you.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Angel Popov [mailto:ju...@bi...]
> Sent: 21 July 2000 15:50
> To: gda...@li...
> Subject: Re: [Algorithms] Bullets on walls
> 
> 
> No, neither glPolygonOffset or moving the near clipplane will 
> have the same
> functionality as the non-existent glDepthFunc( GL_ALMOST_EQUAL )
> because these two approaches will not fix the problem with 
> the wallmark
> not getting clipped at wall corners.
> 
> 
> > For D3D (and probably OpenGL), a good alternative is to 
> move the near &
> far
> > clip planes a bit further away for those tris. You only 
> need to move the
> > near clip plane if using Z-buffering. If using W-buffering, 
> you'll need to
> > move both.
> >
> > Tom Forsyth - Muckyfoot bloke.
> > Whizzing and pasting and pooting through the day.
> >
> > > -----Original Message-----
> > > From: Neal Tringham [mailto:ne...@ps...]
> > > Sent: 21 July 2000 10:56
> > > To: gda...@li...
> > > Subject: Re: [Algorithms] Bullets on walls
> > >
> > >
> > >
> > > Giovanni Bajo <ba...@pr...> writes:
> > > > In DirectX, there is a ZBIAS stuff that let you set a 
> priority order
> > > > (integer) when Z matches. It is a renderstate. But looking
> > > at the caps, it
> > > > is not supported in every boards I have tried. I heard 
> it is an old
> > > thingie
> > > > of first Voodoo boards.
> > >
> > > Yes, the support for zbias seems to be rather inconsistent.
> > >
> > > > I had not found something similiar in OpenGL.
> > >
> > > You may want to look at the 1.1 glPolygonOffset function.
> > >
> > >
> > > Neal Tringham (Sick Puppies)
> > >
> > > ne...@ps...
> > > ne...@em...
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] Bullets on walls

[Brian M. <bma...@ra...>]

	The N64 supports this op. It was used for the bullet holes in Perfect Dark
(and Goldeneye.). It still doesn't give a glitch free result. It does 'clip'
to the edges on polygons when the decal goes over the edge of the polygon
its sat on, but its really just scissoring with Z to do that.
	One thing to remember is that the error in the z slope calculations on the
small decal polygon is higher than that on a larger (in screen space)
polygon. So you are always going to have some accuracy worries. Using one
decal polygon the same size as the surface it's resting on may work very
well. With individual decals someone will always get them all on one wall if
you let them - which is a big hit with individual decals, small with one big
decal.
	Unless you can use precisely the same polygon for generating Z values you
will need to add Z-bias to minimize glitching.

-Brian.
> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Tom
> Forsyth
> Sent: Friday, July 21, 2000 2:35 PM
> To: gda...@li...
> Subject: RE: [Algorithms] Bullets on walls
>
>
> We know. Nothing on the planet supports something like
> ALPMOST_EQUAL as far
> as I know (and even if it did, that still has problems when things walk
> beside the walls).
>
> You will have to either clip the decals to the wall
> geometrically; draw the
> wall poly with clamp texture mode & the right UVs; or composite the decals
> onto a wall-shaped poly, as suggested. If drawing individual decals, which
> seems a popular method, then you will need some sort of Z-bias
> functionality, which is what glPolygonOffset and moving the clip planes
> gives you.
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
>
> > -----Original Message-----
> > From: Angel Popov [mailto:ju...@bi...]
> > Sent: 21 July 2000 15:50
> > To: gda...@li...
> > Subject: Re: [Algorithms] Bullets on walls
> >
> >
> > No, neither glPolygonOffset or moving the near clipplane will
> > have the same
> > functionality as the non-existent glDepthFunc( GL_ALMOST_EQUAL )
> > because these two approaches will not fix the problem with
> > the wallmark
> > not getting clipped at wall corners.
> >
> >
> > > For D3D (and probably OpenGL), a good alternative is to
> > move the near &
> > far
> > > clip planes a bit further away for those tris. You only
> > need to move the
> > > near clip plane if using Z-buffering. If using W-buffering,
> > you'll need to
> > > move both.
> > >
> > > Tom Forsyth - Muckyfoot bloke.
> > > Whizzing and pasting and pooting through the day.
> > >
> > > > -----Original Message-----
> > > > From: Neal Tringham [mailto:ne...@ps...]
> > > > Sent: 21 July 2000 10:56
> > > > To: gda...@li...
> > > > Subject: Re: [Algorithms] Bullets on walls
> > > >
> > > >
> > > >
> > > > Giovanni Bajo <ba...@pr...> writes:
> > > > > In DirectX, there is a ZBIAS stuff that let you set a
> > priority order
> > > > > (integer) when Z matches. It is a renderstate. But looking
> > > > at the caps, it
> > > > > is not supported in every boards I have tried. I heard
> > it is an old
> > > > thingie
> > > > > of first Voodoo boards.
> > > >
> > > > Yes, the support for zbias seems to be rather inconsistent.
> > > >
> > > > > I had not found something similiar in OpenGL.
> > > >
> > > > You may want to look at the 1.1 glPolygonOffset function.
> > > >
> > > >
> > > > Neal Tringham (Sick Puppies)
> > > >
> > > > ne...@ps...
> > > > ne...@em...
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] Bullets on walls

[Stephen J B. <sj...@li...>]

On Sun, 23 Jul 2000, Brian Marshall wrote:

> 	The N64 supports this op. It was used for the bullet holes in Perfect Dark
> (and Goldeneye.). It still doesn't give a glitch free result. It does 'clip'
> to the edges on polygons when the decal goes over the edge of the polygon
> its sat on, but its really just scissoring with Z to do that.
> 	One thing to remember is that the error in the z slope calculations on the
> small decal polygon is higher than that on a larger (in screen space)
> polygon. So you are always going to have some accuracy worries. Using one
> decal polygon the same size as the surface it's resting on may work very
> well. With individual decals someone will always get them all on one wall if
> you let them - which is a big hit with individual decals, small with one big
> decal.
> 	Unless you can use precisely the same polygon for generating Z values you
> will need to add Z-bias to minimize glitching.
 
Strictly speaking (in OpenGL at least), even making the polygons the
same size won't guarantee no Z-fighting.  The OpenGL spec allows implementations
to generate different Z values even when vertices are shared when certain GL
states are not shared.

The reason for that is that you might (for example) have to do a software
fallback for one set of states and not for the other - since software and
hardware rendering are unlikely to generate the exact same Z values, you
can't guarantee no Z-fighting.

However, you'll probably get away with it on most machines.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] Bullets on walls

[Gary M. <ga...@va...>]

Using overlay textures would require you to use a ton of unique textures. .
. can become very unreasonable quickly.

Gary

-----Original Message-----
From: Mark Wayland [mailto:mwa...@to...]
Sent: Thursday, July 20, 2000 9:55 PM
To: gda...@li...
Subject: Re: [Algorithms] Bullets on walls


An extension to Jaimi's method may be to render the bullet holes to an
overlay texture (of which you would have a maximum number) which is only
rendered *once* on-top of the wall. With complex texture mapping this is
obviously not possible, but perhaps for simple quads it would be acceptable
?

Perhaps some form of scalable solution - like use Jaimi's method for a small
number and when a threshold is reached, combine them into the single texture
as I've mentioned and repeat ... ??

Just my 2c worth ...

Mark

> In d3d, this is the way I do it:
>
> Create decals with a one pixel transparent border.
> Then, set the texture address mode to "Clamp".
> Calculate new UV coordinates for your decal based on the wall, instead
> of the Decal - then redraw the entire wall with your decal texture and
> new UV coordinates.
> This way you do not have to clip at all. I would assume you could
> do the same in OpenGL.
>
> Jaimi



_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Bullets on walls

[<ma...@ci...>]

We do it this way:

If the decal does not cross a polygon boundary with a high enough crease 
angle, draw it as a quad.  Use ZBIAS if supported and/or move it along the 
normal to lift it off the surface.

Otherwise draw it as decal, as per Jaimi's method.  Remember to enable 
ALPHATEST so there's no overdraw or fill-rate hit even if the base triangle 
is large and has several decals.

Mipmapping is still a problem - clamp mip levels to a minimum size (16x16 or 
32x32) and make sure your algorithm maintains the alpha==0 border all the 
way, otherwise decals at oblique angles will bleed over the whole base 
triangle.  For small decals like bulletholes just don't mipmap them (and use 
a suitably low-res texture).


-=Mark=-

Mark Atkinson, Technical Director, Computer Artworks Ltd.
http://www.artworks.co.uk

> Using overlay textures would require you to use a ton of unique textures. 
> .
> . can become very unreasonable quickly.
> 
> Gary
> 
> -----Original Message-----
> From: Mark Wayland [mailto:mwa...@to...]
> Sent: Thursday, July 20, 2000 9:55 PM
> To: gda...@li...
> Subject: Re: [Algorithms] Bullets on walls
> 
> 
> An extension to Jaimi's method may be to render the bullet holes to an
> overlay texture (of which you would have a maximum number) which is only
> rendered *once* on-top of the wall. With complex texture mapping this is
> obviously not possible, but perhaps for simple quads it would be 
> acceptable
> ?
> 
> Perhaps some form of scalable solution - like use Jaimi's method for a 
> small
> number and when a threshold is reached, combine them into the single 
> texture
> as I've mentioned and repeat ... ??
> 
> Just my 2c worth ...
> 
> Mark
> 
> > In d3d, this is the way I do it:
> >
> > Create decals with a one pixel transparent border.
> > Then, set the texture address mode to "Clamp".
> > Calculate new UV coordinates for your decal based on the wall, instead
> > of the Decal - then redraw the entire wall with your decal texture and
> > new UV coordinates.
> > This way you do not have to clip at all. I would assume you could
> > do the same in OpenGL.
> >
> > Jaimi
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> 

RE: [Algorithms] Bullets on walls

[Stephen J B. <sj...@li...>]

On Fri, 21 Jul 2000, Mark Atkinson wrote:

> We do it this way:
> 
> If the decal does not cross a polygon boundary with a high enough crease 
> angle, draw it as a quad.  Use ZBIAS if supported and/or move it along the 
> normal to lift it off the surface.
> 
> Otherwise draw it as decal, as per Jaimi's method.  Remember to enable 
> ALPHATEST so there's no overdraw or fill-rate hit even if the base triangle 
> is large and has several decals.
 
Eh?

Alpha Test (presuming it's the same mechanism as glAlphaFunc in OpenGL)
won't eliminate (all of) the overdraw/fillrate issues.  The renderer
still has to scan-convert all those pixels, do the texture calculation
on each one and compare the alpha value against the threshold.

* On some hardware, that'll be no cheaper than drawing the entire polygon.

* On other hardware, you'll only pay *some* per pixel cost (maybe half).

* It'll never be zero though - that's impossible - it has to consume
  some texture bandwidth per-pixel of the entire polygon.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] Bullets on walls

[Mark W. <mwa...@to...>]

Yep, hence the cap on the maximum number. You could consider these overlay
textures "caches" of the bullet holes within an area, so instead of
rendering dozens or more bullet holes each frame, you render the one overlay
texture. Can't be any more expensive than dark mapping, can it ? :)

Mark

> Using overlay textures would require you to use a ton of unique textures.
.
> . can become very unreasonable quickly.
>
> Gary
>
> -----Original Message-----
> From: Mark Wayland [mailto:mwa...@to...]
> Sent: Thursday, July 20, 2000 9:55 PM
> To: gda...@li...
> Subject: Re: [Algorithms] Bullets on walls
>
>
> An extension to Jaimi's method may be to render the bullet holes to an
> overlay texture (of which you would have a maximum number) which is only
> rendered *once* on-top of the wall. With complex texture mapping this is
> obviously not possible, but perhaps for simple quads it would be
acceptable
> ?
>
> Perhaps some form of scalable solution - like use Jaimi's method for a
small
> number and when a threshold is reached, combine them into the single
texture
> as I've mentioned and repeat ... ??
>
> Just my 2c worth ...
>
> Mark
>
> > In d3d, this is the way I do it:
> >
> > Create decals with a one pixel transparent border.
> > Then, set the texture address mode to "Clamp".
> > Calculate new UV coordinates for your decal based on the wall, instead
> > of the Decal - then redraw the entire wall with your decal texture and
> > new UV coordinates.
> > This way you do not have to clip at all. I would assume you could
> > do the same in OpenGL.
> >
> > Jaimi
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Bullets on walls

[Tom F. <to...@mu...>]

If you are using a small texture with clamp-to-edge mode, the scanline
conversion still has to be done (consuming pipeline clocks), but it will
just read the same texels over and over again (the edge ones) for most of
the drawing. So it won't compete for memory bandwidth.

Older chips won't see much benefit - they were indeed core-bound most of the
time, not memory-bound (or at least the core wasn't far behind the memory),
but newer chips will love you silly, especially in 32bpp modes.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Stephen J Baker [mailto:sj...@li...]
> Sent: 21 July 2000 18:38
> To: gda...@li...
> Cc: ma...@ci...
> Subject: RE: [Algorithms] Bullets on walls
> 
> 
> On Fri, 21 Jul 2000, Mark Atkinson wrote:
> 
> > We do it this way:
> > 
> > If the decal does not cross a polygon boundary with a high 
> enough crease 
> > angle, draw it as a quad.  Use ZBIAS if supported and/or 
> move it along the 
> > normal to lift it off the surface.
> > 
> > Otherwise draw it as decal, as per Jaimi's method.  
> Remember to enable 
> > ALPHATEST so there's no overdraw or fill-rate hit even if 
> the base triangle 
> > is large and has several decals.
>  
> Eh?
> 
> Alpha Test (presuming it's the same mechanism as glAlphaFunc 
> in OpenGL)
> won't eliminate (all of) the overdraw/fillrate issues.  The renderer
> still has to scan-convert all those pixels, do the texture calculation
> on each one and compare the alpha value against the threshold.
> 
> * On some hardware, that'll be no cheaper than drawing the 
> entire polygon.
> 
> * On other hardware, you'll only pay *some* per pixel cost 
> (maybe half).
> 
> * It'll never be zero though - that's impossible - it has to consume
>   some texture bandwidth per-pixel of the entire polygon.
> 
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1