Raydium 3D Game Engine

Here the patchs:

text part: http://www.sendspace.com/file/9vjchw
binary part: http://www.sendspace.com/file/tvsout

Instructions: First patch with the text patch as usual (patch -p0 <filename) . Then overwrite the raydium root folder with the folders zipped in the binary.
Important to have installed cal3d system wide.(sudo apt-get install libcal3d-dev)

after that

and now you can test with:
./odyncomp.sh anim-test1.c
./odyncomp.sh anim-viewer.c paladin.cfg
./odyncomp.sh anim-viewer.c cally.cfg
./odyncomp.sh anim-viewer.c freebeast.cfg
./odyncomp.sh anim-viewer.c geisha.cfg
./odyncomp.sh anim-viewer.c hero.cfg
./odyncomp.sh anim-viewer.c trooper.cfg

I've tested these patches over a new checkout of raydium and works, so it (should) works for everyone...I hope.

FAQ:
Why are the animations in data/anims instead of raydium root folder?
Cause each animated character is composed of a variable (But sometimes huge) number of files. The 6 characters of the demos are using more than 120 files. Putting all those files in raydium root would be a bad idea. Complex models can have easily more than 200 files.

What are the cfg files?
Cal3D is a format file compound of various different files. But the way for loading all those files is "free". For such reason exist the cfg files, for telling the engine (Raydium in this case) which files has to load.

Differences betwen model and instance?
The model is like a template of an animated character. However we can NOT use this template directly in our application. We must create an instance of the model and that instance will be that one that we can render, locate, rotate...
Also, from an unique model we can have a lot of instances (for example 6 enemy guys in screen would be 6 instances of just 1 model).

Is the doc completed?
doc are not fully finished, but even in thiw way it can be used as is. Also I want to do a videotutorial about how to make an animated character soon.

Is there an Cal3D exporter for Blender?
Yes. It was hard to find but you can find one in contrib/cal3d-exporter. The content of that folder (without the .svn) has to be copied to the blender plugins folder. However a few rules have to be followed to have a working model in raydium.

Why Cally has a blue leg?
No idea...

Hero model is not moving
Yes, he was just an exporting test, but as he looks fine I let it as example.

The spider is rotated
Yep, it was exported in that way... maybe we can fix it, if we locate the original file.

Known problems?
Not by itself, but yes when we want to commit into raydium. The current R3S system only can send files to the radyium root folder, but we need the animation files in data/anims/. Even more, an per-extension approach won't work cause the anims folders can have textures and other kind of files. Solutions?

Chronicles of making a "simple" patch...
Making the patch was a hell...
svn diff didn't worked cause of binary files. In SVN IRc chat, the people confirmed that SVN can't suport binary diff and all the alternatives were unusable. Finally they suggested me to change the format of our revision server to GIT, instead of SVN. Again that was useless (I can not change that, obviously).
Finally I had to zip all the folders with binaries and I've deleted a few things manually, but there are repeated things...and the process of deleting inside a zipped file is damn slowwww.
We have to find another way to do this kind of things (with binaries involved).

Oooooooooo ! Sounds very interesting !
I was "lock up" in my alpha tested rendering thing and I didn't had the time to test this patch. I'll be right on it tomorrow morning ! No, wait, morning does not exists when you're on holiday

PS: You're right on SVN and binaries. I think we've already talk about this issue a while ago ... no binaries are allowed in Raydium SVN ! The trouble here is that R3S does not seems to fit ... (binaries "deployment" is supposed to be its job). There's an improvement area on this point ! I'll think about that.

Added to my previous message.

Just trying to audit the patch, but this thing is huge ! There's a mix of data and code ...
When I was talking about a patch, I was talking about a regular svn diff:
- You've modified existing files in Raydium -> in the diff
- You've added new code files in engine, and added demos -> in the diff
- Changes to the Makefile, ... -> in the diff
- contrib script -> in the diff
- in facts, all things that should be in the commit are supposed to be in the diff

... but why data in the diff ?! It explains why it was so hard for you to create this patch, I think
- data/anims/freebeast/beastm.xmf
- data/anims/geisha/geisha.xsf
- data/anims/geisha/License.txt
- data/anims/paladin/paladin.cfg
- ...

I really think that it's easy to create such a patch.
- 1: modify all files you're supposed to modify
- 2: "svn add" new code files (if any)
- 3: svn diff > xxxx.patch
- 4: create an archive of your data directory (what did you deleted ?)
- 5: that's it !

Other subject: I'm thinking about a "packaging system" for Raydium that would allow to use archives to pack a big number of data files. In this example, we could use an archive per animated model, or even a big "anim-demo" package with all models. I'll try to create a prototype very soon, I think it can solve the issue with anims, R3S, data/anim, ...

