|
For a comic-style maze game, I need to make sure that characters are rendered "above" each other without the meshes intersecting while at the same time using the z-buffer properly to render the characters in front of or behind the maze walls. The effect I want to achieve between characters is the same you would get if you put each character onto their own layer and use one camera per character with different depths. Unfortunately it seems that this doesn't work with the maze because the characters will be rendered either always in front of the maze or always behind the maze. One possible solution might be rendering the characters into a render texture using some sort of billboards, plus a little z-offset per character/ billboard. But I was hoping that there is a simpler approach. So ... how could this be achieved? I've seen a couple of somewhat similar questions but in those cases it's either about making sure the meshes don't intersect (won't work in my case) or intentionally rendering meshes above everything else (not the effect I'm trying to achieve).
... seems like the image isn't shown, so here's a link: http://www.ramtiga.com/Portals/1/img/funstuff/MeshIntersections.png
(comments are locked)
|
|
Render one player before everything but your background. Render the foreground player afterwards, using ZTest Always. You can stack as many players as you want, using ZTest Always on all of them but the furthest one back. (You could use it there too, but it's not strictly necessary.) Here are the simplest shaders that do this; edit whatever shaders you're actually using, with the Queue and ZTest modifications. Shader "Background Dude" { Sorry - I'm afraid my description saying "like with different cameras" was a bit misleading. Your solution always renders Background Dude in the background, and Foreground Dude in the foreground (just like it would be with the different cameras). But what I really need is Background Dude to "pop forward" when he passes by Foreground Dude. So sometimes DudeA would be the background dude, and sometimes DudeB would be the background dude.
Mar 13 '12 at 11:11 PM
jashan
A shader can't handle that for you. You need to either script Material.renderQueue or switch shaders.
Mar 13 '12 at 11:46 PM
Jessy
Actually, with ZWrite Off this seems to work quite nicely. I still got some issues with my models when using that approach but those can be fixed. Basically, what I get now is that instead of intersecting / overlapping, the whole model "pops to front" when DudeA comes closer to the camera than DudeB.
Mar 14 '12 at 12:45 AM
jashan
The "popping" should be predictable, based on your scripting. I recommend queues 2500-2999 for this effect, if you're using ZWrite Off instead of ZTest Always.
Mar 14 '12 at 01:18 AM
Jessy
(comments are locked)
|
|
I think that if you have multiple cameras in the same position with different clipping planes and depths overlaid on the same screen, you'll be able to render one object as being "in front" of another without it "phasing" into another object.. assuming that it's a consistent distance from the main camera. With "consistent distance" you mean the rrelative distances remain the same? If so, that's where this approach fails: As it's a maze game, the characters (spheres in the linked image) move back and forth, so having a static set up wouldn't work.
Mar 13 '12 at 10:19 PM
jashan
(comments are locked)
|
|
If I correctly understood the problem, I suppose you could get this effect by using some transparent shader (diffuse, specular etc. - use alpha=1) for the characters and setting their rendering order with material.renderQueue: transparent shaders read but don't write to the z-buffer, thus the characters would overlap each other without ignoring the maze walls. I think that should do it ... the only problem I have at the moment is that the models I'm using look pretty messed up when they are being used with transparent shaders (the problem is that there's e.g. hair on top of a head, and using the transparent shaders, the head "pops out"). But that's a problem that can be fixed ;-)
Mar 13 '12 at 10:21 PM
jashan
There's no reason the shaders have to be "transparent" i.e. blending. The key is the ZWrite off. That's a viable solution; I offer another in my answer.
Mar 13 '12 at 10:43 PM
Jessy
I suggested the transparent shaders only as a starting point - the necessary shaders could be edited to only read the ZBuffer. But the "local" depth (relative depth of different model parts) should be solved somehow.
Mar 14 '12 at 12:17 PM
aldonaletto
(comments are locked)
|
I may be able to help, but don't understand. :-( http://en.wikipedia.org/wiki/A_picture_is_worth_a_thousand_words
I've edited the question to contain an image - but I don't see the image, so here's a link: http://www.ramtiga.com/Portals/1/img/funstuff/MeshIntersections.png
Edits don't appear for like an hour now. This site is rather unusable at the moment.