Late-Binding Data

[wynnj]

I was reading an article in the Feb '05 issue of GD Mag about late binding data. It basically senses automatically when a file is updated and then reloads it into memory. I've done some preliminary tests integrating the code from the article into Ogre and it seems fairly straight forward. I have the meshes and textures automatically updating whenever the file is replaced. I think that with a little work the materials could be reloaded as well, but messing with the interpreters was a little hairy for my tests.

Is this functionality that many people would like to see in Ogre? I think its really handy, personally, and many studios have integrated it into their pipelines already.

[wynnj]

Ok, I just found a similar topic (should start performing more thorough searches) at http://www.ogre3d.org/phpBB2/viewtopic.php?t=37967 so I'm obviously not the first one to ask about this. Should I just post a "how-to" on the topic, or could this actually become a feature? I don't mind doing the work, as I want the feature for myself anyways.

Also, I noticed that when I call reload on a mesh it crashes the system. I was able to get around this by detaching and destroying all the entities referencing the mesh before i called reload, and then recreated them, but this is rather cumbersome. Is there a simpler way to do this?

[sinbad]

I'd like to support this, but I've never found the time to do it before. So any contribution will be welcome, be it an example in the wiki or a patch. The mahor consideration if it's a patch is to make it cross-platform, you will probably need different implementations per platform. If you can't do that right now, a wiki article might be better until someone has the chance to round it out to full platform support.

[wynnj]

Ok, I will start with the win32 implementation, but I think I can probably use the pnotify library to add support for linux/OSX. That would add yet another dependency though.

It was my understanding that when you reload a resource all the references are supposed to keep, but when you reload a mesh it appears to invalidate them. Is this a bug, or is it how it is supposed to function?

[sinbad]

The top-level reference will stay valid, the problem is likely to be with the SubMeshes and the references Entity keeps - this is unavoidable as you may change the number of SubMeshes for example.

Resource was enhanced fairly recently to deal better with reloaded resources so that dependents can check and rebuild derived data - see Resource::getStateCount. Entity now checks this before rendering to rebuild it's local SubEntities etc so in HEAD you should hopefully find this improved.

[Game_Ender]

For linux you should just be able to use inotify directly, no need to use a library in between. IBM has a tutorial here.

[Shadow007]

Game_ender : I guess you're right, but :
- pnotify does not sit on top of inotify, but i place of ...
- pnotify works on 2 platforms : Linux/OS X

[Game_Ender]

Yes buts its also another dependency. It really depends on how much Ogre wants to support non Linux/Win/OSX platforms. pnotify makes that easily possible. If we want to go the pnotify way I think it would be better to add Windows support to pnotify, and send the changes upstream.

[wynnj]

It took me a year to get back to this, but now I actually have something working. Or at least enough to launch into trying to more closely integrate with Ogre. I decided to not use pnotify simply because its implementation was blocking and I definitely didnt want to mess with threads. This also means there are no extra dependencies in the code that I've written.

One thing that I've not been able to puzzle out is reloading material files. If I try to load them a second time, it just says it already exists and throws an error, but reload doesn't work on them either because they are listed by material name not filename. Not sure how I can solve this without making changes deep into the material system.

[madmarx]

Two weeks ago i made a helper class that check for latest modification time of files in the disk, and reloads the material even when they are applied , and also give an output string with errors that were logged in the log ("myshader.cg made an error line 20...").

The whole thing is damn easy to use, and reloads efficiently material, shaders, textures...

I posted the full source code of this class in the Yaose Topic + example of a call and setup.

This is in the topic :
http://www.ogre3d.org/forums/viewtopic.php?f=5&t=46787

I hope this helps!

[Misterblue]

I have spent some time figuring out how to have on demand resources in Ogre. I wrote up a description and code of my solution at http://misterblue.com/programming/dynam ... -resources. What worked for me is adding an Archive class to catch the requests for meshes and textures and used one of the listener classes to capture material requests.

I'm sure it's not the most efficient solution but it is working for me.

[xavier]

The problem everyone is going to run into, is the fact that Ogre inherently caches pointers to its resources -- nothing (other than textures, which use name) are dealt with in terms of "handles". It's all direct pointer access. Until you figure out how to overcome this one, you're probably going to spend a lot of time chasing your tail in pursuit of this.

I'd recommend looking forward to the 2.0 timeframe and laying out an approach to refactor Ogre out of its cached-pointer-ness.

[wynnj]

Is there a reason that textures are looked up by name instead of a pointer? It seems that if it was terribly performance intensive to use a handle rather than a pointer then they too would be using pointers. If that is not the case, then is there a reason to not use handles (mesh name, material name, etc) for other resources as well? It would make it much easier to do streaming, caching, hot-reloading, etc. if it was all handle based.