Jump to content
  • Advertisement
Sign in to follow this  
jatobu

multitextured gunshot effect in walls

This topic is 3939 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone! it's not exactly the case but... as many of you know on FPS's when you shot to a wall a 2nd texture gets rendered into that location of the wall so that it looks like the wall has been shot and borken by the bullet... In the app I'm currently working on I need to do something very similar, I need to render a 2nd texture on a specific location of a mesh (wich might vary), so I was looking for any doc's on the gunshot effect used on FPS's to see if from there I could apply it to what I'm trying to do... unfortuately I can't find anything on the topic. does anyone know were can I get information about how to do this?? I'll appreciate any help. :)

Share this post


Link to post
Share on other sites
Advertisement
That article is about something called "3d decals", a method I've yet to see actually implemented, and something I suspect is not very efficient. The poster is really asking about regular 2d decals.

Normally, to make things like bullet hole you simply find the surface normal and 3d coord of the impact area using your collision system. Then just create a sprite (a flat textured quad) and place it against the wall rotated to have the same normal as the wall.. then you apply some kind of alpha blending etc to make it appear to be a hole. You can also use parallax mapping to make it appear more 3D.

Using this method you can many holes at once wihtout much framerate lag, and it looks good enough.

Other methods extend this to actually project the sprite against geometry so you dont get the problem when a sprite is on a corner or edge of a wall.. and part of it sticks out.

Share this post


Link to post
Share on other sites
I don't play too many games but this was clearly the method used in Half Life because they have a fixed number of "bullet holes" and after you shoot at the wall for a while the older ones start disappearing.

Another solution would be to actually burn the sprite image into the wall texture, but this would have a big performance delay and require you to not re-use many textures....so it might not be a good idea to use for this specific purpose but probably has some other creative uses for when you want to make permanent modifications. The lag of putting them down could be fixed by using a sprite mechanism at first and then swapping it for the updated texture later.

edit: for example in Little Big World for the PS3, they must have burned the decals into the texture because they put it onto a cloth and then deformed the cloth in realtime

[Edited by - yahastu on October 26, 2007 12:21:25 AM]

Share this post


Link to post
Share on other sites
Quote:

Normally, to make things like bullet hole you simply find the surface normal and 3d coord of the impact area using your collision system. Then just create a sprite (a flat textured quad) and place it against the wall rotated to have the same normal as the wall.. then you apply some kind of alpha blending etc to make it appear to be a hole


That's exactly the way I'm implementing it now... the problem is that it needs to be placed VERY near to the object, and by doing so the poligons of the object over which I'm placeing it (the "wall" in the case of bullet hole) happens to overlapp from time to time over the quad-mesh sprite wich holds the image... so depending on the camara position and orientation some times it is visible, some times its just partially visible, and some times it is not at all...

Ofcourse that if I put more distance between my "wall" and my bullet-hole sprite this stop happening and looks great at the distance... the problem is that it is needed the camera to get VERY near to that point... and it should still be seen as if it was overlapped over the "wall" mesh...

so... that is why I was thinking more of like drawing the "bullet-hole" as a texture on the "wall" mesh in that specific position... but maybe there are other alternatives.

Quote:

Another solution would be to actually burn the sprite image into the wall texture, but this would have a big performance delay and require you to not re-use many textures....


Sounds cool... And how could I burn the sprite image into the wall texture (and in that specific position)?...

for the app I'm working on it really doesn't matter too much if there's a little delay in the drawing (it will just be drawn once for each level)... so I think it will be ok as long as the image is kept drawn in the place it should be until the player changes to another level...


:)

Share this post


Link to post
Share on other sites
Quote:
Another solution would be to actually burn the sprite image into the wall texture


This generally cant work because of massive texture memory requirements..unless you use mega textures.

The sprite method does work..if you are having problems it just needs to be tweaked.

Share this post


Link to post
Share on other sites
Quote:
Original post by jatobu
That's exactly the way I'm implementing it now... the problem is that it needs to be placed VERY near to the object, and by doing so the poligons of the object over which I'm placeing it (the "wall" in the case of bullet hole) happens to overlapp from time to time over the quad-mesh sprite wich holds the image... so depending on the camara position and orientation some times it is visible, some times its just partially visible, and some times it is not at all...


I would render the sprites at the EXACT distance of the wall, but use a special pixel shader that subtracted some small offset from their depth values when writing into the depth buffer...this way, the sprite appears exactly on the surface of the wall, but the wall never shows through.

Share this post


Link to post
Share on other sites
yahatsu: DirectX and OpenGL both implement a feature sometimes called "coplanar offset", an integer usually in the 0-15 range, which performs micro-override on Z-testing, such that a fragment at the same calculated depth as an existing fragment in the Z-buffer will appear in front of the existing, so long as its coplanar offset is greater.

At least, DirectX did back in the DirectX 7 days, the last time I worked with DirectX. I can't imagine they'd not implement a similar feature in more recent versions.

Share this post


Link to post
Share on other sites
Uhmmmm....

so it looks like there's no easy way to use some kind of multitexturing for this...

maybe I could change dynamically the distance between my "bullet hole" and the "wall" depending of the distance the camera is from that point, so that if the camera is far away then I could put more distance between the "bullet-hole" and the "wall" and this way prevent that occlusion artifact that happens when it is too close to it... and as the camera goes more close to the "bullet-hole-point" the narrow the distance between them... which would make it look like if it was just painted over the object...


I don't know exactly why at a distance the object on which I want to draw the "bullet-hole" overlaps the bullet-hole's sprite and when the camera is near to it it renders without a problem... I'm not shure if this could be some kind of glitch caused by the depth-buffer, or maybe the transformated vertices loose accurancy...

after reading what Wyrframe said I'm thinking that maybe the problem I'm having with de "wall" occluding the "bullet-hole" sprite in the distance is due to the "coplanar offset" thing... maybe the camera is so far away, and the difference between the "wall" and the "bullet-hole" is so insignificant that the depth buffer gives both the same depth (albeit there's 0.05 of difference between them)... causing during the z-test the "wall" object to be rendered instead of the "bullet-hole" sprite...


doesn't shadowmaps project a texture over a given position of a specific object??... could I use something similar to proyect a Bullet-hole texture insted of a shadow???


Thanks guys!!... very helpfull what you have been replaying so far. ;)

Share this post


Link to post
Share on other sites
Wyframe, thanks for informing me of that nifty detail.

Quote:
after reading what Wyrframe said I'm thinking that maybe the problem I'm having with de "wall" occluding the "bullet-hole" sprite in the distance is due to the "coplanar offset" thing... maybe the camera is so far away, and the difference between the "wall" and the "bullet-hole" is so insignificant that the depth buffer gives both the same depth (albeit there's 0.05 of difference between them)... causing during the z-test the "wall" object to be rendered instead of the "bullet-hole" sprite...


Yes...that is clearly the problem, which is why I suggested using a pixel shader to correct the problem by adding a depth bias...I didn't realize that a function to do depth bias already exists:

Quote:
IDirect3DDevice9::SetRenderState method just before rendering them, setting the State parameter to D3DRS_DEPTHBIAS, and the Value parameter to a value between 0-16 inclusive. A higher z-bias value increases the likelihood that the polygons you render will be visible when displayed with other coplanar polygons.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!