Tagged: game engine Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 23:59 on 2017-01-13 Permalink | Reply
    Tags: , game engine, , ,   

    screenshot01132017_235526088

    screenshot01132017_235531770

    screenshot01132017_235541017

    Working on a debugging view for skeletons, a good way to learn how #ogre3d is storing skeletal data. There’s a scaling issue: the points in the face are not correctly placed, they should be at the lips borders, at the basis of the nose and closer to the eyebrows.

    The visualisation is not the same as in blender: bones are linked to their parent head, not tail. It’s simply because the information about the size of the bone is not available in ogre. The only information available for a bone are its position and orientation.

    A fix will come soon!

     
  • xuv 17:35 on 2017-01-09 Permalink | Reply
    Tags: game engine, installation, ,   

    Polymorph Engine on ArchLinux 

    Thanks to the great work and tutorial from @frankiezafe, I managed to compile and run the basic examples of Polymorph on an ArchLinux system. I had to make a few changes to the documentation and find the right flags for some libraries (instructions here). But everything seems to be running smoothly. More tests to come later, I guess.

    ArchLinux screenshot running Polymorph Engnie basic sample

    Save

     
  • frankiezafe 23:42 on 2017-01-03 Permalink | Reply
    Tags: , , game engine, ,   

    screenshot01032017_233404150

    Today, a lot of bug fixes on the basic classes of the polymorph packages.

    New: it is now possible to declare the resources folders in the XML! The common resources.cfg of Ogre can be replaced by a configuration.xml, placed in the same folder as the exec.

    The resources.cfg was looking like this:

    [Essential]
    Zip=../media/packs/PolymorphTrays.zip

    [General]
    FileSystem=../media
    FileSystem=../media/materials/scripts
    FileSystem=../media/materials/textures
    FileSystem=../media/models

    In the XML, it’s converted to this, with control over recursivity and read access.

        <resources>
            <group name=”Essential”>
                <resource path=”../media/packs/PolymorphTrays.zip” type=”Zip”/>
            </group>
            <group name=”General”>
                <resource path=”../media/models” type=”FileSystem” recursive=”1″ readonly=”0″/>
                <resource path=”../media/materials” type=”FileSystem” recursive=”1″ readonly=”0″/>
                <resource path=”../media/materials/textures” type=”FileSystem” recursive=”1″ readonly=”0″/>
            </group>
        </resources>

    The sreenshot comes from an evolution of the XML example, see Dynamic scenes loading

     
  • frankiezafe 18:40 on 2016-11-25 Permalink | Reply
    Tags: , , game engine,   

    scene-loading

    Dynamic scenes loading.

    Based on an #XML description of the project, that looks like this:

    • <polymorph version=”0.1″ date=”20161124″>
      • <scenes>
        • <scene id=”3″>
          • <pobjects>
            • <plight name=”main_sun” visible=”1″ debug=”1″>
            • <pnode name=”floor” visible=”1″ debug=”0″>

    and so on, it is easy to load a new scene. The deletion and creation job is managed by a cool object call “PObjectManager” see: http://polymorph.cool/doxygen/classpolymorph_1_1_p_object_manager.html (thanks, doxygen!)

    In the example.1.xml, the key ‘n’ is binded to the method PObjectManager.nextScene().

    A little note: in the scene 1 (the middle one), the pile of plates has been done via a special tag:

    <repeat count=”20″ offset_pos=”0,10,0″ offset_dir=”0,5,0″ offset_scale=”-2,0,-2″ />

    When placed in a pnode, it will generate copies of the object automatically. Similar to array modifier of blender.

     
  • frankiezafe 19:35 on 2016-11-20 Permalink | Reply
    Tags: game engine, ,   

    selection_709

    Here is the output and the code of the empty example. It is using polymorph package.

    Once installed (the tricky part, soon fixed with a magic installation script), you just have to extends PolymorphApplication class and start working.

    As you may notice, the class CustomApp does nothing on its own. It just calls the mother class’ methods. The purpose of this empty project is to enlight crucial methods to overwrite in order to start coding something.

    I’m now working on a basic example, showing how to add primitives, load meshes, add lights and animate them.

     
    • frankiezafe 21:34 on 2016-11-20 Permalink | Reply

      @xuv & @balt : i think it’s important to be obvious on what is polymorph and what is ogre by keeping the namespaces as they are. For instance, creating a PNode requires to call polymorph::PNode. When you want to create a vec3, there you have to call Ogre::Vector3.
      In the example above, the using namespace is only used in cpp => for all class params (.h), they have to be set this way. It will be explained in the basic example.
      What d’u think?

      • xuv 14:19 on 2016-11-21 Permalink | Reply

        @frankiezafe : seems coherent.

        • frankiezafe 15:53 on 2016-11-21 Permalink | Reply

          i’ve started working on a “PObject”, wich is a common ground for PNodes, PLights and PSounds. It’s a abstract object defining anyhting located in the 3d world, with possibility to attach them together or add physics on them.
          Result: ultra tuff conceptual work, using an abstract class + a template class for PObject – will work in a few days.

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

    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.

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

    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

     
  • frankiezafe 20:01 on 2016-10-21 Permalink | Reply
    Tags: , game engine   

    Today: XML

    Until now, @louise was not able to access objects position and configuration… I guess it was quite frustrating for her, as she is working on the assets of the Tuning Score game.

    Now it’s better. Based on the work made for #PEEL, a XML description of the objects to load is available.

    It looks like this:

    selection_698

    Each polymorph node is an object having:

    • an origin transformation;
    • a local transformation, only applied on the mesh attached to this node, not its children;
    • a primitive to display, when you don’t need to load a mesh – available: cube, sphere, plane & empty (very useful, i got it now);
    • a mesh to display;
    • a material, when you want to use something else than the default one;
    • a bullet configuration, for physics, dynamic or static, with the possibility to use a special mesh and a configuration tag that gives access to a few physical parameters.

    I’m going to deploy this on louise computer and it will be over for this week!

     
    • frankiezafe 00:11 on 2016-10-22 Permalink | Reply

      note: provide a DTD to validate and explains the XML > check if tinyxml supports it.

  • xuv 20:36 on 2016-07-22 Permalink | Reply
    Tags: game engine, , , ,   

    Polymorph weekly news #2 

    general-kickoff-presentation-engine

    Just like last friday, here’s a little recap of what happened inside Polymorph during the week. For this episode, I interviewed Pieter Heremans, one of the core developer working on the Polymorph engine. I first met Pieter when he was part of Lab[au], but you probably also know him for his involvement in HSBXL, F/LAT and many more projects involving hacking and open source technologies.

    During our discussion to prepare this post, I was curious of why they had chosen to go for Ogre 2.0 and how Pieter was seeing the development of the engine.

    There is 4 concurrent versions of Ogre (1.9, 1.10, 2.0 and 2.1), but the dev team decided to go for the 2.0 as it’s right now reaching a stable state and also works on mobile platforms. This page from Ogre team helped make the decision. The “problem” though is that most of the examples and documentation available online are for versions 1.x, so one of Pieter’s task is to fill that gap, meaning, porting or creating new examples and providing good documentation to compile Ogre 2.0.

    Last week Pieter had managed to compile it on Linux (Debian to be precise) and Android. This week, compilation worked on Windows 10. If you care to see how he did it, check out his report in the related issue on Bitbucket. When I left the conversation with him, he was going to have a try at MacOSX, although that could maybe more problematic. It’s worth noting also that although the compilation for Android was successful, meaning software was running and debug messages were flowing smoothly, the violet (violent?) color displayed on the screen could mean problems with the graphics engine. If Ogre uses OpenGL on Linux and Windows, it needs to use OpenGLES on Android, and there might still be some bugs or things to solve in that corner.

    I then asked if Pieter was contributing back to the Ogre development and where or how he was making the documentation. So far, he has only done little changes to Ogre’s code to be able to compile, but does not exclude pushing back his findings later on. As for documentation, he uses a viva voce approach at first with the help of the issue tracker. His plan is to tell @frankiezafe how to compile Ogre with its verbal instructions and see where François might have trouble or where he might be missing some packages. Then they would write a more structured documentation together explaining the process.

    I also asked him about the analogy between Openframeworks and the Polymorph Engine. And here Pieter is a little more skeptical. Openframeworks is a very immediate tool that allows to start coding and get a quick result. Ogre has a more managed approach and is responsible of doing the scene draw itself. It’s also bigger, more complex and uses a different way to get things rolling. So, apart from C++ knowledge, the transition between Openframeworks and Polymorph Engine will not be an easy one. There is a whole lot of different things to take into account. But, where the analogy works, is that Polymorph Engine will be a bundle of Ogre with other useful libraries, proposed as a package. Right now, compiling Ogre means compiling it from libraries installed on your system, while compiling the Polymorph Engine would be working from a folder where everything is put together.

    One of the addition of the Polymorph Engine that Pieter is looking forward to is the the use of libPD (Pure-Data) inside the game engine. Apart from the fact that it would permit all sound manipulations that Pure-Data already proposes, which is very exiting in itself, Pieter hopes to be executing PD patches directly inside Ogre. As he puts it, this would open collaboration between game designers and sound engineers, allowing to integrate their work directly in the game making process, without needing to recode the patches. We could also imagine PD patches becoming a form of scripting language for Ogre itself.

    Next week, @frankiezafe is back from his Blender teaching at iMAL, and the whole Polymorph dev team will be working together on implementing the first game, still known as PEEL, in the Polymorph Engine. This will be an important week. So stay tuned.

     
    • frankiezafe 19:10 on 2016-07-25 Permalink | Reply

      About the “putting everything in a folder”, it’s working fine > one or 2 flags in cmake and the job is done. I’ll a video to show how easy it is 🙂

      • xuv 19:35 on 2016-07-25 Permalink | Reply

        Looking forward to the video. The “putting everything in a folder” was more about a question of distribution of the Polymorph Engine, rather than building the PE. When you say, it’s easy, do you refer to this documentation: https://bitbucket.org/frankiezafe/polymorph-engine/wiki/ogre.0.2-setup
        Another way of phrasing the question is: Is Polymorph Engine going to be a distribution in itself or a set of docs to build it?

  • xuv 20:38 on 2016-07-15 Permalink | Reply
    Tags: game engine, , , , ,   

    Polymorph weekly news #1 

    This is the first post of what we hope to be a series, where we try to summarize and explain what happened at Polymorph during the past week. For this one, I interviewed @frankiezafe and asked him about the development of the different projects at Polymorph.

    PEEL

    Peel is the code name for the first game developped inside Polymorph. François was working on this project since a while and started with a first concept, which gave it its name. As portrayed in this video, the idea was to solve a puzzle, to find your way through a labyrinth by peeling a 3D sculpture. This concept came after a workshop François gave about Three.js.

    If you’ve followed some posts from this week, the concept is evolving into something completely new and different. The name is kept, but the principles have evolved into a different game, one where the player has to assemble different 3D pieces in order to solve a puzzle.

    modules-with-lighting_001

    Since this is going to be the first game published by Polymoph, Francois is looking for something more interesting in terms of gameplay than just a little project that you would discard after 2 minutes. The goal behind PEEL is to test the workflow and the tools, but not only. The purpose of Polymorph is to also test new gameplays and new approaches in game design, this is why PEEL had to evolve in something more challenging, more interesting.

    The inner workings of the game are now more complicated and hard to put into words. So Francois is laying his ideas into schemas and graphics, both as a way to express them but also possibly ease the work of programming it afterwards.

    oo_structure_003

    Let’s see how that evolves over the next weeks.

    Polymorph Engine

    What we call the Polymorph Engine is an assembly of different tools, with at its core, the open source 3D engine called Ogre. Every monday, the dev team of Polymorph meets to discuss the tasks and needs to achieve compilation and running examples of Ogre on all the operating systems possible.

    general-kickoff-presentation-engine

    Taking OpenFrameworks as an example, the Polymorph Engine would be Ogre and some other components nicely packaged so that a game developer could easily start working on projects without having to recompile Ogre each time. The same way you just clone an empty example from OpenFrameworks to start working on your next digital art project, with Polymorph Engine, you would copy the basic default empty example and start coding and testing your project from there. This means that the compilation of Ogre would only be done once, most certainly just after downloading the latest version of the Polymorph Engine. Then just the example you are working on would be compiled each time some code is changed.

    So far, Francois had achieved compilation of Ogre 1.9 on Linux and even published a tutorial for those who would like to try it also. But the dev team of Polymorph has decided to use Ogre 2.0 for the Polymorph Engine and this is much much less documented than the previous versions of Ogre. Work needs to be done in that sense, to document and ease that process.

    During the past week, Peter has managed to compile Ogre 2.0 for Android and Debian and also compiled the first examples that come with it (aka. the Purple Screen of Joy aka “Yes, it’s working”). @balt has also managed to compile Ogre 2.0 for Linux Mint and has investigated into build farm software to automate compilation on different platforms.

    Plans for next week

    By the end of next week, we expect to have Polymorph Engine working as it should (Ogre + an empty example to be copied) for Linux. The whole Polymorph team working exclusively on Linux machines, this is priority in terms of platform so that game designers can start implementing their ideas.

    Compilation of Polymorph Engine will also be tested on Windows 10.0.

    And François will take some time off from game development because he will teach Blender for the whole week at the summer workshops of iMAL. Don’t hesitate to join him if you’re interested, there might be some seat left.

    Thank you

    If you found this post interesting or want to follow Polymorph’s activities, don’t hesitate to subscribe to our RSS feed or our Twitter account. Don’t hesitate to leave us comments, ask us questions and, of course, forward this to those who might be interested.

     
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