Interview: Michalis Kamburelis, Developer Of Kambi VRML Game Engine

VRML and X3D have obvious advantages for displaying 3D graphics on a network, but many worldbuilders also built many games in VRML, that were sometimes showcased at Eurographics.

Kambi VRML game engine is a is an open-source engine that is especially oriented towards working with VRML models. In the last times, it has also increased its support for X3D, that is being developed. In addition, it has VRML node extensions that add lots of new features for graphics and gaming.

http://vrmlengine.sourceforge.net/

Michalis Kamburelis is the author of Kambi VRML game engine. Hiperia3D News has interviewed this great software developer.


- What kind of games can be developed using Kambi VRML game engine?

- Most of all, any kind of 3D game (FPS and others), as that's where VRML/X3D come to great use. Also 2D games are perfectly possible, since everything under the hood (starting with OpenGL) is suitable for 2D rendering. For example,"kambi_lines" demo is a trivial top-view 2D game, "sandbox" (SVN only) is a simple demo of isometric view a'la Diablo, "rift" (SVN only) is a
simple demo of fixed-view 3D (still 2D background with 3D characters, a'la adventure games like "Alone In The Dark" etc.).

Games are portable, as the engine is portable, and uses portable libraries (OpenGL, OpenAL). I work 90% of my time on Debian, the engine works under Linux, FreeBSD, Mac OS X (and probably any other Unix) and (yeah, you guessed) Windows. The programmer shouldn't need to write any platform-specific code.

On the darker side, networking is not really implemented. So network games (internet a'la MMORPG or local) are not possible, unless of course you're ready to implement networking part yourself. Which doesn't have to be very difficult, taking into account many networking libraries
available for FreePascal, but it really depends on your game needs.

- What demos are included and what are they about?

- Two most important programs (not really a mere demos) are

1. view3dscene, universal VRML/X3D (and other 3D formats) browser.

2. "The Castle", FPS game. I was quite proud of this game, but now it got old and game content doesn't use many of the newer engine features (shaders, bump mapping, VRML events), so around the end of this year I plan to make a new FPS game designed to blow your eyes... uhm, I meant "to impress you" :)



Demos provided in pre-compiled form on http://vrmlengine.sourceforge.net/ show various things. "malfunction" and "lets_take_a_walk" are simple 3D games, and are mostly for historic
purposes (they are also somewhat playable :) ). Others, like "glplotter" and "glViewImage" can be used as actual usable programs (to display function graphs and images), they were developed by the way of making the engine.

Inside engine sources there are a lot of example programs (in examples/ subdirectories). Too many to actually list them all, and they try to show pretty much every part of the engine (audio, shadows...). These example programs are mostly for programmers who want to learn how to use Kambi VRML game engine.

There is also Kambi VRML test suite, partially as a demo what VRML content we can interpret and display.


- What visual improvements does Kambi engine have?

- Bump-mapping and shaders are available, and I'm quite proud of them :) Multi-texturing by standard X3D nodes is not available *yet* --- this is one of the more important things for the next release after view3dscene 3.0.

Some details: we have various bump mapping algorithms available, starting from simple bump mapping using multi-texturing with dot3, to the most advanced steep parallax mapping with self-shadowing (using GLSL shaders).

The beauty is that VRML author doesn't have to know anything about the implementation. Activating bump-mapping is very easy for VRML authors that know how to "hack" VRML sources, see http://vrmlengine.sourceforge.net/kambi_vrml_extensions.php#ext_bump_mapping.

When designing with White Dune, you can even do it visually. Internally engine will take care of everything, including selecting the best bump mapping method suitable for current hardware,
loading and setting up necessary GLSL shaders etc.

GLSL shaders are available. Following the nodes and syntax in X3D specification.



Some other notable features:

- 3D sound (by OpenAL, with OggVorbis etc.). Sound support is not yet integrated with VRML (which means, it's available to the programmer using the engine, but is not immediately available to VRML author trying to use standard nodes like Sound).

- We have really good implementation of shadows using shadow volumes. This includes z-fail / z-pass switching, silhouette detection, frustum culling etc. You can see some technical creenshots on http://vrmlengine.sourceforge.net/vrml_engine_doc/output/xsl/html/ch07s02.html.

- MovieTexture is implemented, besides normal movie formats (through ffmpeg) it can also play movies from a sequence of images with full alpha channel (ideal for pre-rendered fire/smoke animations, like rendered by Blender from it's particle engine).

- That's enough bragging, I guess :) Full list of features is on http://vrmlengine.sourceforge.net/kambi_vrml_game_engine.php, and there's documentation on http://vrmlengine.sourceforge.net/vrml_engine_doc.php.


- Kambi VRML game engine is written in ObjectPascal. Do users need a good knowledge of Pascal to build games with it?

- Yes. Although it's possible to just use view3dscene VRML/X3D browser, then no knowledge of ObjectPascal is needed of course.

But in practice, you will not be able to make a "real" game this way. Especially since scripting (through VRML Script nodes) is still not implemented. So for a "real", non-trivial game, you have to write and compile some code yourself, expressing complicated behavior (like creature intelligence) in ObjectPascal code.

- Kambi engine supports X3D and VRML. At what degree are these supported at this moment?

- VRML 1.0, 2.0 (aka 97) and X3D (both classic and XML encoding) are supported. VRML 1.0 is pretty much complete (with the notable exception of networking --- not implemented for now, so only local files with local filenames may be used). VRML 2.0 and X3D have a lot of features
covered, including all standard rendering features, full PROTO and EXTERNPROTO support, SVN version includes routes/events/sensors mechanism.

Most important lack is the scripting support, and sensors support will be quite limited in the next view3dscene 3.0 release (only basic TimeSensor, KeySensor, TouchSensor, ProximitySensor support).

Really detailed list of VRML/X3D features currently supported is available on http://vrmlengine.sourceforge.net/new_vrml_implementation_status.html.


- What advantages do VRML and X3D have for game developing?

- It's a great 3D content interchange format, and so much more. Long time ago I tried to make a conscious decision about what 3D format should I focus on, and VRML turned out to be just perfect. Open, precise specification, support by virtually any 3D modeling program, extensibility,...

The only other 3D format that is at least close to VRML is Collada, but I personally choose VRML anyway (since it has a lot more than Collada, whole events and sensors mechanism just for starters; and many other small reasons, that boil down to "I like VRML more").

- And what flaws that you've successfully overcomed?

- Not much. Shadows and easy bump-mapping come to mind. In theory, it's possible to implement bump-mapping in standard VRML using GLSL shader nodes, but I think that my approach (simple normalMap field for KambiAppearance node) is more scalable and much simpler for VRML authors. For shadows, the lack of specification support is understandable --- it seems nearly impossible to add shadows to VRML language in such way that it's flexible for VRML authors and at the same time doable for various implementors using various algorithms.

Fortunately, this is where "extensibility" of VRML comes to use, it's trivial to add your own nodes.

List of currently supported extensions in my engine is on http://vrmlengine.sourceforge.net/kambi_vrml_extensions.php.

- As the VRML spec does not force to support object-to-object collisions, that is something that most VRML viewers lack. How does Kambi engine deal with these?
- When using view3dscene as universal VRML browser, this is simply not implemented for now. When rolling your own game, the main collision-detection structure we have is an octree and axis-aligned bounding boxes and/or spheres for moving parts (creatures, level moving
parts like elevators etc.). Octree may be triangle-based and shape-based (every occurrence of X3DGeometryNode is treated as one item), both types are useful and usually both are created.

Admittedly, this is not a very scalable solution. It works fine for typical FPS games, where you can (most of the time) separate "dynamic" parts like creatures, elevators etc. from "static" parts. It fails when you want to make every part of the world dynamic. In the future, I'll switch to so-called "loose" octree, to allow smoothly updating octree. And some day we'll probably use external physics engine.


- And what about collisions between avatar and objects or enemies?

- view3dscene creates an octree, so collisions between player and scene work fine, as long as the scene remains static (otherwise octree recalculation is an overkill on scenes where geometry changes, and it has to be turned off).

The rest of the answer is the same as for previous question: you can roll your own collision-detection when making your games, utilizing octree and various bounding objects for moving parts. Far from perfect, and to be improved in the future.

- Have you thought in adding support for H-Anim or Blaxxun avatars for players and enemies?

- We have the basic HAnim support, which means that we can correctly render your human designed with HAnim nodes and efficiently animate it through VRML interpolators. In other words, Joint is pretty much just a Transform node, Segment is pretty much just a Group node etc. So while we support HAnim, we don't do anything interesting with extra information about the skeleton (we're not 3D authoring tool, we only render it).

Implementation was tested on all HAnim versions (1.0, 1.1 and 200x HAnim), both in VRML 2.0 and X3D (in X3D specification says to prefix nodes with "HAnim", like "HAnimJoint"). Our "VRML implementation status" page has some technical notes about this.

So if you already have 3D authoring program to design using HAnim stuff, that's great --- use it to design and animate your humanoids, and we'll be able to render them using standard VRML stuff. So you can use them for player/creatures in our engine. We do nothing more, currently. In
the future this may be improved.

- Have you considered supporting online multiuser games?

- Making online games wasn't the focus of my engine, that's why networking support is almost non-existent. *For now* :)

As someone who likes to make (and play) games, I'm personally still focused on single-user games. That's either because I'm not a social person, or because I really like games with interesting stories underneath, you decide :) I *do* like online games, but even the ones with a thrilling and living world don't feel "personal", not personal like a good single-player game. Of course, this is entirely my point of view and based on my experience with games, you're welcome to prove me wrong.

As someone who makes a VRML and game engine: networking support, including the possibility to make online games, is sure a great thing to have. It'll inevitably be tackled in my engine at some point. Before the end of this year, I plan to add at least basic http:// support for "url"
fields, this is trivial after all. But it will still be very far from being able to make real online game. Contributions are welcome, developers interested in making online game using my engine are welcome!

- What are the features that you would like to add in the future?

Hm, I either like to talk a lot or your questions were perfect :), because I feel I already mentioned most of the things I like to do in the future. In the nearest future (I mean, right after view3dscene 3.0 release) these are: multi-texturing and cube map texturing using standard X3D nodes. In the (slightly) more distant future: loose octrees, physics engine, scripting, H-anim, networking. Oh, and particle engines using standard X3D 3.2 nodes would be nice one day.

-Jordi R. Cardona-

© by Jordi R. Cardona. Link to this post without copying the text.

If you liked this post, get updates of Hiperia3D News for FREE