Ogre Forums

Hello!

What do you think about striping the VFS from Ogre3D and maybe moving it into a seperate OgreVFS library and package?
Maybe there are even more things that are not the core task of a graphics engine which could be moved into seperate packages/projects.

I think that a graphics engine should be only that, a graphics engine. This would make it easier to use Ogre with other products, which may be more convenient or powerfull, or to integrate it into existing applications, which maybe allready have a good infrastructure and just want a graphics engine.

--
DevUrandom

VFS? You mean the resource/resourcegroup manager?

The part with the zipfiles, yes.
I would eg. like to use PhysFS instead, but nevertheless I need to compile and include Ogre's own VFS implementation which seems tied pretty much down into the system.
I suspect that there are other parts which might not directly match the scope of a graphics engine.
So my private primary "problem" is the VFS (currently), but I think it should be thought about which parts of the engine are core 3D tasks and which are not.

VFS sounds too much like Crystal Space system, which is different from what Ogre does. So this is not a commonly used name for Ogre's resource and archive system.

Ogre being a graphics engine means, that it needs to access the media it is supposed to render in some way. This is different from input, which has been removed with Eihort. Input is not needed in order to render media, but access to these media is.
Of course it would be possible to only have interface stubs in Ogre and file access implementing these stubs outside of it. But that would mean to create an implementation outside of Ogre that 99.99% of Ogre users are going to use anyway and thus make it more tedious for the great majority of Ogre users. And even if you want to use other means to access your media than zip archives or OS file systems, you can do this already.

So far you didn't bring forth a sound reason to separate it. If you want to argue in favor of removal, you have to do it more convincing and you have to provide factual arguments for real-life situations. And you have to explain your proposal in more detail with regard to the actual implementation in Ogre.

Sounds sensible...

And even if you want to use other means to access your media than zip archives or OS file systems, you can do this already.

I can disable (aka not compile) the Ogre VFS and provide an own one?
I didn't know that... When I looked at it, it seemed pretty much tied into the engine, without providing an interface I could use to provide Ogre with the data it wants.
Maybe you can give me a hint which classes or docs I should look at?

You can indeed tie any mechanism you want in. If you dont want to remove the current resource system that's fine. Just create your own ArchiveFactory and Archive subclasses and you can create your way of handling files.

I recently ran into problems with Ogre resource system. It has served my needs so often in the past, but now it really got in the way. However, I wanted to handle zips and dirs the same. So, I just don't use the automatic resource mechanisms and use Archives directly. Poke around a bit more and I think you'll find quite a bit of flexibility even in a system that seems so hardwired.

Praetor wrote:If you dont want to remove the current resource system that's fine.

I do want to... Since I don't need/want the additional code in the lib.
Is there a configure switch to disable this part? Or do I have to fiddle with the makefiles?

You could just, like, you know, ignore it?

A few kilobytes wont break the bank.

DevUrandom wrote:

Praetor wrote:If you dont want to remove the current resource system that's fine.

I do want to... Since I don't need/want the additional code in the lib.
Is there a configure switch to disable this part? Or do I have to fiddle with the makefiles?

Resource loading is a fairly integral part of Ogre -- code changes are needed to have it not create FileSystem and Zip archive readers.

What is it exactly that you are trying to achieve? What are you trying to do that implementing an Archive or using manual resource loaders can't fix?

xavier wrote:Resource loading is a fairly integral part of Ogre -- code changes are needed to have it not create FileSystem and Zip archive readers.

Actually, I ran into something like that at one point: you can't override Root's ctor to change how Managers and such are instantiated.

Suggestion: How about moving that code into a virtual method called from the ctor (or Root::initialise), so users can derive from Root and provide their own Manager instantiation code?

