Is there a way to render one object in front of an other altough they are on the same Z-axis?
Thanks!
I suppose you mean when the objects intermix right?
You could call a method to disable the z check on the object that is supposed to render in front, but this would also render it in front of everything else.
How would we make it render in front of another object and function as a normal object for everything else that’s something i would like to know too.
There are several possible tricks. If you are talking about flat objects that are exactly coplanar, you are referring to decalling, whichPanda has special support for.
But if you’re talking about some other case in which things are coincident, there might be different answers depending on the precise nature of the situation. One thing you can try is apply a DepthOffsetAttrib to one object:
obj.setAttrib(DepthOffsetAttrib.make())David
I like the DepthOffsetAttrib but don’t find it as useful as it could be. Most of the coplanar flats I want to disambiguate also have transparency, but DepthOffsetAttrib only affects their depth with respect to culling but not with respect to the back-to-front sorting that happens in the transparent objects bin. It will always render the in-front one completely, but the back one might not get rendered behind it. Is this something that could ever be fixed or is it impossible to take the DepthOffsetAttrib into account when depth sorting to determine render order?
That sounds like you’re running into the problem addressed on this manual page: http://panda3d.org/manual/index.php/Transparency_and_Blending
This is a problem whenever you have two nearby transparent objects. There are several possible solutions, none of which is right in every situation.
David
Yes. I am well aware of that document. This occurs most often when doing stuff in 2d (either because the game is primarily 2d or when doing a HUD-style overlay) where things are primarily transparent flats. My general solution is to turn off depth writing and/or testing and explicitly set the render order (the last solution on that document you linked to), because manual layering makes the most sense to me in most of these cases where I know the order I want to render things in. Since these objects are axis-aligned flats rendered in an orthographic view, the problem is only that they are co-planar because I think that they ought to be basically, differing by the smallest delta possible, which as I understand it is the reason for the DepthOffsetAttrib. The only thing I really like about it is that it is hierarchical so I can give something a DepthOffsetAttrib.make(1) relative to its parent without thinking about what layer its parent is on. For completely solid flats this technique would be fine because it makes sure that the correct one is rendered in front, but just doesn’t control the order they are drawn in, so I would still have to use explicit draw orders in a fixed bin which all would need to be updated if I added a layer in the middle somewhere.
I would say that in a 2-d scene graph this hardly ever becomes a problem, simply because it is so easy to turn off depth write and depth test, and render everything in a fixed order (for instance, by putting it the “unsorted” bin, which renders everything in left-to-right, top-to-bottom scene graph order). In fact, this is the default way that Panda sets up the aspect2d graph.
Really, a depth buffer is designed to solve 3-d problems. It usually doesn’t make sense for 2-d flats that are always in a fixed position relative to the camera.
David
Ok, I still think it wouldn’t be a bad thing for back-to-front and front-to-back sorting to take DepthOffsetAttribs into account if possible, even if there are many (preferable) alternatives to needing that behavior.
I suppose I probably knew that “unsorted” was actually breadth first tree traversal order, except that as a computer scientist I have been trained not to rely on the behavior of anything that says sometimes like “undefined” or “unsorted”, so maybe it isn’t the best name.
My question is, when using a fixed bin, is the sorting of things with the same draw order also breadth first or something else dependable, or is it truly undefined?
I agree it is an unfortunate name. It used to mean just what the name implies, a random order; but at some point someone realized that because it doesn’t sort its list, the list gets left in the order in which it was discovered–which is a depth-first scene graph traversal order–and since it turns out this is a useful feature, we left it that way and defined it as its official behavior.
Since the fixed bin uses the stable_sort() function to sort its list, it will also leave things of the same draw order in scene graph order.
Might be a handy feature, but it sounds hard and possibly expensive to implement a complicated sorting algorithm like this. Not sure it’s worth it. 
David