Asynchronous loading for Actor.loadModel

I found some information from David on the forums. Is this what you're after?

"Actually, the Actor has always supported on-demand loading of animations; and that is its default behavior. Calling loadAnims() doesn't actually load anything from disk; it just specifies that filenames that will be loaded when each animation is played for the first time.

In order to force an animation to actually load, you can either play it or call bindAnim(). This will result in a frame hitch in the traditional Actor code as the animation is actually loaded from disk. In the new 1.6.0 Actor, with the -preload in effect, playing an animation (or calling bindAnim()) starts the animation loading in a thread, so there is no frame hitch. You can call waitPending() to make it stop and wait for all of the pending animations to become available (for instance, during a loading screen).

The normal behavior is to cache each animation the first time it is loaded, and then keep it around until the Actor is destroyed or until unloadAnims() is called. If you really want to recover the memory, you should also call ModelPool.releaseModel(), but only when you are sure that all Actors that share the same animation file have unloaded it. (Since the animation data is essentially a static table, different instances of Actor that load the same animation egg file will actually just share a pointer into the common memory. This common memory will remain resident until all Actors, and the ModelPool, release it. If you release it from the ModelPool prematurely, the next Actor to load it will be forced to re-read it from disk, wastefully duplicating the table already in memory for the other Actor(s).) "

I had already seen that and not really. It refers to the animations, not the
model itself, which is where the issue is. I would simply like the ability
to asynchronously load that as well, making the interface consistent at the
same time. Right now, as far as I know, there is no way to fully load a
character ready for playing in a loading screen without causing glitches in
the frame rate - that explains how to do that for animations, but not for
the model.

On Fri, Jun 26, 2009 at 6:44 PM, pro-rsoft <email address hidden> wrote:

> I found some information from David on the forums. Is this what you're
> after?
>
> "Actually, the Actor has always supported on-demand loading of
> animations; and that is its default behavior. Calling loadAnims()
> doesn't actually load anything from disk; it just specifies that
> filenames that will be loaded when each animation is played for the
> first time.
>
> In order to force an animation to actually load, you can either play it
> or call bindAnim(). This will result in a frame hitch in the traditional
> Actor code as the animation is actually loaded from disk. In the new
> 1.6.0 Actor, with the -preload in effect, playing an animation (or
> calling bindAnim()) starts the animation loading in a thread, so there
> is no frame hitch. You can call waitPending() to make it stop and wait
> for all of the pending animations to become available (for instance,
> during a loading screen).
>
> The normal behavior is to cache each animation the first time it is
> loaded, and then keep it around until the Actor is destroyed or until
> unloadAnims() is called. If you really want to recover the memory, you
> should also call ModelPool.releaseModel(), but only when you are sure
> that all Actors that share the same animation file have unloaded it.
> (Since the animation data is essentially a static table, different
> instances of Actor that load the same animation egg file will actually
> just share a pointer into the common memory. This common memory will
> remain resident until all Actors, and the ModelPool, release it. If you
> release it from the ModelPool prematurely, the next Actor to load it
> will be forced to re-read it from disk, wastefully duplicating the table
> already in memory for the other Actor(s).) "
>
> --
> Asynchronous loading for Actor.loadModel
> https://bugs.launchpad.net/bugs/375628
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Panda3D: New
>
> Bug description:
> Summary says it all really - loader.loadModel() allows you to specify a
> callback function and load asynchronously, whilst the Actor classes
> loadModel method does not. Don't know what would be involved in fixing that
> but would be very useful for streaming in content.
>
> (This isn't a bug report but a feature request I know... but don't know
> where to put feature requests!)
>

The Actor interface does accept an already-loaded NodePath as the model parameter, so you can use loader.loadModel() with a callback to get your model, then pass it to the Actor constructor.

I think this is a better solution than further cluttering up the already-overstuffed Actor interface.

Fair enough - just another case of the documentation omitting useful information then!