Shoggoth removed SceneNode::getWorldPosition() and getWorldOrientation()

In Ogre 1.6.0 RC1, SceneNode::getWorldPosition() and SceneNode::getWorldOrientation() was removed. A topic of the forum reports that some developers who changed their engine to 1.6.0 get errors at compiling.

'getWorldOrientation' : is not a member of 'Ogre::SceneNode'

Changelog explained those two methods were removed from Renderable interface. At the same time, those methos were removed from SceneNode class. The engine gets full transform matrices from Renderable interface, so it doesn't need getWorldMatrix() and getWorldOrientation(). We may use _getDeriveedPosition() and _getDerivedOrientation() instead of the removed methods.

getWorldPosition() and getWorldOrientation() were pure alias methods. Therefore, you may add those alias methos to OgreSceneNode.h of 1.6.0. Even if you do this little hack to a header file of the prebuild SDK, you don't need to re-build the engine.

OGRE 1.6.0RC1 ('Shoggoth') Released!

OGRE 1.6.0 RC1 "Shoggoth" was released. Summary of new key features is following:

• New more powerful script compilers
• Geometry shaders in OpenGL
• Antialiasing on render textures as well as windows
• sRGB gamma correction
• Alpha to coverage support
• New 'Portal Connected Zone' SceneManager 
• Parallel-Split Shadow Map support
• Improved tangent generation
• Skeletal blend masks
• New background loading options
• Custom memory allocator support

The prebuild SDK is going to be released.

New features are appended to the script that we are using to define materials and particles. OGRE_USE_NEW_COMPILERS in OgreConfig.h decides whether the engine uses new features. The Material Feature is improved at this new version and got to handle new shader parameters.

In addition, the Scenemanager got to support "Portal Connect Zone". By that, we can switch in/out-house effectivity. The movie that was used for explanation this feature is following:



In 1.6.0, it's possible to change memory allocator. This is one of the most important features.

An Overview of Collision Detection in OGRE 3D

OGRE3D provides some methods for collision detection. We, Japanese developers call collision detection "hit". Before I explain collision detection, I list factors of collision detection to share our recognization:

• It's useful that many primitive form classes are defined for detect collisions. OGRE 3D provides ray, bounding sphere and Axis Aligned Bounding Box (AABB).
  
• It's possible to handle triangle and planes at Collision Detection.
• OGRE3D doesn't provide ellipse, cylinder and other high-order calculations.
  
• It's possible to detect a collision between Ray and a triangle of a mesh.
  
• We often use low level of detail meshes to detect collision quickly. Does OGRE 3D provide the method to do it?
  

I want to append a little explanation to the last item "low level of detail meshes to detect collision quickly". Japanese developers call such meshes "Hit Model". I don't know what to call it in English, so I describe it as Hit Model in this entry.

OGRE 3D provides all basic collision detections. Bounding Volume instances are generated automatically. For example, Mesh class generates Bounding Sphere and Bounding Box automatically and keep those. This thought is very happy and quick for programers, because they don't think about tools that generate collision data. But, it may be issue for video game development.

In the beginning, you may want to know how to detect collision between Ray and World Geometry. If the world geometry of your game is not height map but a static mesh (rigid model), it's easy to detect the collision. You need to check a collision between Ray and triangle of the world geometry. To do it, we use RaySceneQuery class instead of combination of primitive classes. This is very powerful thought.

A summary of RaySceneQuery is just Ray. But this class exists to handle collision detection. If you use Ray class, you have to write long code to detect collision between Ray and data of geometries in the scene that have possibility to collision with Ray. Plus, your program has to implement gradual detections from BoundingSphere to Triangle of the geometry with using Octree or Quadtree.

RaySceneQuery encapsulates such a standard collision detection process. RaySceneQuery returns the distance from the collision point, so it's easy to do Y-undulation. Some kinds of SceneQuery sub-classes are defined for other classes that work for Collision Detection.

Now, what do you think you need for the standard collision detection process? The scene has many meshes. And a mesh has many triangles. Features that we request to the engine are the following:

• 1) Removes the geometries that don't have the possibility of collision with the ray from the candidates.
  
• 2) Masks the geometries specified by us.
  
• 3) Uses bounding volume for the first collision check.
  
• 4) Keeps the gradation of 1) and re-uses at the next check.
  

Does RaySceneQuery provide these features? At the beginning, we want to understand all functions about collision detection of OGRE 3D.

OGRE 3D moves their source code repository from CVS to SVN

OGRE 3D, that has a project model that the XOOPS Cube project referred to, moved their source code repository from CVS to SVN. We are using CVS now, because it's possible to manage a range of access right of comitters who are assigned to each modules on CVS. We imitated a project model of OGRE and imported this scheme. But, they got to use SVN, so we'd better check how OGRE 3D uses SVN.

Some programers don't want to check the repository of XOOPS Cube, because they are ashamed to use CVS, whatever the repository stores. I don't understand such an obsessiveness that great programers have, but it's good that XOOPS Cube will get to cover the pride of them, if SVN can run our project model.