Ogre's method has lots of weaknesses.
Like... many models share the "technique" (shaders, parameters, etc) but with different textures.
Ogre forces you to have lots of materials specifying shader settings and passes and alternatives over and over. Ogre moved away from that model, making some things, like textures, "pluggable" into materials for that exact reason.
Besides... .material files would indeed refer to textures by name. There's no way around that. References get broken when you rename a file, and you can't reference a texture without naming the file. So no magic bullet for you (or anybody else).
I would indeed ascribe to the practice of separating material data from mesh data. BFXM files are binary and difficult to edit, yet material data (texture references and such) need frequent editing. Having material data in a separate (text) file, would ease maintainance cost a lot. There's already a ticket for that BTW.
Image Types and Image Extensions
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
-
- ISO Party Member
- Posts: 461
- Joined: Fri Sep 03, 2010 12:10 pm
Re: Image Types and Image Extensions
I can derive a class in ogre from manualresourceloader in which the vs texture load functions are called.
So, no name renaming is needed.
(This is the theory for me yet)
So, no name renaming is needed.
(This is the theory for me yet)
plz visit my vegastrike project branch here
plz support VegaOgre by donating to it!
My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
plz support VegaOgre by donating to it!
My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed