Updates from September, 2016 Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 11:29 on 2016-09-16 Permalink | Reply
    Tags: , , ,   

    A bit of architecture

    Concerns sound sources located in the 3d environment.

    On the C++ side, sound::system manages all the sound sources and knowns about the location and orientation of the cam. It also contains the general configuration of the mix (gain, number of tracks, etc.).

    At each frame, the sound::system renders a serie of relations, representing the position of sources in the camera local coordinates (where are the sound sources in the user point of view, to be a bit simplier).

    The sound::system being aware of the number of tracks in the sound engine, it is able to manage efficiently wich source to send to witch track. For instance, if the number of active sound sources is higher than the number of tracks, sound::system will order the closer or the most important sources to send to the sound engine.

    On the #puredata side, the job is simplified. All tracks are similar and reacts to messages sent by sound::system.

    Each sound source knowns about the sound file to load. This info is sent onnce when the source becomes active : activated status.

    Sound::system is able to handle 2 types of communication.

    • In edition, it sends osc messages to puredata, the program with graphical interface. This allows musician to work live on the sound.
    • In production, it sends the messages to libpd internally.

    This 2 modes implies using custom objects in pd that are able to use both modes.

    sound-system-overview

    Thanks to @yacine_sebti for his expertise in pd.

    Currently in development in #peel.

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

    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 16:49 on 2016-09-14 Permalink | Reply
    Tags: , , Virtualbox   

    Deployment using a virtual machine.

    Thanks to virtual box, i was able to test an appllcation compiled on my desktop, and it works 🙂

    Obviously, it’s exactly the same OS, and the way i did it is NOT clean at all: i just copy/paste all the libraries in the bin folder. Hopefully, linux & ogre are kind enough to run that smoothly.

    The application is a utils to test models exported from blender.

    virtualmachine-01

    virtualmachine-02

    The installation of an os in virtualbox required a adjustement in the BIOS. See How to fix verr_vmx_msr_all_vmx_disabled to install Ubuntu on VirtualBox for details.

    More to come very soon.

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

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

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

    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

     
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