Alternatively, if you prefer to send questions through email, you can subscribe and post to our castle-engine-main mailing list.
If you really want to contact the author directly, send email to Michalis Kamburelis.
If you'd like to help in the development of our engine, here are some proposed tasks:
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.
Use our engine to make your next game, of course! :) And make it great :)
Contribute to our wiki useful tips or tutorials about using our engine.
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, please contact us, for example through forum.
Below are some ideas for development. Some of them are not trivial, although they may be easy if you have an expertise in a particular area (or you're willing to gain such expertise :) This list isn't exhaustive of course, there are many things we want to achieve, and you most likely have even more ideas of your own. If you don't have time to work on them, but you badly need them, consider also donating to a particular goal.
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.
WWW browser plugin
Most probably using NPAPI, the cross-browser API for plugins. Our CastleWindow code will become handy for this, as it can deal with WinAPI / XWindows window handle (this is what we get from plugin to initialize our plugin viewport).
Use Cocoa under Mac OS X
We already have a native look and feel, and easy installation, under Mac OS X, see relevant news and docs for Mac OS X situation in SVN. Our programs no longer have to use X11 and GTK under Mac OS X. Still, current solution is not optimal: we use LCL with Carbon under the hood. Carbon is deprecated and only 32-bit (Cocoa should be used instead), and depending on LCL has it's own problems (mouse look is not smooth with LCL message loop).
The proposed task is to implement nice Cocoa backend
CastleWindow unit. Contributions are welcome.
This is an easy and rewarding task for a developer interested in Mac OS X.
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).
Advanced networking support
Basic networiking support is done already, we use FpHttpClient unit distributed with FPC, see relevant news entry. Things working: almost everything handles URLs, we support
https. By sending patches to add it to
FpHttpClient. Or by using LNet or Synapse (they both include https
ftp. By using LNet or Synapse, unless
something ready in FPC appears in the meantime.
Both LNet (through LFtp unit) and Synapse (FtpGetFile) support ftp.
Support for HTTP basic authentication. This can be done in our CastleDownload unit. Although it would be cleaner to implement it at FpHttpClient level, see this proposal. Or maybe just use LNet or Synapse, I'm sure they have some support for it.
Ability to cancel the ongoing download. Add a "cancel" button to CastleWindowProgress for this. See the task below (background downloading) for ideas how to do it.
Ability to download resources in the background, while the game is running. Technically this is connected to the previous point: being able to reliably cancel the download.
There is a question how to do it.
We can use
TThread for downloads,
maybe even a couple of threads each for a separate download.
We can use API that doesn't block (like LNet or Sockets,
with Timeout > 0).
We can do both.
Using separate thread(s) for download seems like a good idea, the synchronization is not difficult as the thread needs only to report when it finished work.
The difficult part is reliably breaking the download.
Using something like
TThread.Terminate will not do anything
good while the thread is hanging waiting for socket data
TThread.Terminate is a graceful way to close the thread,
it only works as often as the thread explicitly checks
TThread.Terminated). Hacks like
are 1. OS-specific 2. very dirty,
TThread.Execute has no change to release allocated memory
The bottom line: merely using TThread does not give
you a reliable and clean way to break the thread execution at any time.
This suggests that you have to use non-blocking
API (so LNet or Sockets is the way to go,
FpHttpClient and Synapse are useless for this)
if you want to reliably break the download.
Using it inside a separate thread may still be a good idea,
to not hang the main event loop to process downloaded data.
So the correct answer seems use LNet/Sockets (not
FpHttpClient/Synapse), with non-blocking API, within a TThread;
thanks to non-blocking API you can guarantee checking
TThread.Terminated at regular intervals.
I'm no expert in threads and networking, so if anyone has any comments about this (including just comfirming my analysis) please let me (Michalis) know :)
Caching on disk of downloaded data. Just like WWW browsers, we should be able to cache resources downloaded from the Internet.
Note: don't worry about caching in memory, we have this already, for all URLs (local files, data URIs, network resources).
I'm sure you can find other ideas for development. Is there something you miss from our game engine? Is there a particular feature you miss from 3D formats (X3D, Collada etc.) support? Some useful tool, or maybe a useful example?
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.
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: