ForumAsk for help, report bugs, discuss features

You can post on the forum without registering.
You can also login to your SourceForge
account, and then you are already considered "logged in" on this forum too.
Any questions related to our VRML/X3D engine and related programs (like
view3dscene or castle) are welcome. Create a new topic, and go!

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.

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.

3. For ObjectPascal developers

3.1. Proposed (larger) development tasks

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.

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.

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
in 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).

Things missing are listed below (some of them may done by adding
integration with LNet or
Synapse, see also nice
intro to Synapse on FPC wiki).

Support for https. By sending patches to add it to
FpHttpClient. Or by using LNet or Synapse (they both include https
support).

Support for 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 Windows.TerminateThread
are 1. OS-specific 2. very dirty,
as TThread.Execute has no change to release allocated memory
and such.
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 :)

Support X3D LoadSensor node.

Caching on disk of downloaded data.
Just like WWW browsers, we should be able to cache
resources downloaded from the Internet.

Store each resource under a filename in cache directory.

Add a function like ApplicationCache, similar existing ApplicationData
and ApplicationConfig, to detect cache directory.
For starters, it can be ApplicationConfig (it cannot be
ApplicationData, as ApplicationData may be read-only).
Long-term, it should be something else (using the same
directory as for config files may not be adviced,
e.g. to allow users to backup config without backuping cache).
See standards suitable for each OS (for Linux, and generally Unix
(but not Mac OS X) see basedir-spec;
specific Microsoft, Apple specs may be available
for Windows and Mac OS X).

Probably it's best to store a resource under a filename
calculated by MD5 hash on the URL.

For starters, you can just make the max cache life
a configurable variable for user.
Long-term: Like WWW browsers, we should honor various HTTP headers that
say when/how long cache can be considered valid,
when we should at least check with server if something changed,
when we should just reload the file every time.

Regardless of above, a way to reload file forcibly disregarding
the cache should be available (like Ctrl+Shift+R in WWW browsers).

A setting to control max cache size on disk, with some reasonable
default (look at WWW browsers default settings) should be available.

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?

4. 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.

5. 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:

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.