New patch supporting packages (this time done in the boring/working way)

patch: http://www.sendspace.com/file/z99g5t
data: http://www.sendspace.com/file/i0w0eq

As usual, first apply the patch and then extract the data zip. All has to be done in the raydium folder.

Comments?

About cal3D I've noticed (in the chat) some people are having problem to get the sources, configuring them, etc. Maybe it could be possible to us to include cal3d sources in raydium... just an idea. Or even a libs folder interactively filled with configure flags.

I'll test that ASAP, but about your last point, we could perhaps use the same idea than for ODE and PHP: hosting a "stable" release of the library (source) on our servers, and downloading/configuring/compiling it from the configure script ? It's not the easiest way for us, but it could work.

But which distribution does not provided cal3D "by default" ?
Here, Mandriva 2009.1 i586, libcal3d-devel is provided with version 0.11.0 (as a contrib)

The minimum for Linux configure script is to test libcal3d, by the way. We'll see this later.

WOW! This is huge!

I followed your instructions applying the patch. Works great as is without any extra modification!
That's probably, because we've made some tests before, used Cal3D already in Raydium World and that the library is already available for every architecture in the Raydium Apple SDKs since some time now.

The FAQ are very useful for me, the only thing I'm missing is how to prepare and make the animation part of my models. I've a question regarding this topic.
I've modeled a low poly mesh, it's finished including texturing. I've the official english Blender 2.3 Guide as a book, which is now also readable online I think. Do I can follow this Blender 3D animation chapter in general to export to Cal3D later on? Or do I have to care to something special Cal3D related, so I don't really want to make the animation part twice.

I really like to write that the Cal3D patch is completely Apple ready, so it is ready in general indeed, but I've discovered a problem on the finalization progress of the engine.
It seems that it only happens when using the Paladin model. I can use every model except Paladin without crashing at program termination. Running anim-test1.c, it crashes at the very end of the process, because it uses Paladin. Using anim-viewer.c works with every model without any trouble, but crashes after quitting the application when Paladin was used. This behavior is reproducible every time when Paladin was loaded. I start the animation viewer with the paladin.cfg param, it will load everything, I don't touch anything, then the only thing is closing the app. => Crash.
To avoid misunderstandings: Everything works as expected while running and using the apps, also with Paladin, every app is shutting down normally using every model except Paladin.
I'll try to figure out what's going on here, starting a debugging session, but I remember that on previous tests, also written about here on the forum, no problems occurred using the Paladin model.
Has Paladin something special? Perhaps a trouble with the new ZIP archives support? Any suggestion?

Yes, paladin is the unique character with LOD applied. LOD(leve of detail) allows the application to use 100% of the polygons of the model or less according, commonly, to the distance of the camera.
I'll do more test about this, but I was aware about using LOD is still buggy.

Also I'm preparing 2 videotutorials. The first is about creating a quite simple model.
The second will be for creating improved animations.

Not really sure where to post this, since Cal3D support is not officially committed I'll post it here.

I've searched the net for an already finished 3D model, which is Cal3D proven, where I can look at inside Blender to learn from for my own models. I've found one, which is the main character in a game, which uses also Cal3D. I got the stuff together from their SCM and zipped the Blender 3D and GIMP files, together with a Targa image file, which I've created from the GIMP file, in an archive called balazar_resources.zip.

The problem is that the Cal3D exporter included in the Raydium Cal3D patch doesn't work for me.
I tried two different official builds of Blender 3D, version 2.43, which I've installed, because it only works with the old Raydium TRI exporter for me (never got the new "full" TRI exporter to work right now) and version 2.48.
I opened the balazar.blend and press the File->Export->Raydium/Cal3D item in the menu. Result looks like:

Checking the console shows me the following:
Which Blender 3D version do you use to export your work to the Cal3D format? Are you able to export Balazar to the Cal3D format?

- EDIT -
I've tried to comment that line, but there are a lot more errors, seems they are all beginning with the "@".

By one side cal3d exporting is quiiiiite buggy...
Also balazar is not 100% cal3d standar model. It's prepared for soya-cal3d, that's not equal to simple cal3d. Maybe the names, the structure or something is different.
The cal3d support on internet is almost null, so is really hard to get a tutorial or notes about how to prepare a model. I'm trying to do by try-error method.

Here a model I'm using for my tests:
http://www.sendspace.com/file/ax0v9j
The model has 3 working actions
Using the exporter should create an standard cal3d working character.
My own rule is to create a folder with the name of the char and put there all the files created EXCEPT the .cfg one.
Then edit the cfg one and, at the top, add a line like

