Quick Question about FadeLODNode and its overhead

Hi, I am about to build a project that incorporates LODs and want to mostly use FadeLODNodes instead of classic LODS. I want to subclass them into their own class to simplify things for general use instead of using a combination of the two. This is kind of a quick question to answer: Do fade LODS that have a fade time of 0, add any overhead compared to a classic Pop LODNode. I’m looking at the source code:

      if (elapsed >= _fade_time) {
        // Transition complete.
        ldata->_fade_mode = FadeLODNodeData::FM_solid;

      } else {...

I’m not actually very familiar with the entire panda3d codebase and am assuming that this is setting a state telling the LOD system that the LOD has finished its transition. From the looks of it there is already a kind of check for a 0 transition time fade. I’m just not sure if there is some kind of hidden overhead as it looks like some other requirements like the alpha transparency attribute has to be applied to the different LOD levels.

I thought it might be faster to ask someone that knows the source code better than I do, instead of scraping through files looking for answers.

Yes, the check you are pointing at will immediately pass after starting the transition, so it will jump to the solid state before it even has a chance to set up the transparency effect. So no overhead in that regard. There is a tiny amount of overhead for the extra book-keeping, but it’s peanuts compared to the cost of rendering an expensive model.

1 Like

Cool Thanks. On another note not related to LODs, How does Occlusion Queries work in panda3d? Is there a high level API for this because the GSG has a function to check support for it: getSupportsOcclusionQuery()→ bool.

Edit: I moved this to a new post: New Topic

I know very little about it other than that they are meant to be used by the PipeOcclusionCullTraverser, which (from what I understand, which is not much) was an experiment to first render the bounding volume of a model and query whether any fragments passed the depth test to decide whether to render the real model. Naturally, it would suffer from pipeline stalls, and I’d be surprised if that code still worked.