Reloading changed art assets
by Tom Spilman · in Torque Game Engine · 02/10/2005 (11:49 pm) · 1 replies
I redirected this discussion here from two hijacked posts:
http://www.garagegames.com/mg/forums/result.thread.php?qt=24929
http://www.garagegames.com/mg/forums/result.thread.php?qt=25689
The overview...
Exporting or changing some art files then launching Torque and loading your mission to examine the changes is *way* too long of a process to be efficient. Ideally we would like to have a copy of Torque running in the background, do a change to an art resource (DTS shape, DIF, texture, shader in the case of TSE, etc), then switch back to Torque and with a single key press have it reload within an already running mission. This is the plan anyway.
So far i've added a new ResourceInstance::reloadInstance() virtual function which can be overridden by resource classes like GBitmap or InteriorResource. The current problem? The resource may have been reloaded, but in most cases an owning object. For example GFXTextureObject in the case of GBitmap in TSE need to know to update the copy in video memory. Another example is InteriorInstance needs to know to unregister the old zones and register the new zones in the scene manager (also reloading of material maps and registration of lightmaps in the lightmanager).
This has me at a stopping point since i don't know enough about the system yet to make a good judgment call on how to proceed with it. I do see some options:
- Add a registration system of resources to their owners. This way a resource can inform it's owner of a change. Seems like too much complexity to me.
- Have a resource owner check for a resource changes per-frame? Wasteful of cycles... Even if it's only enabled in "special" dev builds.
- Ditch trying to add this at the resource system level. Instead traverse the scene graph requesting scene graph objects to reload themselves with the cooperation of the resource system.
Anyone else have any thoughts on this subject?
http://www.garagegames.com/mg/forums/result.thread.php?qt=24929
http://www.garagegames.com/mg/forums/result.thread.php?qt=25689
The overview...
Exporting or changing some art files then launching Torque and loading your mission to examine the changes is *way* too long of a process to be efficient. Ideally we would like to have a copy of Torque running in the background, do a change to an art resource (DTS shape, DIF, texture, shader in the case of TSE, etc), then switch back to Torque and with a single key press have it reload within an already running mission. This is the plan anyway.
So far i've added a new ResourceInstance::reloadInstance() virtual function which can be overridden by resource classes like GBitmap or InteriorResource. The current problem? The resource may have been reloaded, but in most cases an owning object. For example GFXTextureObject in the case of GBitmap in TSE need to know to update the copy in video memory. Another example is InteriorInstance needs to know to unregister the old zones and register the new zones in the scene manager (also reloading of material maps and registration of lightmaps in the lightmanager).
This has me at a stopping point since i don't know enough about the system yet to make a good judgment call on how to proceed with it. I do see some options:
- Add a registration system of resources to their owners. This way a resource can inform it's owner of a change. Seems like too much complexity to me.
- Have a resource owner check for a resource changes per-frame? Wasteful of cycles... Even if it's only enabled in "special" dev builds.
- Ditch trying to add this at the resource system level. Instead traverse the scene graph requesting scene graph objects to reload themselves with the cooperation of the resource system.
Anyone else have any thoughts on this subject?
About the author
Tom is a programmer and co-owner of Sickhead Games, LLC.
Associate Kyle Carter
I don't think there's a free lunch here. The worst possible approach in terms of complexity would be implementing diff on arbitrary game objects (like interiors). Better to either kill 'em off and recreate them (though problematic as that clobbers all kinds of game state) or even better, to just create the new asset for future instances. That way all you have to do is create a new X or restart the mission to see changes. Maybe for textures it's worth doing a special case; not sure it's worth it for other objects (having a "kill me and recreate an exact copy with the same ID" would be a handy button for artists to hit, but I wouldn't make it happen transparently as would not properly replicate internal state and could potentially destroy all sorts of assumptions in the engine. The same ID might be too much, might have to be a new ID).