OGRE & Cube (1)

A design of Cube is based on OGRE. When I started to design Cube (The prototype name is Shade 2), I had not learned PHP and Web applications enough (also now). By that, I brought certain design that I usually handle, into XCube. That is the concept of the scene graph, especially OGRE.

In those days, I did not think that Shade become just XCube. But, I had the following opinions.

No Framework

In those days, Japanese PHP programmers were discussing about frameworks. “Framework” is the special term for Japanese. Japanese people often draw a line about Japanese between English, so “Framework” got different from “Wakugumi” that is translations in Japanese. That may be important discussion for IT professionals. But, it seemed to be unusual for me. I didn’t want to be involved in it. Therefore, I thought that XCube should have no framework.

Multi Render Target

Designers see the theme format and CSS as problems. But, that is a kind of religious controversy. I thought that XCube should not join in this controversy, because this is solvable by the plural renderer. But, new format gives bad effects to existing modules and themes. We should be able to use different formats in the same time, and the final output should be able to include results of them. 3D applications often have such purposes. I brought the concept of render-system & render-target into XCube.

Configurations

The configuration of XCube is decided by the .ini file. Someone said that it’s DI. But, this is not DI, because XCube doesn’t want to be involved hot topics of the professional world. In fact, this process is based on OGRE. OGRE consists of exchangable managers. And, there are many useable plugins for those managers already. Developers decide the combination by editing cfg. This is the only way that users can give effects to the initial part of the program — except editing source code. OGRE has shown “exchangable” concept, so they don’t encounter needless discussions “what is the best design for all of mankind?”.

Exchangable

XCube doesn’t have actual functions for realizing web sites. This is the concept of OGRE, too. OGRE is very compact engine. It doesn’t have dynamics, AI, terrain and BSP. Such engine was uncommon when developers began OGRE development. “The Engine” had to implement many feature to realize FPS easily. But, some other engines stopped, because they could not solve many tasks and many controversy. Meanwhile OGRE had kept its progress.

For example, in a engine, even if you can’t be gratified at its BSP process, you can’t change the embeded BSP process without editing source code. OGRE shows another way for these cases. “Exchangable” denies “Only One Standard”. In OGRE, you can develop another BSP. Also, you can do it in XCube. This feature was called “Wii like”.

Advertisements
This entry was posted in XOOPS Cube. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s