Archive

Archive for the ‘OGRE 3D’ Category

Hikari

September 4, 2008 3 comments

Hikari is an ADD-ON to handle FLASH on OGRE3D. Hikari works on only Windows OS, because it needs flash.ocx. This is an excellent ADD-ON and makes it possible to design UI by FLASH and bind it to game programs.

The Demo reflects values of both slider and color pallet to the viewport. And the Demo application send FPS value to Hikari and show it by using functions of FLASH. In other words, the application of the OGRE 3D can read values from FLASH side and can send values to FLASH side.

At recent years, video games use FLASH with the middleware to implement rich UI rapidly. By Hikari, we became able to try it at our free time!

Categories: OGRE 3D Tags: ,

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

September 2, 2008 2 comments

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.

Categories: OGRE 3D

OGRE 1.6.0RC1 (‘Shoggoth’) Released!

August 31, 2008 Leave a comment

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.

Categories: OGRE 3D

An Overview of Collision Detection in OGRE 3D

May 5, 2008 1 comment

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.

Categories: OGRE 3D Tags:

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.

Categories: OGRE 3D, XOOPS Cube
Follow

Get every new post delivered to your Inbox.

Join 54 other followers