Updates from January, 2017 Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 23:05 on 2017-01-31 Permalink | Reply
    Tags: , , ,   

    3D – puredata communication

    Starting to work on the first external to enable an easy integration of puredata in the polymorph engine.

    The idea is simple: you place a pobject_in object in your patch to receive position (translation), rotation and scale of the 3D objects.

    In edit mode, meaning you have pd with ui and the game running aside, info will go through OSC, allowing a RT modification of the patch.

    In release mode, the patch will be loaded by the application thanks to libpd.

    The pobject_in will work seamlessly in the 2 modes: in edition, you just add an udpreceive object and link it to pobject_in. Once edition is done, if you want to be clean, you just remove the udpreceive. In release, the info will come through a special receive object, polymorph_pobject_in_RT, already included in the pobject_in.

    LibPD being integrated since several month it shouldn’t be too hard to adapt the required methods on the C++ side. I’ll work on this tomorrow, I hope to have a cool demo for sunday!

     
  • frankiezafe 15:45 on 2017-01-30 Permalink | Reply
    Tags: , , , ,   

    Polymorph @FOSDEM

    Hello to all,

    I’m (very) glad to remind you that Polymorph and its engine will be presented at FOSDEM this year, in the devroom “Open Game Development“.

    The presentation is focused on the engine, why we did it and how we propose to conceive interactive 3D and video games.

    I hope to see you there, even if all presentations are streamed 🙂

    Best regards,

    François Zajéga

    Practical info:

    • date: Sunday 5th of February 2017
    • hour: 15h30 – 15h55
    • location: ULB, Campus du Solbosch, Av. F. D. Roosevelt 50, 1050 Bruxelles, room AW1.126

    For complete practical information: https://fosdem.org/2017/practical/transportation/

     
  • frankiezafe 19:56 on 2017-01-29 Permalink | Reply
    Tags: Camera, , matrix, ,   

    New example showing how to go from world space to camera space.

    A bit of explanation.

    The black sphere is attached to the pink camera. Therefore, it is located in the camera space, meaning that its position, rotation and scale depends on the camera ones. By default, the sphere is static in the point of view of pink camera.

    The pink camera is rotating around the world center.

    An empty, represented as a XYZ axis, follows the mouse position.
    If the space bar is hit, position & orientation of the empty is converted into camera coordinates.

    Vector3 p = custom_cam.worldToCam( empty.getTrans( ) );
    Quaternion q = custom_cam.worldToCam( empty.getOrientation( ) );
    

    The values are then applied on the sphere:

    ball_cam.move( p );
    ball_cam.orientation( q );
    

    By doing so, the ball is placed at the exact same location and orientation as the empty, relatively to the pink camera.

    note: the 256×256 square at the top left of the images is made with overlay manager, not yet simplified in polymorph namespace.

    The example is available in samples/0.1/example.cam_space

     
  • frankiezafe 22:03 on 2017-01-22 Permalink | Reply
    Tags: , , , , RTT   

    Currently working on PCamera class (a class to manage … camera!). The new samples/0.1/example.cam shows how to create one and render it onto a texture.

    In these images, the pink texture on the cube is the rendering of the camera rotating in the center of the scene, the tall pink cone. It is very ogry to send the camera to the texture:


    RenderTexture * rt = texture->getBuffer( )->getRenderTarget( );
    custom_wp = compositorMgr->addWorkspace( sceneMgr, rt, custom_cam.getOgreCam( ), cwName, true );
    custom_mat->getTechnique( 0 )->getPass( 0 )->createTextureUnitState( )->setTexture( texture );

    There should be a way to make this a bit more handy, I’ll look into it sooner.

     
  • frankiezafe 13:08 on 2017-01-17 Permalink | Reply
    Tags: , , , , , ,   

    screenshot01172017_125756932

    New example ready for skeletons manipulation.

    In the example, the skeleton debugging is enabled by default. It shows the bones hierarchy and the local orientation of each bone.

    There is 3 transformation spaces for bones, inherited from Ogre3D:

    • LOCAL
    • PARENT
    • WORLD

    All methods to get or set orientation, scale and position are sensitive to this value, except the moveBone methods, not yet finished.

    The example shows also the different ways to retrieve information about the skeleton: list of bone’s name, list of bone objects, access via name, id or pointer, etc.

    The beautiful model i destroy if from Sophie Khan and distributed by #additivism.

     
  • eurydice 11:23 on 2017-01-17 Permalink | Reply
    Tags: , ,   

    AMazingGameSS0

    AMazingGameSS1

    First little game without pretention done while learning Openframeworks and C++ during my traineeship !

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

    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!

     
  • frankiezafe 17:33 on 2017-01-12 Permalink | Reply
    Tags: , , , , ,   

    screenshot01122017_171204940

    Preparation of a 3d model for skeleton example. The model is from Sophie Kahn and distributed by #additivism (their selection is really good!).

    Image of the model in the 3d additivism cookbook:

    rhino

    First step was to reduce (a lot) the number of faces of the model ( around 75% ), generate a UV map and link it to an armature, in blender, obviously. Note that the armature is displayed using Envelope. I never use it to work, but i find it lovely for screenshots.

    rhino-screenshot-002

    rhino-screenshot-001

    The skinning was tricky, due to the mesh mess. There are no arms for instance.

    After the export and conversion via OgreXMLconverter, the model has been easily imported in the engine.

    A lot of fine-tuning has been done on the material, to display solid and wireframe + having a light emission of the wireframe pass in the shadows.

    Here is the material definition:

    pass sophiekhan-mat
    {
    	ambient 0.8 0.8 0.8 1.0
    	diffuse 0.8 0.8 0.8 1.0
    	specular 0.02 0.05 0.05 1.0 0.1
    	emissive 0.0 0.0 0.0 1.0
    
    	alpha_to_coverage off
    	colour_write on
    	cull_hardware clockwise
    	depth_check on
    	depth_func less_equal
    	depth_write on
    	illumination_stage 
    	light_clip_planes off
    	light_scissor off
    	lighting on
    	normalise_normals off
    	polygon_mode solid
    	scene_blend one zero
    	scene_blend_op add
    	shading gouraud
    	transparent_sorting on
    
    }
    pass sophiekhan-wf
    {
    	ambient 0.0 0.0 0.0 1.0
    	diffuse 0.85 0.7 0.75 1.0
    	specular 0.5 0.5 0.5 1.0 30.2
    	emissive 0.31 0.26 0.2 1.0
    	polygon_mode wireframe
    	transparent_sorting on
    }
    

    Other screenshots:

    screenshot01122017_171414743

    screenshot01122017_171208673

     
  • frankiezafe 19:24 on 2017-01-11 Permalink | Reply
    Tags: , , glitch, , , , ,   

    screenshot01112017_142211314

    screenshot01112017_142217797

    screenshot01112017_142624367

    screenshot01112017_150924058

    screenshot01112017_150940710

    screenshot01112017_150945944

    screenshot01112017_155054726

    screenshot01112017_155102542

    screenshot01112017_160911261

    screenshot01112017_160926611

    screenshot01112017_161703380

    screenshot01112017_161732695

    screenshot01112017_161750328

    screenshot01112017_161757179

    screenshot01112017_161810645

    screenshot01112017_170923978

    screenshot01112017_171052215

    screenshot01112017_171406017

    screenshot01112017_172418511

    screenshot01112017_185234271

    Cool day today: the creation of the example.glitch was quite fun.
    The example demonstrate a bit more extensively the usage of the ogre’s compositor (see here) and the interaction with shaders.

    If you test the example, ckeck CustomApp::createCompositor: you’ll find comments about how to interact with the shader’suniform.

    The superb model in this scene is gearthing4 by shivinteger, distributed by #additivism.

     
    • xuv 00:57 on 2017-01-12 Permalink | Reply

      Wow. Looks awesome. Indeed, add some sound and it’s a finished piece. 🙂

  • frankiezafe 20:13 on 2017-01-10 Permalink | Reply
    Tags: , ,   

    screenshot01102017_200308117

    screenshot01102017_200310217

    screenshot01102017_200315718

    screenshot01102017_200318951

    screenshot01102017_200328133

    screenshot01102017_200347400

    New example about compositor and shader (example.compositor).

    The example concerns the definition of a custom compositor. In Ogre3d, a compositor is a serie of post-processing nodes attached to the camera. It is the place where the image displayed at each frame is created.

    In the example, there’s a shader attach to the background of the window that renders a blurred circle. The shader params can be modifed RT via the mouse.

    • Moving the mouse change the red and green channels of the center color.
    • Dragging with left button modify the radius of the circle.
    • Dragging with right button modify the center of the circle.
      • Compositor is a really strong feature of Ogre, even if it’s a quite difficult one!

     
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