Both. I think maybe any Object3D that you create with Quesa/RB
stays in the render list.
NavNodes don't create any Object3Ds. So there's something fishy
going on here: if the NavNodes are involved, then it shouldn't
matter what version of Quesa you're using. If it's Quesa at fault,
then the NavNodes shouldn't affect it.
Well it seems to be the case here. When I used Jeff's workaround by
switching to Wireframe, everything is fast again in 1.7 with the
NavNodes in my game using that map. So, it does look like Quesa keeps
everything in the render list that was ever created. Remember this
workaround only works after all objects gets created. If I toggle the
wireframe mode before all the objects are created, it is just as slow
as before.
I'd like to, but I don't know when I'll get the chance -- things
are a bit busy for me at the moment.
Maybe Jeff might want to take a stab at it to confirm my results.
I believe NavNodes generate their own Object3Ds even in the game.
Is this correct?
No, or at least, they certainly shouldn't do so.
Maybe it's a bug? I see that the RebuildObject3D method in the
NavNode class is being called when I set a break point there in the
game.
Assuming my theory is true...The wireframe workaround may work for
the moment, but if for some reason you need to create new objects 3Ds
in the game, they'll be stuck in the render list until you toggle the
wireframe mode again.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|