So I just decided I’d pick up the UE4 to make some prototypes, mostly to show the games I want to make to potential recruiters and so on. So I’ve decided to work on a small FPS prototype first. I’ve loaded up the FPS example and played around a bit with it. However when trying one specific thing I was surprised. If you put the gun and camera a little bit forward, the gun clips in the walls.
Now what surprises me is that a common technique in FPSs is to pretty much clear the depth buffer before rendering the guns so as to avoid any clipping effect, even if the objects actually overlap in the 3D world. Depending on the engine it’s achieved differently. Source uses layers, Unity uses clear flags and culling masks…
However when searching for it for UE4, nothing pops up except standard first person camera like in the official example or “true” FPS camera (which annoys me as hell… why would someone want a “true” FPS camera like those showcased except for horror and milsim games, but that’s another matter eheh). So my question is, how can I achieve this effect ? UE2 and UE3 had it, so I’d be really disappointed if UE4 didn’t.
So That’s what I came up with based on a reddit post explaining how the Custom Depth works, using custom stencils. However, while I figured how to use a custom clor to show the actual mesh, what I’m seeking is actually seeing the mesh through the other meshes. So would I get that output to give to my lerp’s B parameter ? The PostProcessInput returns the actual image, so it’s already z-buffered =/
Bumping the thread ! Been scratching my head those last days about it and I still can’t find out a way to display the actual object (only to display some color where it’s clipping). The problem is that the rendered already did its job and I’m not sure there’s a way, as of now, to actually get the pixel color of the mesh I want to render OVER the rest of the world. I even thought there coudl be a way by putting the entire world in another stencil, but the very problem still stands.
My problem with Epic’s explanation is that I don’t see how a deferred renderer affects this. Deferred rendering still works with a depth buffer, and since every graphic API allows you to clear that depth buffer WITHOUT clearing the stencil buffer, I don’t see why deferred rendering would prevent that. Now I can see how it would be a hard thing to implement however, but in any engine, not just deferred rendering engine. I’d mess with C++, but from what I’ve read, the depth buffer is inaccessible anyway, so that would be a long shot for this feature (it’s major to me, but if it requires so much work, I’d rather go with the very small weapons sticking right in front of the camera solution).
So if anyone has an idea, please do tell, in the meantime I guess I’ll just stick with that solution I mentioned.
There is a ticket on UE4 issue tracker to support such way of sorting, but it is backlogged and don’t have any votes so I doubt we will see any updates anytime soon, but still worth voting to increase a chance of happening.
I’ve seen a lot of discussions on that matter and usually it just won’t worth to spend much time on that issue because it’s easily avoidable with workarounds like having bigger capsule that will capture your weapon and it won’t bump into anything or having fluid animation blueprint which will move arms back if there any blocking issues. IMHO it’s visually better than weapon models overwriting everything else and relatively easier to implement than changing whole rendering pipeline for one small visual feature for a couple of meshes. Here some answerhub threads(1,2) with details on workarounds. Someone even suggested to make tiny arms with weapon and attach it super close to camera, but I doubt that T.Rexing your character is the way to go
Thanks, I’m gonna vote for it in the hope for this !
Well I beg to disagree Had this been a thing in the new Doom game, it would probably have ruined it. Making arms move back is only a good thing for games that want to make themselves look “so real”. It’s not like better graphics, it’s an awful gimmick that sadly often remove the player’s ability to fire (since most of the time, it’s not simply the arms moving back, but the gun being pulled back with an anim). As for the capsule encapulating the weapon, it really looks bad from a first person persepctive IMHO since it blocks you way too far away from the wall (it looks like something prevents you from closing in to the wall). Also, only pulling back the arms is not looking good as far as any game I’ve seen it implemented in, because it messes up with how the weapon looks in first person in an aesthetically bad way in general.
The other upside to allowing for layers is (in the case it’s implemented too) that it also allows for a weapon model FOV differing from the main FOV. Weapons generally look very good with a 60-ish FOV, when FPS generally requires a world FOV of 90 to 110 FOV. The reason this solution was introduced by FPS is far from being a gimmick, while to me, unless you’re making a pseudo realistic or sim game, moving back arms is really gimmicky That’s why I’ll probably go with the T.Rexing solution xD (love that naming, you must absolutely copyright it ! I may look into the translucent workaround but I’m scared it may be less efficient performance wise, wouldn’t it? (I guess the game doesn’t treat translucent materials teh same way no?)
