Tagged: Openframeworks Toggle Comment Threads | Keyboard Shortcuts

  • frankiezafe 20:22 on 2017-06-14 Permalink | Reply
    Tags: , computational geometry, , , Openframeworks   

    Straight skeleton C++ implementation 

    Long time no seen!

    Lot of things happens in may and june, that’s one of the reason of this long silence. The other is the library i’m working on to generate the maps of Disrupted Cities. Implementing a complex process in an efficient way is harsh. But it starts to works nicely.

    A small openframeworks demonstrates the part of the lib dedicated to shrink the 2D shapes, used later in the map to generate the block of houses.

    Shrink Demo on bitbucket.

    See you soon for more.

  • frankiezafe 18:58 on 2017-03-23 Permalink | Reply
    Tags: , , , , Openframeworks,   

    Road network generation: the gif gives you an idea of the procedure executed in ~300 milliseconds by the c++.

    With a deformation:

  • frankiezafe 21:35 on 2017-03-19 Permalink | Reply
    Tags: , configuration, , , Openframeworks   

    Different kind of network generated by 3 configurations (images go 2 by 2).

    Note: add a variation on the roads length (min, max will be ok).

  • frankiezafe 20:50 on 2017-03-18 Permalink | Reply
    Tags: , , , Openframeworks   

    Result of different configuration of network at each pass. In each image, you see the road network alone and the network with the control grid. I’m proud to mention that the generation time on a big network is taking around 500 millis, something easy to hide with a small transition.

    Here, there are 3 + an initial road (the thick one). In each pass, the road becomes smaller and thinner.

    It’s also possible to generate the same network with depth enabled. It’s becoming very complex to follow visually, but it makes no mistake 🙂

  • frankiezafe 17:46 on 2017-03-18 Permalink | Reply
    Tags: , , , Openframeworks, random,   

    Reviewing the road generation system.

    • generation of normal and tangent for each segment (cyan & purple vectors): they can be used easily to generate a new road starting from any point;
    • a million better random selection, based on the formula: X1 = a*X0 + b % m;

    This random generation merits a bit of attention.

    Until now, i was randomly picking a new start point from an existing road to create a new road. The process is consuming, and there is no guarantee to avoid picking several time the same point on the same road.

    With the formula above, found in the great numberphile channel (see below), I attribute once and for all a random to each road’s dot. The particularity of this random generation is that it will NEVER repeat two times the same value in one sequence. Once generated, my dots have a number in the range [0,1], with a linear distribution.

    For instance, in a line having 10 dots (and therefore 9 segments), each dot will have a random number between 0 and 1. If you order the list of dots by random values, and compare the gap between each sorted values, the average gap will be 0.1!

    The way to use this random number is straight forward. If you want to generate a secondary road on 50% of the dot of the first one, you just have to loop over these number and check wherever the random value of the dot is < 0.5. If the distribution was not linear, doing this would not guarantee to create on sub-road every two dots. As it is, you can just specify the percentage, all random calculation has already been done, and in a more controlled way then ofRandomuf() does it.

    This formula requires big prime numbers (>10000) to be placed at a and b. Here is the source i used: list of primes.

  • frankiezafe 20:34 on 2017-03-11 Permalink | Reply
    Tags: , , , , , Openframeworks   

    flat network (no Z)

    slight Z curvature

    strong Z curvature

    strong Z curvature

    strong Z curvature

    After a bit of struggle with the management of a 3d grid, the advantage is there: it’s now easy to generate a road network in 3D, with automatic connection of the streets while generating them. It’s a simple brute force & unsupervised generation algorithm, but it is memory efficient and error less.

    Just to explain a bit the images above: the cubes are the cells of the road grid. Only the required one are created during road generation. There are connected to each other to speed up the proximity tests once a now road segment is added. I’ll measure the generation time soon, but it’s already quite fast regarding to the first test made several days ago in processing.

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



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

  • xuv 20:00 on 2016-08-05 Permalink | Reply
    Tags: , , Openframeworks,   

    Polymorph weekly news #4 

    OGRE Render Window_658

    Fourth week already and half way? Let’s see.

    So back to interviewing @frankiezafe, our project leader and main motor behind the Polymorph Engine (haha, I’m so funny). So Frankie and I had a little chat, which was supposed to last one hour but ended up taking two. Although this post won’t be as long, I promise. But I was keen to know how projects were going from his point of view.

    As you may have seen from his last posts, there is now what is called an Empty example for Ogre 2.0 running. It’s not that empty because it has a camera, lights and objects floating in empty space, but you get the idea. It’s a basic demo to start working from. It’s also a great tool to check that things compile in all platforms. So far, François has it running on Linux. It should run on Windows and other platform are coming. By the way, if you are interested, please have a go at it and send feedback. There is now documentation and code on the repository. And while it’s not yet a complete Empty example, it should get you started. And we’re excited to read what you think of it.

    So François is now step by step going deeper in the Ogre3d documentation. His experience with Openframeworks proved very valuable here. Because he already knows how the GPU (graphic card) is handling images, as he says it:

    You throw a bag of numbers at it in the correct format and it spits out an image.

    Although handling Ogre is a lot more different than Openframeworks. If Openframeworks is an excellent introduction to C++ and a very flexible tool, Ogre is way more complex and structured. It requires a good understanding of high level C++ concepts and related software design patterns, which makes Ogre a powerful tool indeed, but harder to learn. I could sense that this was kind of a hard step for François, but it also came with its moments of joy, when he shared with me the code that defines the camera movement.

        if ( mouse_right_dragged ) {
            Real rspeed = 0.005f;
            Vector2 diff = mouse_right_current - mouse_right_pick;
            Quaternion qo = cam->getOrientation();
            Quaternion qx( Radian( -diff.y * draw_event.timeSinceLastFrame * rspeed ), Vector3( 1,0,0 ) );
            Quaternion qy( Radian( -diff.x * draw_event.timeSinceLastFrame * rspeed ), Vector3( 0,1,0 ) );
            cam->setOrientation( qo * qx * qy );

    These little things in Ogre make it so much easier, said François.

    His work from this week focused on code to generate mesh, materials and texture on-the-fly, meaning things are not preloaded from files at startup, but generated by the engine itself when the game runs. François is taking inspiration from Mad Max tutorials, but “cleaning up” the code, as he says it, and creating basic classes from it. Making it then reusable code for following projects. It may not look like it, but all this is necessary for the development of PEEL, the first game of Polymorph.

    PEEL should come out at the end of August, hence my introductory mention of “half way”. Polymorph exists since 4 weeks and should deliver an alpha verison of its first game in 4 weeks. There is many steps until then, but Pieter and François are making progress. And Daniel Perez has agreed to make a Pure-Data patch for spatialized sound. So stay tuned and see you next week.


    • frankiezafe 10:26 on 2016-08-09 Permalink | Reply

      Much better version of the camera controls, thanks to qknight (https://github.com/qknight/ogre-examples)

      Real rspeed = 0.005f;
      Vector2 diff = mouse_right_current – mouse_right_pick;
      cam->yaw( Radian( -diff.x * draw_event.timeSinceLastFrame * rspeed ) );
      cam->pitch( Radian( -diff.y * draw_event.timeSinceLastFrame * rspeed ) );

      Already in example.2.0

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

    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