Forum
Ask for help, report bugs, discuss features

Alternatively, if you prefer to send questions through email, you can subscribe and post to our castle-engine-main mailing list.

You can also submit bugs and feature requests to our "tickets" tracker.

If you really want to contact the author directly, send email to Michalis Kamburelis.

Helping in the engine development

If you'd like to help in the development of our engine, here are some proposed tasks:

For everyone:

• Brag about our engine on blogs and social platforms :)
• Donate.
• Create a page on Wikipedia about our Castle Game Engine and/or view3dscene. Maybe only a page about view3dscene for starters?

For 3D worlds creators: if you use our tools to create or browse your 3D worlds, you can:

• Show off your works on our forum, in any way you like (screenshot, link to model, youtube video etc.). If you use some of our engine special VRML/X3D extensions or rendering features, you are strongly encouraged to do so (Michalis loves to see how his work is useful for others :) ! But also post about "normal" 3D models that simply look nice in our view3dscene or such.

• Contribute models to our demo models.

• Look into improving our documentation. Our VRML / X3D documentation is large, and always wants to be larger. Contributions describing how something works, or how to do something practical, are welcome.

  You can add your contributions directly to our wiki. (Once we'll get some user content in our wiki, we'll think how to make it more visible.)

• Test the nightly builds of our binaries. These are build automatically every night using current SVN code. You can test them and catch eventual bugs before the release. This way you can also preview new features before they are released.

  Bugs can be reported on the forum or in the tickets tracker.

For ObjectPascal (FPC, Lazarus) developers:

• Use our engine to make your next game, of course! :) And make it great :)

• Many areas of the engine could use the help of an interested developer. If you'd like to join, or just send some patches improving something, feel welcome to post to our forum.

  Some larger ideas for development:

  • Native look and feel, and easy installation, under Mac OS X

    Currently, our programs (view3dscene, all games etc.) look a little out of place on Mac OS X, as we use GTK. They are also not easy to install (as we require user to manually install X server, and some stuff from fink, first). This feature is to implement nice Cocoa interface, that will look and work natively on Mac OS X, and will also remove the need to install anything through fink. The details how I imagine this implemented are here.

  • Support Material.mirror field for OpenGL rendering

    An easy way to make planar (on flat surfaces) mirrors. Just set Material.mirror field to something > 0 (setting it to 1.0 means it's a perfect mirror, setting it to 0.5 means that half of the visible color is coming from the mirrored image, and half from normal material color).

    Disadvantages: This will require an additional rendering pass for such shape (so expect some slowdown for really large scenes). Also your shape will have to be mostly planar (we will derive a single plane equation by looking at your vertexes).

    Advantages: The resulting mirror image looks perfect (there's no texture pixelation or anything), as the mirror is actually just a specially rendered view of a scene. The mirror always shows the current scene (there are no problems with dynamic scenes, as mirror is rendered each time).

    This will be some counterpart to current way of making mirrors by RenderedTexture (on flat surfaces) or GeneratedCubeMap (on curvy surfaces).

  • Basic networking support

    Basic integration with network: ability to load resources from http, and hopefully https, protocols. Probably will be implemented using lnet, or synapse (nice intro also on FPC wiki), or maybe some other library. It will be pluggable, so programmers of new games using our engine can even turn it off completeley (like when you make local games, and don't want a burden of linking with a networking library). For this basic support I don't promise a background downloading --- which means that you may have to wait for download to finish, or interrupt it. But you will not be able to interact with 3D world while a download is taking place. (Background downloading will of course be added one day too, but that's a larger feature that I want to deal with separately.)

  • Scripting in JavaScript

    Allow to use JavaScript (ECMAScript) directly inside VRML/X3D files (in Script nodes). This will follow VRML/X3D specification. Implementation will be through besen (preferably, if it will work well enough), SpiderMonkey, or maybe some other JS library.

  • Physics integration

    Integrate our engine with a physics engine. Most probably Bullet, which will require proper translation of Bullet API to C and then to FPC (as Buller is in C++, it's not readily usable from anything other than C++). Eventually ODE. Allow to easily use it in new games for programmers. Allow to use it in VRML/X3D models by following the X3D "Rigid body physics" component.

• Contribute to our wiki useful tips or tutorials about using our engine.

• Help to port our CastleWindow unit to Cocoa (Mac OS X). This is an easy and rewarding task for a developer interested in Mac OS X, it will make our programs look more native and friendly on Mac OS X.

For Blender experts:

• I think that success of our engine is tightly coupled with the quality of Blender X3D exporter. Of course, you can use anything to generate VRML/X3D for use with our engine. But if you make FOSS game, you have probably already chosen Blender as your main 3D modeller.

  Blender is really fantastic. But the current exporter from Blender to X3D lacks some important features. For starters, there isn't any way to export animation to X3D. At least exporting animation of transformations (translation, rotation, scale of objects) would already be very useful. Exporting mesh deformation (from shape keys, or derived from bone animation) would be great. There are also various other small lacks. Many features of VRML/X3D and our engine are not used intensively enough, because there isn't any way to express them and export from Blender.

  We have our own customized Blender X3D exporter, so you can start from this. Preferably, changes should be reported and applied to the Blender sources. Only stuff really specific to our engine (cooperation between Blender and some specific features of our engine) should be left inside our custom exporter.

For Linux distros package maintainers::

• Please package view3dscene for your favourite Linux distribution :) It's a great and stable VRML/X3D browser (and viewer for other 3D models, like Collada and 3DS). Some facts in favor of view3dscene, important for package maintainers:

  • Stable program, with long development history and regular releases.
  • Desktop integration files (SVG icon, .desktop file, MIME xml) are already included in our archive.
  • The dependencies of view3dscene are documented. There's nothing weird there (ffmpeg and ImageMagick are only light suggestions; OpenAL may also be a suggestion instead of a recommendation; the rest is standard for any GTK program using OpenGL).
  • Build-dependencies of view3dscene include Free Pascal Compiler, but this should not be a problem — all major distros already have fpc packaged.
  • Complete sources of view3dscene are here, get both view3dscene and engine sources, and unpack them to make view3dscene and castle_game_engine siblings.
  • The whole thing is GPL >= 2 (most of the engine may also be used under more permissive "LGPL with static-linking exception" >= 2, but this probably doesn't matter here).

  Michalis uses Debian, and sometimes Ubuntu, and would love to see his software available in your repositories :)