Castle Game Engine news: Development: transitionComplete, Debian packages, network tutorial, data URI, MultiTexture tests, more

Various new features developed for next Castle Game Engine and view3dscene:

1. NavigationInfo.transitionComplete support. Demo model transition_multiple_viewpoints.x3dv shows how to use it to make an animated transition between a couple of viewpoints.

2. Thanks to Abou Al Montacir we will have packages with Castle Game Engine and view3dscene in Debian! Most of this software was developed by Michalis using Debian, so having my software in the Debian repository would feel really great for me :) See here for our forum thread, and here is the Debian bug marking ITP (Intent To Package) for engine: #706408 and for view3dscene: #707932.

3. For developers, new chapter of our tutorial describing network support is available.

4. Engine examples contain a simple tool examples/tools/to_data_uri.lpr that can generate data URI (to embed your texture, audio, model, etc. inside a VRML/X3D model, or a webpage, or other documents) from any file. It gets the file and guesses MIME type using our existing CastleDownload unit, so it supports local files as well as http links, and MIME type is retrieved from server or guessed based on file extension.

   There is a demo data_uri.x3dv showing how you can use data URI to embed all kinds of things inside X3D file: textures, sounds, other 3D models (to Inline or Anchor to them), scripts etc.

5. MultiTexture.function support (forces shader pipeline rendering for given shape; there's no way to reasonably implement this using fixed-function pipeline). Demo in functions.x3dv.

6. A set of X3D multi-texturing tests is available, testing support of view3dscene and other VRML / X3D browsers for multi-texture features. This is part of my ongoing effort to improve X3D MultiTexturing specification.

7. There is a progress bar showing the process the downloading. The download is still blocking, but at least now you see what's going on :)

8. If you load or save image sequences using the syntax image%d.png, for example inside our extension Movies for MovieTexture can be loaded from images sequence: the new syntax to indicate counter inside the URL will be @counter(4), where 4 is the padding. For example image%d.png has to be changed to image@counter(1).png and image%4d.png has to be changed to image@counter(4).png.

   For loading, you will have to use new syntax with @counter(<padding>) with new view3dscene / Castle Game Engine versions. You will have to update your VRML/X3D models, old syntax will unfortunately not work anymore (reasons below). For saving, the old syntax %d will continue to work for some time (along the new @counter(<padding>) syntax, and you're encouraged to upgrade to new syntax).

   The reason for this is that MovieTexture.url is now correctly treated as an URL, and this means that percent character % needs to be escaped to %25. Inside URL the sequence %4d has to mean letter M (ASCII code 77, which is 4d in hexadecimal). So there is unfortunately no way to avoid breaking compatibility — we want to correctly support URLs, which implies that %4d must be interpreted as letter "M", not as a magic counter.

   Looking back, it was an unfortunate choice to use percent character to indicate images sequence, since percent is special inside URIs. It was done for consistency with ffmpeg, that supports things like image%4d.png on the command-line (but not when using URLs; for example, ffplay /home/image%4d.png works, but ffplay file:///home/image%4d.png does not work, neither does ffplay file:///home/image%254d.png). So, one can say that it was ffmpeg that made a bad choice, but then ffmpeg did it for consistency with common string formatting functions (C sprintf, ObjectPascal Format)...

   Comments about this change are of course welcome, through forum or any other means. Right now, I just don't see a way to avoid breaking compatibility. We made a bad decision to use %d to indicate image sequence, and it has to change in order to correctly support URL encoding in new versions.

9. A couple of bugfixes. Including bugfix to a quite horrible mistake in ShaderPart node, in some circumstances the shader code would be reloaded from file at every frame, causing a horrible slowdown. It's fixed now of course.