Of course, it may not be that simple. Changing what Root is hard-coded to set up might break a lot of things if there are lots of interdependencies between different Managers. (It may not be as simple as just not using whatever you've changed or removed.)

Anyways, just an idea I thought I'd throw out there.

Actually, I ran into something like that at one point: you can't override Root's ctor to change how Managers and such are instantiated.

Suggestion: How about moving that code into a virtual method called from the ctor (or Root::initialise), so users can derive from Root and provide their own Manager instantiation code?

i ran into this issue before. as i want (and still want) OGE to handle the overall resource management, im gona create an archive factory etc for ogre that interfaces to my resource system, but OGREs will still be there, and each time resources are to be loaded, it will check each one in order. so the only one i want ogre to use, will be checked last.

surly if there were a few more #defines in the OgreConfig.h, one for each archive type, then they could be both turned off. allowing users to provide their own, without any overhead of the default ones?

xavier wrote: What is it exactly that you are trying to achieve? What are you trying to do that implementing an Archive or using manual resource loaders can't fix?

I want Ogre to use my resource management, which uses an external VFS library.
I need that resource management system and the VFS library, because of the way the data is organized and of course because not only the 3D part of the app needs a resource management system.
Additionaly I don't find it comfortable to have 2 resource managements or 2 VFS layers in the app. At least it sounds a bit stupid to me to duplicate code.
So my idea was to strip out at least Ogre's VFS and hook my own in instead. Of course it would be even better if I could unify the resource managers. And surely it would be even more better if not my whole app would depend on the 3D library, but instead make the 3D library use my app's code.
This is how I think currently, but maybe there is a bug in my thoughts...

Why not provide access to your VFS through an implementation of Ogre::ArchiveFactory/Ogre::Archive? This is the standard way to let Ogre use external VFS systems.

I'm still not getting it.

And what exactly do you want to strip out? Please name classes. Your answer is still too much on a generic layer.

I think he means:

I have a resource system for my main application maybe it has support for distributed resources now the problem is that ogre has it own resource system this means it takes up memory twice eg.: My System has a resource registered and Ogre System has also the same resource registered.

So i think DevUrandom has tackled a good question why we should waste memory for the same thing?
Why is the resource system not plug-in based so that i can plug my own system in?

Why not provide access to your VFS through an implementation of Ogre::ArchiveFactory/Ogre::Archive? This is the standard way to let Ogre use external VFS systems.

but it still has its own default ones active. even if you dont add any paths for them to use, they will still be checked first.

There are no paths that are checked or default archives that are loaded unless you tell Ogre to check them or load them -- not sure what you are referring to here.

The way to use your VFS with Ogre is to do it the way Ogre was designed: implement an Archive or use ManualResourceLoader implementations. There is NOTHING that says you have to make your resources available to Ogre ONLY through Zip files or filesystem objects. We do not use a single loose filesystem file or Zip file in our project -- everything is provided to Ogre through ManualResourceLoaders from our own custom data file format.

So in effect, I don't know what we are discussing here -- Ogre already decouples this via interfaces and provides a couple of sample implementations of those interfaces.

Chris Jones, this is an implementation detail and can be changed inside the system that is there now. Actually I agree that it can be useful to not instantiate archive types, that are not used anyway. But this doesn't mean they have to be removed. Your problem is a completely different matter imho.

Wolfmanfx, but what resource is registered twice? What is this resource thingy? An Ogre::Resource? If so, why have a different one instead of the one Ogre uses? After all it is ogre that is used to render them and Ogre has to somehow access the media data with some interface. And since Ogre can only use the interface that has been defined when Ogre has been written I don't understand how Ogre is supposed to magically access the data from the other resource systems other than those Ogre uses.
So if one resource is pointless, it is the one not using the Ogre interface. Simple as that.

Wolfmanfx, and again, what classes exactly as a plugin? Ogre::Mesh, Ogre::Material? But these are vital. Without Ogre::Mesh you can't use Ogre::Entity and what is a render library without entities? This is taking modularity too far imho. What exactly do you want to take out of Ogre into a separate plugin?

There is a well defined Resource interface and a well defined Archive interface. Let your application implement those interfaces so Ogre will use them. Or use a manual resource loader for everyhing or... Many possibilites but removing Ogre's resource system won't help a bit.

And, at least for PC, the extra memory in the executable is irrelevant. And from what has been brought foward so far this has not been marked as crucial in any way.

From what I can discern this is solely a debate on principles. Which one can have, but which is pointless without regard to actual real-life cases with actual real-life problems. Which is why I ask for these.

I think you guys will find that compared to the overall size of Ogre's object code, the size of the resource management implementations for folders and zips is tiny.

Both the FileSystem and Zip implementations are a single CPP file each. They used to be plugins but keeping them separate was a complete waste of time for the amount of code involved.

As others have said, if you want to use other sources of files, Archive / ArchiveFactory is the way to do it.

I think you're totally overstating the issue here. Have you actually examined exactly what it is you'd be removing if you did take it out?

The Resource system is not a duplication of a 'VFS' system. A VFS is just an abstraction of a source of files, which is what our Archive system already is. The Resource system uses our 'VFS' but performs no VFS-style tasks, it's a completely different set of features.

If you want to use PhysFS, go ahead. Just write a small Archive / ArchiveFactory bridge between them, it's really not very hard. Then just addResourceLocation with only your new PhysFS archive type. Physically removing the existing FileSystem and Zip archive types would save you a tiny, tiny amount of space that it's not even worth considering. As such it would be completely pointless.

Ogre's 'VFS' is all about pluggability - the implementations of exactly where the files / streams come from (Zip / FileSystem / PhysFS if you like) is completely decoupled from the use of those files and streams. Honestly I fail to see how it could be any more easily integrated with external systems - I think maybe there's some element of being blinded by terminology in this request.

Thanks for the information. I will have a look into Archive, ArchiveFactory and ManualResourceLoader and see which one I need to use my resource system.