also you can force an scale with

Remember, the path line has to be at top, to be loaded before the rest.

By other side, the version of blender I'm using is 2.49a (2.43 and 2.48 are distro stable versions but not the current ones).

edited:
This file could be the resulting of export that (plus a few tweaks: texture and cfg changed)
http://www.sendspace.com/file/r11vx8

edited 2:
I've exported the balazar character from the resorce file you posted:
http://www.sendspace.com/file/1n2q89

Thanks for your help!

I've solved the problem with the Cal3D export script by simply updating to the newest Blender version available, which includes Python 2.5, the older version of Python was the problem exactly. I'd already installed Python v2.5.1 on my system, but Blender is shipped with its own version.

Balazar was also successfully exported by myself, your way of creating an additional folder for the files is very useful, but it is possible to use the exported files without accessing folders at all (and makes everything chaos).

About the Raydium TRI import and the old export scripts I can say, that I've successfully imported and exported a TRI. Previously, with Blender v2.48 I had a problem, the sizes/scale was not correct, probably a Blender related behavior, because importing a TRI file to a blank scene and exporting it with the same sizes/scale was not possible for me. But with the new Blender version everything has been changed.

The segmentation fault issue makes me crazy, I cannot figure out why it is crashing at the very end of the process (of course some bad memory access issue I guess). Do you have this problem yourself or is it only me?

You're right the paladin model exits leaving a nice "segfault" also in Linux.
For sure its related with the LOD system, but I can not guess more until a depth search.

First review of you patch (sorry, I'm a bit late):

About the code itself:

1) indentation ... ;)

2) void raydium_anim_instances_destroy()
- missing void argument
- name should preferably be something like raydium_anim_instance_destroy_all(), I think

3) Non standard variable declaration ("code before data"), seen in raydium_anim_cal3d_instance_render_mesh() for instance.

4) Is there any way to get rid of all the hardcoded "data/anim" path ? Is it still needed with the package system ?

5) Parsing of .cfg file is not error proof (like you did for the autoconfig system): you should at least test data types. "mesh={1.0,2.0,3.0};" does not generate a parsing error. It makes me think about the usability of the parsing API ... perhaps should I add a simple layer. Anyway, a simple test on raydium_parser_read() returned value (RAYDIUM_PARSER_TYPE_STRING for strings) will do the trick. It would also be cleaner if CFG files were using double quotes for strings.

6) way too much debug traces during loading ! No more debugging in a almost-final-version, a single line with a very few infos would be enough.

7) Perhaps can we remove the "EXPERIMENTAL: DONT USE!" in docs ? A single "beta" warning in the header may be sufficient ? And a complete doc ... :)

8) You should use RAYDIUM_ANIM_RENDER_* defines in demos. Most people will probably use this as a reference, it should use the anim API at its best.

9) Should we add an "obsolete code" warning for MD2 support ? And perhaps remove the current demo for this feature, it may confuse users ...

10) compilation warnings with demos. Also many typos (anim.viewer.c, instancde, ...)

11) anim-viewer.c is including packages by itself ... we must find another way (the user may provide its own package with its own model, of course)

About the API:
- raydium_anim_models_destroy(): automatic instances removal seems is a must. We can't ask this to the user, IMHO.
- noob question: why meshes and materials are not automatically applied ?
- I don't understand raydium_anim_loop_clear() ... why called so many times in demos ? is the viewer really generic ?
- ... and let's be honest, I've hard time to understand the API. Missing docs is perhaps the main reason, but I think we should try to make things more simple ... Am I wrong ?

Last thing: Great job vicente, we're on the way to a proper animation system ! Probably the most awaited feature of Raydium :)

Hello guys, Im experimenting with cal3D on this 2 weeks. Here is what I got so far.


Maybe I can be some of help.

little update about the animation system:

• Currently the animation system can load zip files(thanks to the package system). Also all "data/anim" hardcodes have disappeared.
  
• Simplified loading system.
  
  Code:
  model=raydium_anim_model_load("geisha");
  instance=raydium_anim_instance_new(model);
  
  Note:As package system uses only zip files, the summoned filename has NO EXTENSION. (Is there a simple code to remove safely the extension of the package filename?)
  
• A lot of debug output has been removed.
  
• And more things.

I hope to do a new patch quite soon.

One more thing: Farabi, Could you send me your test model? I'd like to make tests with "external" models. Thanks

Cool cool cool cool

About the extension, I'm not sure to understand the point. You would like to use a specific extension for models ? The package system does not work when you provide anything else than a ".zip" file ? (never tested this)