Tagged: physics Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 19:24 on 2018-07-11 Permalink | Reply
    Tags: , , , , physics, ,   

    Soft skin 

    Currently working on a library of skinning called SofSkin. It’s purpose is to make skinning in a different way: less rubberish and more mesh/geometry-oriented. The idea is to use edges of the mesh as springs that tries to recover their initial length by pulling/pushing on the vertices. The lexical field is focused on anatomy, to keep the code lifefull.

    The integration in godot is on its way, as shown in this video:

    The repository is hosted in gitlab: https://gitlab.com/frankiezafe/SoftSkin

  • frankiezafe 21:09 on 2018-02-14 Permalink | Reply
    Tags: , , , , physics   

    Second phase of the work: sending the user inputs from client to server and process the interactions. There is still a small issue with the relative position on the screen of the client, to fix tomorrow, and implementing visual feedback in the client.

  • frankiezafe 23:05 on 2018-02-13 Permalink | Reply
    Tags: , , , , physics, synchronisation,   

    Always the same surprise when one application controls another! In this case, the application on the left is running on my workstation, receiving and visualising the position and rotations sent by the laptop on the right. The laptop is running the physical worlds.

    Tomorrow I’ll remount the mouse control in the client (the one on the left), and it will be possible to play at 2 in the same physical world!

    (done with my crappy webcam, sorry fot the quality)

  • frankiezafe 15:51 on 2018-01-13 Permalink | Reply
    Tags: , inverse kinematics, PBR, physics, , urho3d,   

    Urho3D, demo session. Great work, tested on windows and osx.

    The end of the video is the discovery of the editor.

    Try out the samples.

    All examples:


  • frankiezafe 23:24 on 2017-10-12 Permalink | Reply
    Tags: , , , , physics, , ,   

    same video on peertube

    (a bit more than a technical demo this time)
    After finishing the work on shadows, it was time to play with the different materials possibilities.

    To explain a bit what you are seeing:

    • at the top left, the 3 textures containing the shadow maps;
    • transparent walls (wireframes) are not take into account in the shadow map because they are using a specific material called invisible_for_shadows, i think the name is obvious;
    • the foggy volume above the ground is made of a stack of 25 thin boxes, using another cool material: solid_shadows_no_cast, they receive shadows but don’t cast them;
    • and the balls, using the solid_shadows material and having the standard behavior, but in wireframe, implying that fog is hollowed when you look through them.

    A cool feature is the ability to set the alpha of the shadows material per material. For the jelly fog, the material is looking like this:

    material screen_mat : solid_shadows_no_cast
        pass standard
          diffuse 0.6 0.7 0.95 0.2
          emissive 0.2 0.3 0.45 0.4
          depth_write off
          scene_blend alpha_blend
        pass pssm
          fragment_program_ref ShadowsPssm_pix
            param_named shadow_alpha float 0.2

    The speed control over the physic simulation (when everything freeze) is modifying the time multiplier of bullet. The call is looking like this:


    Complete projects is accessible in the engine, under samples/0.1/example.pssm_shadows.

    I need to rest a bit, it has been a harsh road to get this packed. The last part of the job is to ensure the compatibility low opengl versions!

  • frankiezafe 20:38 on 2017-10-10 Permalink | Reply
    Tags: , physics, , ,   

    Visualisation of contact events in the engine. Wireframe objects are the actual physical objects. The small plain spheres are placed at the position of the contact (or the average of all points), and reacts to impulse. Impulse is one of the components of the forces applied on the objects while bullet resolves the world.


    • impulse > 1000: red material;
    • impulse > 1: yellow material;
    • by default: cyan material;
    • scale calculation: (3 + impulse * 0.00001) caps at 15.

    To be precise, the impulse used here is the delta of the previous and current impulse.

    The video shows only one of the 2 contact events you can retrieve from engine:

    • pairs: represents the relation between 2 objects in contact (visualised here);
    • per object: it is also possible to retrieve contacts for a specific object.

    In future version, I plan to enable specific pair listening (“i want to know when this specific object touch this other specific object”).

  • frankiezafe 18:58 on 2017-09-29 Permalink | Reply
    Tags: , physics, , ,   

    Precision tests with bullet 

    Small demo of the current state of the refactoring on Tuning Game 3D.

    The code has been completely torn apart, some features have been moved to the engine, the rest is currently heavily refactored.

    One of the things that works much better than before is the localisation of the pointer when the user is grabbing an object: the screen is projected onto the “ground” (the floating pink box at the middle of the “room”) in a proper way. Once grabbed, the mouse is not moving in the screen space but on the surface of the ground. This may seems odd when explained, but it’s very intuitive when you controlling the mouse.

    [to be continued]

  • frankiezafe 20:35 on 2017-09-22 Permalink | Reply
    Tags: , , , , physics,   

    1K spheres, 7 static boxes.

    It has been a hard day: the communication between Bullet and Ogre has been completely reviewed:

    • update of the physical world is now linked to the Ogre rendering cycle through Ogre::RenderQueueListener, meaning a more consistent frame cycle;
    • PObjects (any renderable object in the scene) are smart enough to update the correct engine, ogre when no physic, bullet when physic is enabled;
    • anti-explosion tests are refusing to parent 2 objects having physic enabled.

    The work is not finished yet, and a serious stress test should be done.

    See samples/0.1/example.bulletspring in the repository for the code of the example.

    • xuv 21:45 on 2017-09-22 Permalink | Reply

      After the popcorn test, the lottery test. Nice 🙂

  • frankiezafe 18:50 on 2017-09-17 Permalink | Reply
    Tags: , , , , physics   

    Not very sexy, but very useful: there are 2 new methods in the bullet wrapper that enables retrieval of an ordered list of the collisions along a ray.

    The job was super easy, thanks to the bullet lib consistency and documentation. The object to use is AllHitsRayResultCallback. Once processed, it returns a list of bodies touched by the given ray.

    The last part of the job was to order this list. The fastest way I thought of was to use an std::map, and use distances between the start of the ray and the hit point as keys. The nice thing with maps is that they are automatically sorted, if you use a native numeric key, such as floats.

    This map is then turned into an array of PBulletRay.

    In the code that use these methods, you can loop over the array, all objects are sorted from the closest (relatively to camera) to the farthest.

    Available in repo (not yet documented nor doxygened)

  • xuv 17:43 on 2016-10-25 Permalink | Reply
    Tags: , physics, ,   

    Polymorph weekly news #9 

    Tuning Scores chair physics

    No news is good news. Polymorph is alive and kicking. The train is on its tracks. The ball is rolling.

    It’s already almost a week since I’ve chatted with @frankiezafe and @louise about the advancements of their project. You might have also noted that they don’t post much either on this blog. As François says it, it’s because the progress they make is not that big of  step to share, or does not produce some visuals that would look good on the blog. Back a couple weeks, when features where being added almost every day, things were exciting. Now, the real work of polishing and improving what has been initiated is actually happening and that just does not seem as exciting to share. Although it’s exciting for the team to see it growing.

    A second meeting with Contredanse was much more productive and finally we started talking about gameplay. Baptiste and Florence could put their hands on the mouse and feel what a player could feel. Discussion ensued on object movements and reactions in the virtual world. The manipulation of the camera created interesting problems and awkwardness that needs to be addressed. And a common set of objects has been defined and should be limited to a stone, a stick, a chair, a cup and a chain for now. @louise is iterating on the appearance of those and playing around with their physics properties.

    François is deep into physics programming. He also took a big decision regarding all the tools he is building. Instead of trying to produce some independent Ogre libraries, he will concentrate on making it all work in the Polymorph Engine (PE). As a reminder, the PE is a bundle, a package of great open source libraries to make video games. The choice to release work as a bundle instead as independent modules is mainly a practical one. It will take less time to code. The modules are also very much interdependent for now. So making them detachable from the PE would require extra work that the team does not have at the moment. Maybe in the future. But again, making a full featured game engine on top of Ogre was always one of the goal of Polymorph. The ability to break this apart is then for later.

    Where is PEEL you might ask? On hold for now. Tuning Scores is the priority since the prototype needs to be delivered by December. All eyes are on this goal now. And challenges remain, such as multiple mouses input for example. Anyway, all progress on Tuning Score is good for PEEL. So no worries, François will be back on it for Christmas.

    See you next time.

    PS: All screenshots by @louise

    Tuning Scores chair

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