Hmm,

It sounds to me like this is the wrong method to address the problem. Not the sync behavior using atomic operations but the whole concept presented here.

I admit I haven't implemented such a scheme but wouldn't it be easier if the loader thread would load a portion of the scene graph, along with its assets and once its loaded, either it or the master thread (it depends on the design) will attach the completed scene subtree to the current scene graph.

Attaching is as simple as assignment of parent/child, possible in several places but still. Connecting and disconnecting entire subtrees under a lock every once in a while is perfectly viable and shouldn't incur any performance problems.

The concept presented above, to my understanding, means the following:

1. I have an entire scene graph
2. In order to conserve and recycle memory I'm going to offload and load textures and other big resources based on several criteria.
3. All nodes that need access to assets then must be able to query a resource manager to verify their assets are loaded and if not, request loading.

This method seems more difficult. Not only to code properly but to debug. Not just because of threading problems but we also introduced loading states and when an asset it loaded it is held by the graph node (albeit with a handle of some sort).

Now consider that you have specific unloading criteria and when you unload you probably unload entire chunks of resources that fit entire subtrees in your scene graph so it boils down to something along the line of what I suggested earlier but with a lot more code overhead.


I've done streaming of other things, not a scene graph, but that seems to be a better solution to me.

I've worked on projects that stream medical images and do so with prioritization that is dynamic. Its a medical viewing application and memory constraints also dictate how you unload images.

That's in its simple form of course :) technically the data structures more likely resemble several trees when you manage them. Only in the final rendering you actual present images in a "list" of some sort.

Some great replies here so far. One suggestion I wanted to add is avoid doing look ups into your data manager by string. This pattern never scales (huge performance hit with a large catalog), uses a lot of memory, and often causes fragmentation. Instead, I would generate a hash of your asset names (32bit or 64bit, possibly working in a bucketed hash to handle collisions) and make your requests against hash values instead.

Cheers!
Graham

Heck, I'd like to work in bioware too :). Can't say enough good words about their games. Kudos.