• Advertisement
Sign in to follow this  

multitextured gunshot effect in walls

This topic is 3765 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
Quote:
Original post by yahastu
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.


Great!... I'm going to take a try on it!... I'll let you know if I succeeded with it or not.

(ofcourse, any other ideas on how to solve this problem would be appreciated too)


Thanks!

Share this post


Link to post
Share on other sites
I think stencil buffers will work and they r fine to emulate theese effect like burned wall after a rocket hits it.

Share this post


Link to post
Share on other sites
Another common technique for fixing the coplanar decal problem is biasing the near/far depth range in the perspective matrix by a small amount when you render the decals, so that it pulls all depth values slightly closer to the camera. I've tried all the fancy DX slope biasing stuff and it never seemed as though it worked as well as straight depth range biasing.

Share this post


Link to post
Share on other sites
I have worked with decals using a face in front of a wall in 2 programs and it has always looked ok to me, CS even has a system to make the decal shape to 3d surfaces, like a real bloodstain or shadow would.

http://crystalspace3d.org

Share this post


Link to post
Share on other sites
Well,

Here I am again... I changed the DepthBias and SlopeScaleDepthBias to see if I could fix the overlapping problem, I think it helped, it doesn't look so flicky as before, although the overlapping is still happening... any other ideas why this could be happening??...

It defenitly looks to be something at the pixel level, since when I render the scene in wireframe mode the vertex do not change (actually, the overlapping can happen at different regions of a single triangle)...

I think I'll try to change the depth values in the DepthBuffer as yahastu suggested... but it would just be a twick to make it look right, not exactly to fix the problem from the roots.

There's a distance of about 0.1 between the "wall" and the "bullet-hole-sprite", is it too little??... as I said, when the camera is near that point there isn't any overlapping, but as you get far from it it becomes to make more and more visible...

Thanks!

Share this post


Link to post
Share on other sites
The resolution of the depth buffer gets worse as you get further away from the camera, so you cannot rely on "physical separation" between the wall and the decal. The most common solution is the depth biasing that has already been mentioned.

One thing that hasn't been said is that you have to set the depth culling method so that when you're drawing the decal it'll draw a pixel if the depth buffer value is "greater or equal" to the decal's depth, as opposed to "greater". In OpenGL this is done with glDepthFunc; I don't know about D3D.

Share this post


Link to post
Share on other sites
Hi fingers_,

Well, I think I'll have to stick to that method then... Thanks!


Does anyone know how to change the Depth Buffer using Direct3D?... I think this would best fit to be done under the pixel shader, doesn't it? (accualy I can't think of a way to doit otherwise).


Thanks!

Share this post


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

  • Advertisement