Tagged: game dev Toggle Comment Threads | Keyboard Shortcuts

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

    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:44 on 2016-09-23 Permalink | Reply
    Tags: , , game dev,   

    Bullet integration.

    Working on a wrapper to ease access to the ogre objects, in a namespace called polymorph 🙂

    For instance, here is how to declare objects.

    polymorph::PBullet::start();

    // simple nodes
    n0.sphere( sceneMgr );
    n0.orientation( Vector3( 0.3,-0.1,0 ) );
    n0.scale( 2.46 );
    n0.move( Vector3( -12,8,0 ) );
    n0.debug( true );

    n1.sphere( sceneMgr );
    n1.debug( true );
    n1.orientation( Vector3( -0.5,0.1,0 ) );
    n1.scale( 4 );
    n1.move( Vector3( 12,0,0 ) );

    // parenting n1 to n0
    n0.attach( &n1 );

    // nodes with physics
    my_sphere.sphere( sceneMgr );
    my_sphere.orientation( Vector3( 0.3,-0.1,0 ) );
    my_sphere.scale( 2.46 );
    my_sphere.move( Vector3( -12,8,0 ) );
    my_sphere.debug( true );
    my_sphere.physics( polymorph::BT_DYNAMIC_SPHERE );

    my_node.load( sceneMgr, “General”, “ob.mesh” );
    my_node.physics( polymorph::BT_DYNAMIC_FREE, “General”, “ob-physics.mesh” );
    my_node.scale( 5 );
    my_node.debug( true );

    Once done, to move an object, you call:

    my_sphere.yaw( Radian( 0.005 ) );
    my_node.yaw( Radian( 0.02 ), true );
    my_node.move( Vector3( -12,8,0 ) )

    Very soon, custom meshes will be available into Bullet!

    See P.E.2.0/bullet/app for sources.

    ogre-render-window_690

     
  • frankiezafe 20:06 on 2016-09-18 Permalink | Reply
    Tags: game dev, , , 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 🙂

    selection_687

    This post is related to this one

     
  • frankiezafe 18:44 on 2016-09-14 Permalink | Reply
    Tags: editor, game dev,   

    Edition tool, first draft.

    This is the first step towards a game editor based on #ogre. At this stage, the application allows to reload all resources from the drive and therefore to change the materials manually without having to stop/start the viewer each time. Lights are also selectable and modifiable.

    It’s obviously much less clean to drag and drop files in the filebrowser, but i like the idea that you can use any text editor to work on your files. An “open game development toolkit” rather than an “Integrated Game Development Environment” 🙂

    The source is available here.

    The previous post and this one close the day on an happy note: it’s now possible to see the models in Ogre without compiling it and to fine-tune materials easily.

     
  • frankiezafe 20:25 on 2016-09-11 Permalink | Reply
    Tags: , , game dev, ,   

    Repositories clean-up.

    All repositories related to polymorph are now accessible in a clean and understandable way, thanks to the team concept of bitbucket. See polymorph-team.

    There are 5 projects:

    • engine, with all the examples
    • addons, one repo/addon
    • internal, the graphical id and other stuff related to communication
    • games, one repo/game, none public yet…
    • tools, custom tools developped for specific tasks, none public yet…

    selection_681

     
  • xuv 22:00 on 2016-09-09 Permalink | Reply
    Tags: game dev, , ,   

    Polymorph weekly news #6 

    overall-structure-20160930-liberties-002-text

    If you’re following this series of weekly news, you’ve noticed there hasn’t been any for the past few weeks. I apologize for this. It does not mean Polymorph was on hold or that I lost contact with the team, but I just did not have much time to write a post and do the regular interviews of the different participants. But this week, I’m back on track and was invited to participate in the dev meeting with @frankiezafe, @balt and Olm. So let’s summarize this 3 hours meeting in a couple points that hopefully will invite you to dig further and come to the next one. Because, since Polymorph is actually an open source game development platform, you are all welcome to join, anytime you want.

    Out of the many things that have been developed around Ogre for the past few weeks, the last notable one is an addon to handle game controllers. François has finished and tested it with Olm and Balthazar. They’ve even tried to plug in multiple mouse controllers in one machine to see how that would work. But although this could be possible on a Linux machine, it’s not as easy as it sounds. While the idea of creating a game for multiple users on the same computer, each with his/her own mouse, is appealing, the complexity and the limitation in terms of OS choice don’t make it a priority for Polymorph at this time. If a project comes up that requires it, further research will be done in that direction. As for now, the Ogre addon for game controllers works. It’s not going to be an official addon as the Ogre community requires that unit tests must be written for it in order to make it into the official list.  But since it’s open source and the code available here, if someone wants to jump on it and do it, you’re more than welcome.

    The conversation went on about PEEL’s gameplay and especially how the player moves around and manipulates objects. As you can see in the video below, things run smoothly. But an interesting conversation happened between Olm, Balthazar and Francois on how to improve things and make it even smoother.

    François then introduced his plan on how to configure each levels using XML files. Basically, each level is fully described by a tree of options and parameters, which makes it a fast and convenient way to create new levels. Discussion went around the structure of the XML, where to add and define sound parameters and so on. Which then evolved in a whole conversation on how to best use the sound engine (aka Pure-Data) that is now fully part of the Polymorph Engine. Pure-Data, for those who don’t know, is the open source equivalent of Max/MSP. A very powerful realtime sound synthesizer, making the Polymorph Engine a musical instrument in itself.

    As for PEEL, being a minimalist game in  terms of 3D objects and environment, the sound will be crucial to give a sense of space and set the overall mood of the game. We’re taking about spacial sound and realtime sound effects, of course, done with the help of Daniel Perez Hajdu.

    Regarding the development of Polymorph Engine, many questions are still open. What about the compilation on Android? Lacking tools and access to proper Android hardware, Francois has not managed to compile it for this platform yet. There is also big questions hanging in the air regarding shadows. Francois has not figured out how all that works. It might be not so important for PEEL, but the next project will require it.

    And since we are already talking about the next project, @louise will be joining Polymorph next week to start working on the Contredanse application. She will be doing research on the gameplay and work on the integration of the 3D elements in the game engine. While @frankiezafe will be in charge of integrating Bullet (the physics engine) and finding all the help in can get from the Ogre community to get the shadows working.

    So stay tuned, come visit us and pass on the information around you, that’s also a way to show support to this project. And see you next week.

     
  • frankiezafe 19:37 on 2016-09-06 Permalink | Reply
    Tags: game dev, motion, , ,   

    Navigation along the structure.

    After some refactoring, the system starts to behave nicely:

    • objects position, size and orientation are described in an xml, much easier to modify
    • gaps (the space between joints, marked by a white sphere), are rendered automatically by the engine
    • camera rig (a hierarchy of objects including camera and lights) is able to move along the structure, from cluster (orange boxes) to boxes
    • when 2 gaps are vailable in a cluster, it’s possible to choose wich one to solve
    • camera orient itself according to the selected gap

    I have to plug back the resolution of gaps, disabled for now. Moving a segment will cause issue, for sure. More about this very soon!

    The tricky point was to manage the camera correctly when its orientation is not aligned with the world axis anymore. The camera is parented to a node called origin. When the orientation of origin change, the UP axis used to update camera has to be given before calling lookAt for instance.

    Vector3 local_up( 0,1,0 );
    local_up = origin->getOrientation() * local_up;
    cam->setFixedYawAxis( false, local_up );
    cam->lookAt( origin->getPosition() );

     
  • frankiezafe 20:10 on 2016-09-03 Permalink | Reply
    Tags: game dev, ,   

    Starting the integration of the new logic in the engine.

    The cluster concept being new (the orange boxes), i need to already review the classes behaviour. The class diagram posted in july is not good anymore.

    Selection_679

     
  • frankiezafe 16:45 on 2016-08-26 Permalink | Reply
    Tags: , game dev,   

    Gamepad addon for Ogre.

    First version of the code is ready:

    • detection of gamepad plugged / unplugged
    • all buttons & axis accessible
    • events on gamepads and on each axis and button
    • precise axis + delta of motion
    • precise axis + delta of motion
    • separated thread for data retrieval

    repo: https://bitbucket.org/frankiezafe/ogregamepad/

    gamepad_parameters_in_ogre3d

     
  • frankiezafe 19:09 on 2016-08-25 Permalink | Reply
    Tags: game dev,   

    Game controller wrapper.

    Just finished a nice piece of code to manage gamepads (and potentially joysticks) in an efficient and clean way.

    For start, you just ask Input manager to start a game controller

    input::InputManager::openGameController(0);

    To get the information out of the InputManager, you call:

    input::DataFrame input_frame;
    input::InputManager::getInputFrame( &input_frame );

    To detect change events (equivalent to button pressed), you have to declare the DataFrame as a class parameter. Each time you call getInputFrame, the events are rendered.

    To access events and input values, you have to read your input_frame. It contains a vector of GameControllerFrames. Each GameControllerFrame has an id, corresponding to the id you gave in openGameController( ID );

    A GameControllerFrame also contains several maps:

    • axis: a map of vector2d for 3 axis: left & right sticks + trigger.x (~LT) & trigger.y (~RT). Vectors are normalised and stabilised.
    • buttons: a map of boolean, true if the button is pressed
    • axis status: indicate if the axis is active, inactive, has just been activated or deactivated
    • button status: indicate if the button is active, inactive, has just been activated or deactivated

    activated and deactivated are there only for one update. After that the status becomes generally active or inactive.

    It is important to understand that these status depends on the frequency of InputManager::getInputFrame( &input_frame ). The previous data frame is stored in the local DataFrame, NOT in the InputManager. The idea is to make a clean data retrieval when needed, and not risking interruption during the main loop.

    The InputManager runs on its own thread and does not trigger events in the main application.

    The code is available in the example-gamepad.2.0 in bitbucket. See related issue.

    Selection_677

     
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