Tagged: example Toggle Comment Threads | Keyboard Shortcuts

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

    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
    {
      technique
      {
        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:

    polymorph::PBullet::time_multiplier(0.85);

    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 18:02 on 2017-09-21 Permalink | Reply
    Tags: , , example   

    Popcorn example in engine 

    A new “popcorn” example showing how to enable physics on objects is available in the engine. It is not finished yet, and will help fine-tuning the relation between ogre and bullet (engine-level).

     
  • frankiezafe 22:41 on 2017-09-15 Permalink | Reply
    Tags: , , example   

    Camera rig example in engine 

    A new example showing how to use the class PCamRig object is available in the engine’s samples.

    PCamRig is using PRange objects to describe all rotations (pitch, yaw & roll), enabling a simple control of the angles.

    In the example, roll is going from 0° to 90° and yaw from -45° to 45°, the mouse is only controlling the percentage of each range applied on the camera. There is a subtlety about axis of rotation explained in the code.

    It comes with a simple way to interpolate value with an “elastic” effect. Explanation about the interpolation can be found here: Notes:Interpolation, speed/current

     
  • frankiezafe 18:25 on 2017-02-01 Permalink | Reply
    Tags: example, , ,   

    Technical demo.

    Based on the patches started yesterday evening, the example.pd shows how PD can be used with its user interface to interact RT with the engine. Once the work is done, by commenting a #define in the main class, you switch to release mode, without changing anything to the patch!

    Parts of the video:

    1. edition: puredata used with ogre3d
    2. release: libpd loads the pd patch inside of ogre3d

    As explained in this post, the edition is based on an OSC communication between the two apps, it works with the basic puredata.

    There is 2 VERY important objects in this patch:

    • pobject_in: it can parse osc messages as well as internal messages (when used in release mode); it also create 4 internal senders pobject_in_trans, pobject_in_rot, pobject_in_scale & pobject_in_all; no need to be plugged to the pobject_in box, you can receive the messages anywhere in your patches;
    • pobject_out: it can pack osc messages for the engine as well as internal messages (when used in release mode); it also create 4 internal receivers pobject_out_trans, pobject_out_rot, pobject_out_scale & pobject_out_all; no need to be plugged to the pobject_out box, you can send messages from anywhere in your patches;

    On the C++ side, the PdEngine has to be set in edition or release mode to works properly with pd. The communication with pd happens through the same methods. The idea here is to make the two modes transparent to the user, even if the c++ guy has to know what he’s doing :).

    Keep in mind it’s a demo and there is a lot of optimisation to do on the C++ level, but it gives a good idea of the integration of the 2 libraries.

    And, yeah, i’ll have to check how to record the sound with ffmpeg on linux…

     
  • frankiezafe 13:08 on 2017-01-17 Permalink | Reply
    Tags: , example, , , , ,   

    screenshot01172017_125756932

    New example ready for skeletons manipulation.

    In the example, the skeleton debugging is enabled by default. It shows the bones hierarchy and the local orientation of each bone.

    There is 3 transformation spaces for bones, inherited from Ogre3D:

    • LOCAL
    • PARENT
    • WORLD

    All methods to get or set orientation, scale and position are sensitive to this value, except the moveBone methods, not yet finished.

    The example shows also the different ways to retrieve information about the skeleton: list of bone’s name, list of bone objects, access via name, id or pointer, etc.

    The beautiful model i destroy if from Sophie Khan and distributed by #additivism.

     
  • xuv 20:00 on 2016-08-05 Permalink | Reply
    Tags: example, , ,   

    Polymorph weekly news #4 

    OGRE Render Window_658

    Fourth week already and half way? Let’s see.

    So back to interviewing @frankiezafe, our project leader and main motor behind the Polymorph Engine (haha, I’m so funny). So Frankie and I had a little chat, which was supposed to last one hour but ended up taking two. Although this post won’t be as long, I promise. But I was keen to know how projects were going from his point of view.

    As you may have seen from his last posts, there is now what is called an Empty example for Ogre 2.0 running. It’s not that empty because it has a camera, lights and objects floating in empty space, but you get the idea. It’s a basic demo to start working from. It’s also a great tool to check that things compile in all platforms. So far, François has it running on Linux. It should run on Windows and other platform are coming. By the way, if you are interested, please have a go at it and send feedback. There is now documentation and code on the repository. And while it’s not yet a complete Empty example, it should get you started. And we’re excited to read what you think of it.

    So François is now step by step going deeper in the Ogre3d documentation. His experience with Openframeworks proved very valuable here. Because he already knows how the GPU (graphic card) is handling images, as he says it:

    You throw a bag of numbers at it in the correct format and it spits out an image.

    Although handling Ogre is a lot more different than Openframeworks. If Openframeworks is an excellent introduction to C++ and a very flexible tool, Ogre is way more complex and structured. It requires a good understanding of high level C++ concepts and related software design patterns, which makes Ogre a powerful tool indeed, but harder to learn. I could sense that this was kind of a hard step for François, but it also came with its moments of joy, when he shared with me the code that defines the camera movement.

        if ( mouse_right_dragged ) {
            Real rspeed = 0.005f;
            Vector2 diff = mouse_right_current - mouse_right_pick;
            Quaternion qo = cam->getOrientation();
            Quaternion qx( Radian( -diff.y * draw_event.timeSinceLastFrame * rspeed ), Vector3( 1,0,0 ) );
            Quaternion qy( Radian( -diff.x * draw_event.timeSinceLastFrame * rspeed ), Vector3( 0,1,0 ) );
            cam->setOrientation( qo * qx * qy );
        }

    These little things in Ogre make it so much easier, said François.

    His work from this week focused on code to generate mesh, materials and texture on-the-fly, meaning things are not preloaded from files at startup, but generated by the engine itself when the game runs. François is taking inspiration from Mad Max tutorials, but “cleaning up” the code, as he says it, and creating basic classes from it. Making it then reusable code for following projects. It may not look like it, but all this is necessary for the development of PEEL, the first game of Polymorph.

    PEEL should come out at the end of August, hence my introductory mention of “half way”. Polymorph exists since 4 weeks and should deliver an alpha verison of its first game in 4 weeks. There is many steps until then, but Pieter and François are making progress. And Daniel Perez has agreed to make a Pure-Data patch for spatialized sound. So stay tuned and see you next week.

     

     
    • frankiezafe 10:26 on 2016-08-09 Permalink | Reply

      Much better version of the camera controls, thanks to qknight (https://github.com/qknight/ogre-examples)

      Real rspeed = 0.005f;
      Vector2 diff = mouse_right_current – mouse_right_pick;
      cam->yaw( Radian( -diff.x * draw_event.timeSinceLastFrame * rspeed ) );
      cam->pitch( Radian( -diff.y * draw_event.timeSinceLastFrame * rspeed ) );

      Already in example.2.0

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel