Chaise pagholz in blender, with @louise.
Updates from October, 2016 Toggle Comment Threads | Keyboard Shortcuts
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
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
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:
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!
Long time no seen!
After fixing tiny and absolutly not sexy issues in bullet code, programming went to an even less fancy topic: efficient temporary storage of udp packets.
Indeed, OSC messages (basically udp messages) arrives asynchronously. The display thread is running at ~60fps, but messages can pop in at any time. To avoid a display thread interruption each time a message is received, they have to be stored until the main thread request them.
The first approach was to push them in a std::vector. If the main thread never requested them, this vector might eventually become VERY long. To solve that, setting a maximum size seemed to be a good option. Each time a new message is received, if the vector is longer than maximum, the first element, witch is also the oldest, is deleted.
There’s 2 important performance issues in this approach (fixed by the new one :)):
- removing the first item ( =>resizing the vector) and push back an item at each reception ( =>resizing the vector once again) is not efficient at all;
- read and write access to the same object, implying that you can not write while reading and reverse.
Sooner in my life, someone told me about ring buffer. The name was nice and the idea behind was appealing!
Here is what has been implemented in the class that receives and parses the OSC messages (readable text below the image, click to enlarge).
polymorph::POscReceiver – ring buffer logic
POscReceiver uses ring buffer to store received messages temporarily.
If its capacity is 10, it uses an array of 10 PMessageData.
When the maximum number of messages is reached, the oldest message is overwritten.
The position of the oldest one is shifted by one each time a new message is stored in an “overflowed” array.
polymorph::POscReceiver – read and write buffer
POscReceiver uses 2 ring buffers.
Reception and parsing are managed in a separated thread.
Buffers are swapped when the main process request a read access.
Documentation about how to prepare meshes (structure, materials, etc.) usable by bullet in polymorph engine.
The documentation of the project is not yet ready, as you might see if you surf a bit in the wiki…
Precise object grabbing, require a bit of math, but it worst the headache!
After some posts with images, schemas and long technical descriptions, here is the result.
The chain is breaking when there’s too much stress along the links…
First generation of documentation with doxygen and … OMG! it’s a huge mess!
Defining an architecture and clean namespaces is really required, and must to be done as soon as possible.
Doc is here: polymorph.cool/doxygen
Demo with of a chain using bullet:
Meshes (displayable and physical) are desgned in #blender by @louise !
All bullet’s primitives are now available:
- & btConeShape.
The link with blender is make easier via 2 python scripts ( see Two python scripts… ).
A default fallback to convex hulls still has to be done.