Tagged: Ogre3D Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 23:31 on 2016-11-27 Permalink | Reply
    Tags: , Ogre3D,   


    Today, visually, it is ULTRA minimal.

    The two dots are 2 sound objects. The left one is muted and is related to pobject_3_object messages in the pd patch. The right one is on and is related to pobject_6_object messages in the pd patch.

    In human language, this means that the 3d objects are directly connected to the sound engine. For instance, when the right dot moves, it sends a message named “moved” to the sound. In this case, the message triggers a short sound.

    For developpers:

    • main class for sound objects: PSound
    • interface between Ogre thread and Puredata thread: PdSource

    Soon with more!

  • frankiezafe 17:05 on 2016-11-19 Permalink | Reply
    Tags: , , , Ogre3D   

    Polymorph package is on its way!

    Until today, polymorph was a collection of Ogre addons, independent from each other. The approach has changed a lot during the development of Tuning score. All extra libraries are now linked into one big package:

    • Bullet – physical engine;
    • libPD – sound engine;
    • OSC – Open Sound Control messages, based on udp;
    • tinyXML – for project loading;
    • SDL – for gamepad and joysticks.

    The package uses a project file format, in XML + provides high-level objects and a base class containing all mandatory methods to manage a game:

    • scene & resources loading;
    • window management and events;
    • keyboard and mouse events.

    A large documentation has to be written, but programming architecture is now fixed.

  • frankiezafe 19:12 on 2016-10-10 Permalink | Reply
    Tags: , Ogre3D,   

    Precise object grabbing, require a bit of math, but it worst the headache!







  • frankiezafe 17:22 on 2016-10-06 Permalink | Reply
    Tags: , , Ogre3D   

    Demo with of a chain using bullet:



    Meshes (displayable and physical) are desgned in #blender by @louise !



  • frankiezafe 14:55 on 2016-10-06 Permalink | Reply
    Tags: , , Ogre3D   

    All bullet’s primitives are now available:

    • btBoxShape;
    • btSphereShape;
    • btCapsuleShape;
    • btCylinderShape;
    • & btConeShape.

    The link with blender is make easier via 2 python scripts ( see Two python scripts… ).

    A default fallback to convex hulls still has to be done.


  • frankiezafe 18:18 on 2016-10-01 Permalink | Reply
    Tags: , Ogre3D,   

    Bullet’s compound shapes wrapper for ogre.

    A tutorial on how to prepare your meshes is being written and will soon be completed > https://bitbucket.org/polymorphteam/pe.2.0/wiki/bullet-compound



  • xuv 22:12 on 2016-09-30 Permalink | Reply
    Tags: , Kimai, Ogre3D,   

    Polymorph weekly news #8 

    Bullet schema

    This will take only 5 minutes.

    This is what @frankiezafe and I told each other when starting our weekly meeting about the Polymorph.

    Time, whether it’s a good way to evaluate a human activity or not, is always going to be used as a reference. How much time did you spend on this? How long will it take to release a first video game? How much more time do you need to finish implementing Bullet? Do you have 5 minutes to share this article with your friends or read this weekly news? (which by now you have figured out is not even weekly).

    With computers it seems, we’re all quickly loosing track of time. Whatever the machine is doing to us, it is sucking it at an incredible pace. And EVERYONE in the business knows it. Let me quote a discussion between Ton Roosendaal and Bart Veldhuizen about development time:

    Our meeting, with the excuse of this post, took almost 2 hours. Of course we talked about other things than Polymorph. Of course this always happens between us two. But in an open structure like Polymorph, on an open source project like PEEL or the Polymorph Engine, how do you track the amount of work being done?

    Well, it’s not really a little secret, but within Polymorph, participants are encouraged to log the hours they spend on each project using Kimai. It’s certainly not the best way, but it’s not a bad way either. It’s also mostly a tool for oneself to figure out how much time we’ve spend on something. And believe it or not but @frankiezafe has already spend 350 hours developing the Polymorph Engine. Not bad if you ask me. This is over the course of the last 3 months, full time, or close.

    The Polymorph Engine is not finished yet, of course. But François is happy the way it advances. It will help build games faster in the future, as the most common operations for building a game will be immediately available, without hiding the complex process underneath it.

    For the technical minded in the audience, François is still working on adding Bullet to Ogre. The illustration of this artcile is from Bullet’s documentation, which François has praised as the best documentation he’s seen so far. Bullet (a physics engine) will be useful for both PEEL and for Tuning Scores. In PEEL, it will help to avoid collisions and discard impossible moves in the puzzle, while in Tuning Scores, the whole game play is based on the physical properties of the objects in the virtual world.

    This news took me 53 minutes to write. I better close now. I still have to post it on Twitter, Facebook and Diaspora*. You’d be so kind to give us a minute too and share it with your friends.


    • frankiezafe 19:44 on 2016-10-01 Permalink | Reply

      a programmer’s day lasts around 30 minutes, from 9am to 8pm for the rest of the world…

      • xuv 20:49 on 2016-10-02 Permalink | Reply

        Nope, it’s the other way around. A programmer’s day lasts 2 weeks for the rest of the world.
        Because if a programmer tells you that he can do something in a day, come back in 2 weeks for actual delivery.

  • frankiezafe 19:52 on 2016-09-24 Permalink | Reply
    Tags: , , Ogre3D, ,   

    Demo of physics in polymorph engine.

    A lot of stuff has been fixed since yesterday, but severe improvments are still to be done.

    In the video, only convex hulls and simple colliders (cubes & spheres) are used.

    To add a custom collider on a PNode, you call:

    pnode.load( sceneManager, “General”, “my-high-resolution.mesh” );
    pnode.physics( polymorph::BT_DYNAMIC_CONVEX, “General”, “my-low-resolution.mesh” );

    “my-low-resolution.mesh” will be used to calculate physics.

    Using convex is a problem for the blue thingies: the torus is not empty, but convered by an invisible “skin”. Therefore, other objects can not go through this huge hole… The issue should be solved by using the btGImpactMeshShape, but the shapes are behaving strangly when enabled. They jumps all the time…

  • frankiezafe 20:06 on 2016-09-18 Permalink | Reply
    Tags: , Ogre3D, , spacialisation,   

    Sound source linked to Puredata.

    After the work of yesterday, a bit tedious, and a bit of cosmetics in pd, sound sources are now correctly linked with the sound. Pan is controlled by the x coordinates of the source. Source also send the file path to play to the track. The 3 tracks you see there are completely automatised, with the help of yacine sebti.

    About the file format, it’s a bit more tricky: puredata only reads .wav & .aif by default. An addon exists to load ogg (personal choice), but it only takes absolute path!

    Ogre cannot do that (find the absolute path) but boost::filesystem canref. Unfortunately, this part of the boost library is not binded to ogre… Another todo 🙂


    This post is related to this one

  • frankiezafe 21:11 on 2016-09-17 Permalink | Reply
    Tags: 3D, , , Ogre3D, trigonometry   

    Trigonometry hell.

    Finishing the day with cool code running:

    • World coordinates to camera coordinates, especially usefull for sound sources. Indeed, top, right and front depends on the relative position of the source in the camera space, not the global one.
    • Transformation of the sticks direction into world coordinates relative to camera, once again. This time, calculation is based on the lookat location, keeping the system centered on the screen.

    Second point was trickier but solved first… Finding the position of an object in the camera space is basically a conversion of reference: center of the world is not (0,0,0) anymore, but camera world location + up is not (0,1,0) anymore, but camera orientation.

    A bit of code, it can help to understand the trick:

    // creation of the camera matrix, not sure it’s possible to retrieve it easier…
    Matrix4 cam_mat = Matrix4( cam->getDerivedOrientation() );
    cam_mat.setTrans( cam->getDerivedPosition() );
    // inversion of the cam matrix
    Matrix4 cam_mat_inverse = cam_mat.inverse();
    // for a given vector expressed in global
    Vector3 v( 10, 5, -45 );
    // construction of a matrix representing this translation
    Matrix4 m = Matrix4::IDENTITY;
    m.setTrans( rel );
    // MAGIC! > conversion to camera space
    m = cam_mat_inverse * m * cam_mat;
    // and, finally, getting back the coordinates in camera space
    v = relm.getTrans();


Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc