Updates from July, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • xuv 22:39 on 2016-07-29 Permalink | Reply
    Tags: , open source, , Unity3D, Unreal Engine,   

    Polymorph weekly news #3 

    Going for the third week now, I scheduled an appointment with @balt, the second developer of Polymorph Engine.

    I never met Balthazar and so this was more an introduction meeting and a discussion to get to know each other. The other reason is Balthazar has tasks to do on the Polymorph Engine but he has not found the time yet to get to it, so it was pointless to talk about what he had achieved so far. Nonetheless we did talk about it and what he sees in Polymorph and that’s equally interesting.

    So Balthazar de Tonnac is a developer and system administrator from Brussels. He has worked with artists helping them integrate open source tools in their workflow. He also has knowledge in Blender, Unreal Engine and Unity3D. One of his previous work was to develop a visualizer for atk.io. ATK! is an audiovisual duo, composed of Ofer Smilansky and Isjtar, known for doing live performances using light and music in relation to architecture. Balthazar created an interactive application for ATK! using the Unreal Engine. This permits them to visualize their set up and show what it could look like to their clients. Using the Untity3D engine, Balthazar is now working on a VR application to help companies visualize the installation of heavy industrial equipment in their final environment.

    All this experience with proprietary solutions is very useful for Polymorph and it’s also the reason why he wants to invest time and energy into it. As Balthazar says it, there is an incredible amount of resources and tools already available in the free/libre and open source world regarding the development of games and interactive applications. But where proprietary still beats everyone is that there is no packaged solution yet. Ogre3D is a very powerful engine but it’s very complex to start using it. There is an enormous amount of code that needs to be rewritten every time someone wants to start a project and this should not be the case.

    Also, we need something that can compile for all platforms and from whatever platform you’re working on. And to achieve that, a lot of configuration needs to be done. Ogre is not easy and one needs to dig into its documentation first, which is also a little scattered all over the place. But it’s a very promising tool and, as we can see, @frankiezafe and Pieter have achieved a big step this week (check previous posts by François).

    Balthazar believes that Polymorph is working on an incredible and very ambitious project. Something that the open source community needs and that in the long term could be really successful, but it also requires a great amount of resources. He sees the Polymorph Engine as an open source alternative to Unreal Engine or Unity3D. But for that, so much work needs to be done in terms of ease of access and more intuitive interfaces. The problem with Ogre is that, whatever you want to achieve, you have to do it with code. There is no preview window, no icon that tells you where your camera or your lights are. You have to write it, compile it and then see it running. Which makes game creation very tedious. Balthazar is hoping that with Polymorph Engine, those aspects could be solved, one day.

    For now, though, building PEEL, the first open source game project from Polymorph, is the real goal and the best strategy according to him. It allows the team to see what’s working and what needs to be improved. And once Polymorph has something to show, than the bigger goals can be put on the table. But as Balthazar says it: “All we need now is a very good Makefile”.

  • frankiezafe 16:14 on 2016-07-29 Permalink | Reply
    Tags: , , ,   

    Complete Ogre.2.0 example!

    Very glad that the week ends with a good result: the basics are done: import and loading of objects, creation of lamps, input & frame listeners. Next week will be MUCH more cool!

    The main reason of my joy is due to the fact there is no available example of orge.2.0 available online.

    Workflow from blender to ogre is rather straight by using https://bitbucket.org/LSS_NorthWind/blender2ogre.

    OGRE Render Window_644

    With the help of a FPS style camera, it’s a bit easier to navigate in the world…

    OGRE Render Window_644

    OGRE Render Window_644

    • xuv 18:13 on 2016-07-29 Permalink | Reply

      Maybe you could post this on the Ogre3D mailnig-list or something. Get others to test it and maybe contribute back. Just a suggestion.

  • frankiezafe 22:51 on 2016-07-26 Permalink | Reply
    Tags: , ,   

    Design of startup dialog for ogre : it might seems unrelevant, but i’m quite glad to have change the background image and colors of this window. I feel more at home 🙂


  • frankiezafe 18:29 on 2016-07-25 Permalink | Reply
    Tags: ,   

    Starting to work on the famous “Empty example”. The code is really basic but clean. It’s also the first pushes in the polymorph-engine repository!
    Empty example for Ogre 2.0

    Repository: https://bitbucket.org/frankiezafe/polymorph-engine

    See Source > example.2.0 for the code.

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

    Polymorph weekly news #2 


    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: , , , , ,   

    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 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.


    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.


    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.


    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.

  • frankiezafe 12:44 on 2016-07-15 Permalink | Reply
    Tags: ,   

    The graphical research of yesterday was driven by a structure problem: how to describe progammatically game objects more complex then a tube with 2 ends. This forced me to review the analysis i’ve made before , based on simple geometries.
    Each game object will now be a group of several specialised objects: a segment (the main part), and “joints”, containing pushers and switches.



    Joint structure


  • frankiezafe 19:56 on 2016-07-14 Permalink | Reply
    Tags: , ,   

    Graphical research regarding the lighting + different types of elements that might be useful.




  • frankiezafe 11:55 on 2016-07-14 Permalink | Reply
    Tags: , ,   

    Useful repository to compile Ogre3d dependencies : https://bitbucket.org/cabalistic/ogredeps
    Once done, just adapt the cmake param OGRE_DEPENDENCIES_DIRSelection_982

  • frankiezafe 20:08 on 2016-07-13 Permalink | Reply
    Tags: , ,   

    Coding with openframeworks and inkscape – Faces, cube and segments are implemented, tomorrow i start building the gap. OF is ideal to develop standalone libs.
    Workspace 1_981

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