Tagged: Peel Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 18:08 on 2016-08-10 Permalink | Reply
    Tags: , , Peel   

    Time to dig into the hardware skinning, and shadow casting…

    Sides of the elevated cube are not black, texture wise, but the engine didn’t received any information about the need for an update. Therefore, using a shader for the shadow is mandatory.

    screenshot08102016_190647543

     
  • frankiezafe 16:58 on 2016-08-07 Permalink | Reply
    Tags: , , , , Peel   

    Too much complexity.

    On the way home yesterday, i sketched the required modification to make to the joint generation algorithm to generate normales. And, sadly, i came to a point where the hours of works and analysis involved were too high, taking into account that this technique requires a shader to animate the model (another tricky point). The whole idea of generating everything programmatically is sexy, really, but i’ll drop it for now.

    Today, i opened blender 1h30 ago, and here is the result: object is UVed and boned, ready to be animated and will react correctly to lighting.

    joint-in-blender-cropped

    About generative objects, an old idea is running my brain for a while: it will come back soon!

     
  • frankiezafe 13:44 on 2016-08-06 Permalink | Reply
    Tags: , , , Peel   

    Joint version 1: uvs are (nearly) ok.

    The error in vertices calculation is to have only one vertices at each corner on the bottom plane. This involves have only 1 uv coordinate for these vertices, where 2 are required – see uvunwrap here below.

    Each joint can receive a configuration to deform the height of its faces. this will certainly be done via shader later.

    That’s it for this week, back on monday for other adventures!

    OGRE Render Window_668

    OGRE Render Window_666

    OGRE Render Window_667

     
  • frankiezafe 17:51 on 2016-08-04 Permalink | Reply
    Tags: , , Peel   

    First usage of BaseApplication.

    The development of Peel has started today by the implementation of the Joint class. A joint is the base of the puzzle. It is generated programmatically > no mesh import.

    first-step-with-ogre

     
  • xuv 22:39 on 2016-07-29 Permalink | Reply
    Tags: , open source, Peel, 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”.

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

    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.

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

    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.

    General

    oo_structure_002

    Joint structure

    oo_structure_003

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

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

    modules-with-lighting_001

    modules-with-lighting_002

    modules-with-lighting_003

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

    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

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

    Working on PEEL basic concepts, defining the programmatic objects.
    oo_structure_001

     
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