Scene failed to render multiple time per frame bug

I've split up the topic from here: viewtopic.php?p=55425#p55425

Btw, I found a bug in the PCZSceneManager::_findVisibleObjects(). It's getting the frame count from Root::getSingleton().getNextFrameNumber(). This is bad because when we need to render the scene multiple times, I.E. rendering scene within the compositor passes, nothing will get rendered in that compositor pass. I think we should revert to the commented line which just increment the counter.

Hmm... But there was a very good reason (which I can't remember right now) why I commented that line and went with getNextFrameNumber...

Oh.. hmmm.. okay, how about moving the frame counter thing into the renderScene method? Or is that even worst? As it is, I can't get my refraction compositor to work properly due to this. Switching to the previous method helped there. Though like you said, that might have caused some other problem I'm not aware of. I'll try and dig through to see if I can spot it.

I vaguely recall that it might have been something to do with lighting...

Ah... I think I see it. Lights are updated with a frame count check. Hmmm... It's using it to check against the homezone's frame count. That's rather confusing. What's that for?

I am going by memory (away from my work computer right now) but I think it's because the recursive nature of the PCZSM. Without the check, the lights get updated multiple times in the same frame which caused problems I think...

From the looks of it, we either have to use another method for the lighting update, or we need to make sure that lights are only updated once every frame. I think the best and most fool proof way is to change the way lighting is updated. However, I'm not very certain since I'm not familiar with the lighting code. It seemed to me that it's only used to set the mAffectsVisibleZone boolean value that is used in PCZSceneManager::findLightsAffectingFrustum(). Other than that, the light zone list still gets added?

Thx for the post, now I know why my compositor wasn't working.

Yeah.. it really sucks. But I think I found a way to work around this. And it's actually a much more efficient method.

I noticed there's an mVisible list of nodes that keeps track of the visible nodes in the scene manager. It's not really used anywhere right now. But seemed to be prepared for the non-working method PCZSceneManager::_alertVisibleObjects() which so happen was supposed to be designed for post processing it seemed.

Here's my suggestion. Since mVisible keeps the list of visible nodes since the last camera check, as long as the next camera check is the same camera within the same time frame, we can just reuse it and manually push them into the render queue. This will also save useless portal and frustum culling processing. Obviously, we dont need the _alertVisibleObjects() method. I suggest removing it.

This however is under the assumption that the camera wasn't modified within the same time frame which I think can be a reasonable assumption to make. The only time this would be a problem is if one tries to use PCZSM to do stuffs like imposters/lightmapping. For stuffs like these, maybe one can just force a frame increment in the Ogre::Root. Not too hard I think. Or, they should be done with other SM instead.

@Chaster: tell me what you think. I'll be willing to submit a patch as this is very important for my project.

P.S. I'm thinking of changing the mVisible variable to std::vector instead of std::list which is not efficient as each insertion and removal is a new/delete.

Hmm... that could work, but coincidentally, I am changing the camera settings within a single frame... It doesn't do a whole lot to help out with figuring out which lights affect which zones & nodes, but for the multiple pass problem, it could be okay... If you decide to try it, make sure it's optional.

Chaster
p.s. sorry I have been so quiet lately. I am slammed with work.. and will be for the forseeable future. It might be necessary for me to share duties on the PCZSM with someone else...

As a matter of fact, I managed to do it. But it's not optional like you suggested. One thing though. How did you managed to change camera settings within a single frame and still get them to render? As far as I can tell, rendering a second time with the same camera will never work. The only way for it to work is if a second camera was used, then back to the first camera since then the cached last camera would not match.

If that's the case, my fix would not disturb this at all.

Here's the patch:
https://sourceforge.net/tracker/?func=d ... tid=302997

P.S. I'll be willing to share duties on PCZSM. There's still quite some code cleaning I would love to do on it. Also not to mention the Zone <-> Zone filter feature which I planned to add. Aside from that, there's actually a bug with current scene traversal for directional light casting but that leaves for another thread. So yeah, there's much to do with PCZSM. Aside from this, considering that Sinbad is working on a dynamic paging system, it would be a good idea to see if PCZSM can benefit from it.

I've got permission to commit PCZ source directly. This patch is now in trunk.

P.S. Thanks Chaster and Sinbad.

Thank YOU lf3thn4d!

You're welcome.