Skybox bleeds into models sphere sometimes

Scripting Issues
1

I have the smiley sphere surrounding my hamster model. Occasionally, the skysphere show up in it!. Not all the time. Im actually not sure where to start with this one, so ill post my skysphere code.

skyphere_issue
skyphere_issue1920Ă—1080 65.9 KB

def _set_up_skybox(self):
        self.skybox = self.loader.loadModel("models/inverted_sphere.egg")
        self.cubemap = self.loader.loadCubeMap("skyboxes/cloud/#.jpg")
        self.skybox.setTexGen(TextureStage.getDefault(), TexGenAttrib.MWorldPosition)
        self.skybox.setTexProjector(TextureStage.getDefault(), self.render, self.skybox)
        self.skybox.setTexture(self.cubemap)
        self.skybox.setLightOff()
        self.skybox.setDepthWrite(False)
        self.skybox.setAlphaScale(0)
        self.skybox.setBin("background", 1)
        self.skybox.setScale(1500)
        self.skybox.reparentTo(self.render)
2

Weridly, and i think related for sure. the smily texture does not show up in some orientations! despite the sphere showing up. ha.

3

I think the problem is that you have disabled depth testing for skybox.

4

Rendering is me weakest area. Do you mind explaining? If its on bin 1 and garaunteed to be rendered first, would there be a need to depth test? Ill try this when i get back from walking my dog btw

5

Just in this case, there will be a Z-depth failure.

6

So, commenting out the depthWrite line did not change the situation.
I then tried setting the depth write:

self.skybox.setDepthWrite(True)

Issue persists! Thanks for the help and sorry if I am misunderstanding.

7

I think you can also comment out the explicit order for the test.
self.skybox.setBin("background", 1)

This is explained here by the Panda3D developer himself

8

Okay, i did, no change though. Ill read that when I can.

9

I think that placing your sky-sphere into the “background” bin and disabling depth-writing (as you’re doing in the code-snippet that you posted) is wise–that should reduce issues related to depth and render-order.

So, could we perhaps see the code related to the sphere? Perhaps there’s something being done with it–either in its initial setup or in the logic implemented for it–that will provide a clue…

10

I don’t think it’s a good idea for volumetric geometry to disable writing to the depth buffer.

11

It is I think pretty normal for a skybox–it prevents the skybox from rendering over distant geometry, for one.

As long as nothing else is a child of the skybox, it should be fine.

12

drwr:

From what I understand “background” and “fixed” don’t use the depth buffer so you can safely disable depth write and depth test?

This sentence seems a little confused. The depth buffer has nothing to do with bins, not really. But many people disable the depth buffer for things in the “background” or “fixed” bins, because they want things in these bins to appear behind or in front of the rest of the scene, and they don’t want the depth buffer interfering with that. Note that this trick only works if the items you’re drawing don’t require the use of the depth buffer to draw themselves correctly (i.e. they’re flats or otherwise not self-occluding).

If you are too lazy to go through and read the link I have given, then I place the text here.

13

And nothing said there contradicts what I said.

(A sky-box–or in this case, sky-sphere–generally doesn’t require depth-buffering to render correctly, and so should be fine.)

But note that I’m talking about the sky-box, not the little sphere; and CeyaSpaceCowboy indicated that the former was so handled, not the latter.

If the little sphere is also being rendered without depth-writing, then indeed, that could be a problem–but we don’t yet have indication of that, as far as I see.

14

Heh guys, thanks for all of the feedback. Indeed, those priperties were only applied to the skybox and nothing is parented to that.

15

That’s good to know! :slight_smile:

Okay, could we see the code related to the ball, please? Specifically, any setup applied to it (e.g. loading the model, putting it in a bin, attaching it to “render”, etc.), and any later code that affects how it’s rendered.

16

Its sort of a mess right now, because i am trying to fogure out the blend2bam not respecting directional lighting issue. Ill come back to this!

17

Fair enough! In your own time! :slight_smile:

18

Okay, so it may be worth noting its not JUST the skybox.

xray
xray1920Ă—1080 58.9 KB

19

heres little sphere code:

sphere_shape = BulletSphereShape(1)

        self.sphere = base.bullet_world_node_path.attachNewNode(BulletRigidBodyNode('ball'))
        self.sphere.node().setMass(1)
        self.sphere.node().setFriction(1)
        self.sphere.node().addShape(sphere_shape)
        self.sphere.setPos(0, 0, 2)
        self.sphere.setCollideMask(BitMask32.allOn())
        self.sphere.node().setRestitution(.1)
        base.bullet_world.attachRigidBody(self.sphere.node())

        hamster = loader.loadModel('models/hammy.egg')
        
        hamster.reparentTo(self.sphere)
        hamster.setScale(0.1)
        hamster.setH(180)
        visual_sphere = loader.loadModel('models/sphere.egg')
        visual_sphere.setShaderOff()
        visual_sphere.setTransparency(1)
        visual_sphere.reparentTo(self.sphere)
        visual_sphere.setColorScale(1,1,1,.6)
        visual_sphere.setLightOff()
        visual_sphere.setDepthWrite(True)
        mat = hamster.findMaterial("body")
        mat.setBaseColor((0,1,1,1))
        base.taskMgr.add(self.update)
        base.taskMgr.add(self._check_ground, sort=-1)
20

Ah, okay–it’s semitransparent. Where transparency is used (outside of a few special cases), render-order will tend to become important: if the transparent object is rendered before something that should appear behind it, its presence in the depth-buffer may prevent that “something” from being rendered, causing whatever’s behind that to be visible.

For this reason, when Panda loads an object with transparency, the object is placed into a specific culling-bin named “transparent”. That bin renders after the default “opaque” bin, and in addition sorts its objects from furthest to nearest.

The result–ideally–is that opaque objects (having been already rendered) correctly appear behind transparent objects, and transparent objects correctly appear behind each other.

(In practice it’s not always that easy, especially with 3D transparent objects, but that’s the basic idea.)

However, your object is, I gather, not transparent when it’s loaded. As a result, it’s presumably placed into the aforementioned default bin–hence rendering issues.

What I suggest, then, is to simply place it into the “transparent” bin yourself.

(Noting that the second parameter to “setBin” is meaningless in the case of the “transparent” bin, despite the fact that it is nevertheless required; just put in whatever value you feel like.)

2 Likes