While the ogre sample media is intended primarily for use in the ogre samples, having a selection of useful media already in ogre format is a great feature for rapid prototyping, especially for coders who have no art skills or nearby artist.
I've already fixed some issues with a few of the meshes (cube.mesh had broken normals, geospheres didn't have the origin at their center so they wobbled when rotated, etc) around a year or two ago (I think ogre 1.7 has the newer versions), but there's a lot of changes I want to make which will break current media use, which is why I put this in papercuts.
Take a look at this pic:
These are all the ogre sample meshes side by side with the same scaling factor. The green line is the Y origin.
Problem: Scale
As you can see, the scale varies wildly. Here's the size (in ogre units) of each mesh:
Code: Select all
athene.mesh Size: <55.3616, 163.262, 64.7096>
Barrel.mesh Size: <5.32, 6.14, 5.32>
column.mesh Size: <47, 442, 47>
cube.mesh Size: <100, 100, 100>
facial.mesh Size: <58.1849, 72.8472, 57.4565>
fish.mesh Size: <7.36978, 3.07694, 3.44928>
geosphere4500.mesh Size: <399.78, 400, 399.728>
geosphere8000.mesh Size: <400, 400, 400>
jaiqua.mesh Size: <38.0775, 18.9682, 93.7924>
knot.mesh Size: <190.216, 202.395, 147.127>
ninja.mesh Size: <65.0689, 195.649, 101.493>
ogrehead.mesh Size: <57.8734, 54.0165, 49.7022>
penguin.mesh Size: <61.7703, 47.0496, 48.3053>
razor.mesh Size: <160.639, 42.5104, 152.693>
robot.mesh Size: <32.1252, 101.673, 49.0925>
RZR-002.mesh Size: <24, 5, 22>
ShaderSystem.mesh Size: <200, 200, 200>
sibenik.mesh Size: <126, 32.6, 80>
sphere.mesh Size: <200, 200, 200>
spine.mesh Size: <32.7714, 104.04, 28.8151>
tudorhouse.mesh Size: <675.985, 1120.86, 732.911>
WoodPallet.mesh Size: <7.1967, 0.803846, 7.06621>
Sinbad.mesh Size: <8.88854, 8.93138, 4.69699>
dragon.mesh Size: <230.912, 288.056, 268.653>
Proposal: All meshes should be scaled to a uniform real world unit. My preference is metre scale, since this is the international standard unit for distance measurement and physics engines tend to like metre scale. If another scale is preferred by the majority of users, fair enough, as long as it's uniform for all meshes.
Problem: Mesh Orientation
Ogre uses -Z as the default facing direction. All lookat or setdirection style methods assume -Z as the default, and untransformed cameras face -Z.
But the meshes use various facing directions.
+Z : athene, ogrehead, penguin, razor, rzr-002, sinbad, facial
-Z : ninja, jaiqua, dragon
+X : robot
-X : fish
Proposal: All meshes should face -Z. This means that ogre's camera and general facing direction code matches the facing direction of every mesh. If you tell a scene node to face another object (auto tracking, lookat, etc) then the mesh within the node should be looking at the target too, not backwards. The +Z direction might be ok for models you just want to drop in a scene and look at (like athene), but once they are controlled as dynamic objects it's much simpler to have them follow the ogre standard.
Problem: Mesh Origin
The origin for meshes varies as well. This one is a little trickier because different uses benefit from different origins.
The ninja, jaiqua and robot all have the origin at their feet (centred on X and Z, 0 on Y). This is the best position for any mesh which is placed in a typical scene, you can make a mesh sit perfectly on the ground without knowing how big the mesh is. You tell meshes where to stand by placing their feet. For all general objects this is a good standard.
Sinbad, tudorhouse, dragon, barrel, athene, razor, rzr-002 all have the origin around their centre. Placing them in a scene requires checking their bounding box so they can be offset from the ground (if padding is on in the mesh manager, as it is by default, then the models will float a little above the ground).
But usage can vary. I think all objects which are placed on the ground should have an origin at the base/feet, but objects which rotate on any axis (ships like razor and rzr-002, spheres, anything in the air) work better if the origin is their centre of mass. Physics engines also tend to use centre of mass for positions.
Proposal: All ground based meshes (furniture, living things, etc) should use a centred on X and Z, 0 on Y origin. Other objects (utility shapes likes the spheres and cube, or non ground based stuff like the fish, razor, etc) can use the appropriate origin for their intended use (probably centre of mass).
Problem: Licensing
Ogre has a heap of textures. There's 131 just in the texture resource path, plus more in zip files and maybe other directories (such as pczappmedia).
The problem is that the license doc with ogre isn't very clear on the license for all these:
Which textures are from Matt Anderson? We need to give credit to The3DStudio if we use them.Matt Anderson at http://www.The3dStudio.com who kindly gave permission for the use of some textures. These textures are used with permission of http://www.The3dStudio.com and may not be re-distributed, sold, or given away except in the form of rendered images, animations, or real time 3D applications when credit is given to http://www.The3dStudio.com.
Jonathan Clark at http://www.jonathanclark.com for some Golgotha textures thet were released to the public domain.
Grass texture is courtesy of Mathias 'freezer' Walc
Which textures are from Golgotha?
We have 3 grass textures, which is from Mathias? All three? (One is overhead grass for terrain, 2 are for grass geometry rendering)
Most of the meshes are covered in the licensing page (ninja and robot are from psionic, facial and jaiqua are from SoftImage samples, etc), but who created athene, fish, penguin and tudorhouse?
Proposal: All sample resources should have clear licenses. We should have a page in the docs which shows a thumbnail of each texture and lists where they came from and what license they have. Or at lease keep them in different directories, like how the 6 nvidia licensed textures are in textures/nvidia.
Problem: Sample media could do with a touch up / replacement.
Some of the sample media is getting a bit old (8 years or so). We should update or replace some of them.
Razor has bad jpg artifacts clearly visible in it's texture, and it uv unwrapped at a 30 degree angle which makes painting textures hard.
Droplet.png has no alpha channel. (While it works fine as an additive particle, it's black border sucks for alpha particles).
Ogrehead is non manifold, is old and has been used by other 3d engines in rendering samples.
Proposal: Razor isn't really needed anymore since we already have rzr-002 (which looks cooler). Other textures and meshes can be improved. Ogrehead should be replaced by Sinbad's head (the 3d model, not steve, although a laser scanning of steve's head would be damn cool). Actually I seriously think we should change the ogre logo to use the sinbad head too, it's a much better looking model and is made by a community member instead of being an old character studio sample file.
Other things that would be nice but not likely to change: make all meshes have similar animation and bone names. Preferably have all of them follow sinbad.mesh's example and have upper and lower body animations for easier blending. It probably won't happen, but I can dream.
Of course there are a few potential problems with these improvements.
Changing any sample media will affect the sample browser. This is pretty minor though, we can fix that easily. But it will also affect the wiki (all tutorials need to be checked, etc) and any user projects (install ogre 1.9 or whatever and find your ninja is 100 times smaller).
Size is always an issue. There's currently around 59MB of media resources. We wouldn't want to increase this by much (preferably make it smaller if possible). I'd love to add tons of new high quality sample meshes and textures, but it's a waste for most users. One solution to this would be a separate repository (like ogreaddons) just for resources which are ready for ogre use and meet all the requirements I've mentioned above. This could have stuff which isn't used by the sample browser, but is available for users for quick inclusion in their own projects.
Even if all the other proposals are ignored, we really do need to fix the licensing issue of textures and meshes.
.
