Sign in to follow this  
Structural

Resource management: resources with non-static content?

Recommended Posts

I'm in a bit of a twist here that I can't seem to solve. The situation is as follows: I have a resourcemanager (finally, hurray) that takes care of "resources". It loads and unloads them, it keeps track of references. These resources can be tonnes of things: Scripts, textures, meshes, sounds, particlescripts etc etc. What I'm worried about is resources that can be animated, such as a mesh or a particle engine prototype. Every frame I will want to update the coordinates of the resource to animate it. Then the next frame update it some more... So in the end the coordinates are nothing like they were initially. Ofcourse, you see that I can not animate the resource itself because all objects linking to the resource would then change. That would look a tad silly. So I will need to make a deep copy of the entire resource, and animate that. Is that really the only way? Make a deep copy, an animate it then? It kind of defies the whole purpose of managing those kind of resources, if you have copies of them all over the place, don't you think? So, how do you deal with animated resources? I have the feeling I'm missing out on something. And for question 2: What do you think of as resources? So far I have the following things in my list (most of them TODO's): - Meshes (animated/static models, terrain) - Textures (animated (movies) and static) - Particle scripts (engines, primarilly prototypes of the engine) - Sounds - ??? Please help me fill in the list. note: I know most meshes can be linearly interpolated between frames for animating, but the first question mostly applies to resources with a non-linear behaviour, like for example particles or objects that are effected by world interaction. Thanks in advance for your input.

Share this post


Link to post
Share on other sites
A resource is just hard data. What you do with it is up to you. I consider textures and sounds to be resources. Possibly blocks of text for a long-winded RPG. Config files, scripts, AI modules, etc etc are not resources. Those should be handled by some other method.

As such, you shouldn't have to "animate" a resource. You should just ask for the required graphics or textures and do whatever you want with them afterwards. The resource manager is just responsible for loading, dumping, and handing out the resources, not blitting graphics or playing sounds or any combination thereof.

Share this post


Link to post
Share on other sites
You would want to store the animation parameters in a different class, say a RenderOperation. The RenderOperation will take the start index and end index if your mesh is using keyframe animation.

So when you 'draw' an object, you are essentially adding it to a list of RenderOperations. When your renderer does the actual drawing, it just loops through these RenderOperations, uses the keyframe data and draws it to screen one by one.

Hope that helps.

Share this post


Link to post
Share on other sites
Eh... don't listen to these guys. You seem to be leaning towards a broad definition of "resource", and there's nothing wrong with that. Of course, that said, the complications are many.

What you'd want to do for animation, etc. is to have static inputs be resources and have a separate memory allocation manager for scratch buffers, vertex buffers, texture buffers, etc. If you have pointers to these buffers within the resource, mark them somehow as transient (in the java lingo), meaning they won't be saved and will be recreated on load.

As for scripts and config files not being resources, why the hell not? Any and all static data can be a Resource for fast pre-compiled loading. Then you don't have to keep track of a bunch of singletons allocating/deallocating memory and paging for each subsystem...

Tom

Share this post


Link to post
Share on other sites
I see that there are a few different opinions about this matter.
My definition of a resource is a "piece of data that can be used by multiple objects". This piece of data can be anything in my opinion ranging from textures, to meshes, to settingsfiles and much more.

I think Darkor gave me a basic idea of how to structure this. Use a second object that takes care of the animating/rendering/changing of the mesh for example. Then the resource will only serve as a prototype model for many objects.
As for particle engines, only the base settings should be loaded as a resource (particle size, speed, direction, gravity, etc etc) , and the RenderOperation, as Darkor calls it, will have its own vertex array. In the way ParadigmShift says, a temporary buffer, possibly also memory managed. The resource with the settings will only be used to animate.

Yes, I got a clearer vision now I believe.


I have another question. Having written a BMP and TGA container, do you keep the actual image data (as read from file) in memory, or do you load it in video-memory right away (glGenTextures and so forth, for you openGL users) and free the heap memory?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
When loading a resource I just pass a flag indicating if this particular resource will be animated or not. If it will then resource manager creates a unique copy based on previously precached data - and if not, then it just returns 'common' static resource

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this