search

realXtend / tundra

realXtend Tundra SDK, a 3D virtual world application platform.
www.realxtend.org
Apache License 2.0
84 stars 70 forks source link

Enhance AssetTypeFactories to be able to create non-empty assets and already registered asset types from new file extensions #631

Open Stinkfist0 opened 11 years ago

Stinkfist0 commented 11 years ago

This would allow getting rid of somewhat hackish integration of AssImp and Crunch and would be better for future usability when incorporating support for new asset types in Tundra. See related discussion in #513 and #532

Stinkfist0 commented 10 years ago

Bumping the issue as this has been on my mind lately and we (Admino) might be doing something regarding this.

jonnenauha commented 10 years ago

The main problem with this setup is that EC_Mesh casts the IAsset* into OgreMeshAsset*. It also requests the mesh with forced type OgreMesh via the ref listener. This forced the Assimp integration to be quite ugly (although it already is a lot nicer with the new signal business), making the OgreMeshAsset emit a "conversion needed" signal and making something do something. It's not very structured.

So, how would this asset factory mod exactly fix this problem? EC_Mesh would still cast to the one asset type ptr even if we made AssimpMeshAsset. Or is this some completely separate thing and does something else?

I think the easies solution to fix this mesh business is defining a OgreMeshAssetBase or similar, that would have the needed shader variables EC_Mesh actually needs to load the mesh. As far as I can see that would be the CPU side cached geometry stuff (including the raycast func to it) and the actual Ogre::MeshPtr.

This could then be inherited by Assimp modules AssimpOgreMeshAsset and others, and EC_Mesh would cast to that and accept anything that implementes OgreMeshAssetBase.

Stinkfist0 commented 10 years ago

Don't think such base class would be needed. OgreMeshAsset can be considered source agnostic: once mesh data is loaded (and converted), an in-memory Ogre mesh is always an Ogre mesh and it doesn't know anything about its origins. Filename and file extension can be simply considered as metadata for identification.

jonnenauha commented 10 years ago

I'd love to see in code a proposal how this would work, like how would the current asset request flow change. Those are nice words that everyone can agree on but are not a solution. But can you explain in detail how your factory changes would fix eg. the EC_Mesh "problem". I'm thinking in practical code change steps, you are just atm talking about a "ideal way of loading meshes" without any hint what would need to be changed.

You mean when the AssetPtr loaded signal arrives to EC_Mesh it would query Ogre a MeshPtr with its sanitized name and use it if found? This is what you mean in the factory re-factoring that it would not actually produce any kind of IAsset but just load stuff to Ogre? Different code could handle different file extensions etc.?

That would surely work (after a fair amount of re-factoring) but the CPU side geometry caching would need to be moved somewhere per asset, maybe to OgreWorld.

Stinkfist0 commented 10 years ago

This commit in the AngelScript branch is somewhat related: https://github.com/LudoCraft/Tundra/commit/d4bfce39d0a4ce13da5a71d88e9b126af3769587