Raydium 3D Game Engine

I'm just playing around with Raydium a little bit, following the tutorial and going through some of the API, and I've run into 2 small problems. I'm using an SVN version from yesterday on GNU/Linux.

- The first thing are the coordinates in some functions. Are they supposed to match up with coordinates from Blender? In the function raydium_camera_look_at, the first set of coordinates match up fine, but the second set don't. I'm having to use them in this order:

(camx, camy, camz, camy, -camz, camx)

Is that normal or do I have something messed up?

- The second small problem I'm having is with exporting from Blender. I had one object that was about 100 units in blender long, and that was fine in Raydium, but another object that was only about 0.05 units long was about 10 times larger than it should be.

Checking the tri mesh for the small object shows it is being exported too big. I also tried making the larger mesh even bigger, but it seemed to be about 10 times smaller than it should have been. Is there a certain maximum or minimum size for meshes, or something else I could be messing up during export? I can post the blend and tri files too if needed.

Sorry for this long post in English. Time for me to play some more ManiaDrive, thanks

Hi,

Raydium worlds use Z as height. The case of raydium_camera_look_at() is very particular, since second set of coordinates use "another hand". This was needed for historical reasons, and we should probably provide a small wrapper for all "look_at" camera function, but all other function use standard z-height coord system.

About Blender, you must know that the export script only deals with vertices, not objetcs. It means that you must do every rotation / sizing / move operation in vertices mode, not in object mode. You can also use the "Transform -> Clear/Apply -> Apply Size/Rotation" menu, or join you objets before the export so they can share the same properties. Hope that helps

Ah, that was pretty stupid of me. I was doing exactly that, scaling in object mode. Works great now, thanks again.

Hi again,

Is there anyway to use repeated textures? I'm basically working on a little golf game, and I need more detail on the ground than I'm getting with a single tga. Is there a simple method to use a tileable texture in this way? Or would I need to use some opengl functions? I might be missing something in the documentation about it, but I couldn't find anything yet.

Sorry about double posting, thanks.

You think about something like multitexturing ? Have a look to "cocorobix.tri" file if you want to see avery simple example of one-pass detail texturing (repetition factor is RAYDIUM_RENDER_MULTITEX_AUTO_UV_FACT, in common.h). It's done using a texture name built like this : t_circuit-2f.tga;ground.tga

If you want a more powerfull control over multitexturing, you can use another method : UV mapped detail texture. Have a look to "cinemal.tri" (to all: I've just uploaded this new file ). It use multitexturing for lightmaps, but you can use the same idea for detail texture. It looks like : wood2.tga;0.267053|0.801024|cinemal.tri.1.tga
As you can see, there's U and V value for the second texture (cinema.tri.1.tga). For your world, you can use much highers (10 ? 50 ? 100 ?) values so that this second texture repeats all over the triangle.

Did it helps you ?

WARNING : most import/export scripts are unable to deal with multitexturing. You better use a search/replace method or script to apply detail textures to your "worlds" just after exporting.

Ah, that's a nice simple way to handle. I should have looked at the tutorial more closely. Anyways, I'm going to go with the one pass method for now. I'm just using awk to edit the tri file:



Then delete tex1.tga:tex2.tga from the top line.

I'm really enjoying working with Raydium, thanks again.

Nice to hear that

Hi, I'm stuck once again.

I'm trying to figure out how I should handle having different types of ground. I'd like to have different textures on different parts, as well as a different coefficient of rolling friction. So for example on the litle golf thing I'm working on, I would have a fairway part that rolls easy compared to the rough on the side, and they would have different textures as well.

Is there a way to set the ground to multiple meshes to handle the different textures? If I could do that, I'm still not sure how I would detect which part of the ground it's colliding with to set the rolling friction.

I'm just not sure how to approach this problem.

Thanks

mike, i would use a memory loaded bitmap(that should represent the whole field in a top view) with different colors according the friction of the terrain. And then, each time the physic has to be calculated, i would change the friction of the WHOLE terrain according the friction of that point in the map.
With only one ball, i think, is the easier solution.

Maybe the map could the grey-scaled. So a 0,0,0 value could be a 0 friction and a 255,255,255 value could be a "infinite" friction or your maximun friction value...

Yeah, there's no trick, here A work was started to support "ground triangle detection" wich was supposed to report all "touched" triangles for a specified element (see raydium_ode_ground_dTriArrayCallback() in ode.c) but ODE was not able to support this yet. From what I've read from the ODE ML, it seems that release 0.6 now provides such support. We should probably try to upgrade to this version, now (and complete the TriCallback system)

If anyone wants to try ... !

Ah ok, thanks guys. That sounds like a good idea vincente, I think I'll that a try. If I have trouble with that, I'll settle for the same friction everywhere for now.

I've just think to another possible answer, with bounding boxes. ManiaDrive use such system for checkpoints, boosts and start/finish. It can work if your different friction zones can fit into rectangular areas.

The idea is to create standard "physic boxes" without meshes, and to avoid collisions of other elements with theses boxes, so you can detect if your ball (or whatever) enters this area and then change its friction.