## Tagged: dev Toggle Comment Threads | Keyboard Shortcuts

• #### frankiezafe 20:42 on 2017-04-17 Permalink | Reply Tags: dev, OSC ( 6 ), Pure Data ( 14 ), serialisation ( 2 ), Tuning Scores ( 9 )

To prepare the work session between Tomas Turine and Lisa Nelson, I prepared a OSC serialisation of all the objects available in the 3D world, including mouse and cameras, and built an interface in pd to visualise and use the data.

• #### frankiezafe 17:46 on 2017-03-18 Permalink | Reply Tags: dev, generative ( 9 ), math ( 4 ), Openframeworks ( 8 ), random, research ( 8 )

• 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: algorithm ( 12 ), C++ ( 6 ), dev, disrupted cities ( 10 ), generative ( 9 ), Openframeworks ( 8 )

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.

• #### frankiezafe 21:10 on 2017-02-22 Permalink | Reply Tags: dev, game engine ( 15 ), material ( 3 ), Ogre3D ( 50 )

Several hours of work later, the class PMaterial is fully integrated to PNode. This part has been tricky: materials and textures are shared objects, managed by managers below the objects.

The approach is to create PMaterial on demand, when you call pnode.getMaterial, for instance. Once created, it stays in the pnode until you destroy it or overwrite the material with another.

This limits the memory consumption and force the coder to always retrieve the material pointer from the pnode, and not to store it.

Another cool feature of the pnode.getMaterial is that the material can be created RT if the mesh doesn’t specify one.

On the PMaterial level, it is becoming very easy to add the methods to access the different layers of the Ogre material.

For instance, here is the code used to create the 2 materials applied on the balls in the image above:

```pmat_even.create( "Test", "Nice material" );
pmat_even.diffuse( 1, 0, 0 );
// activation of fog
pmat_even.fogMode( Ogre::FOG_EXP );
pmat_even.fogDensity( 0.1 );
pmat_even.fogDistance( 10, 15 );
pmat_even.fogColor( 0.4, 0.4, 0.4 ); // same as background
// cloning pmat_even in pmat_odd
pmat_odd.clone( &pmat_even );
pmat_odd.fogColor( 0.8, 0.8, 0.8 );
// adding a pass on the material
// there are now 2 passes in technique 0 of this material
uint tid = 0;
uint pid = 1;
pmat_odd.emissive( 1,0,1, tid,pid );
pmat_odd.polygon( Ogre::PM_WIREFRAME, tid,pid );
```

It’s super easy to clone a material, at creation or via the clone method. The second pass of the odd material have to be set manually. Passes are not cloneable (yet?).

As you may notice, mentioning the technique or pass to attack is optional. If your material has only one technique and one pass, the call is very short. Once you beginning to build a more complex material, adding 2 uint at the end of your arguments should not be too difficult…

The material of the cube is also created manually:

```PMaterial pmat2( pmat_even );
// disabling the fog
pmat2.fogMode( Ogre::FOG_NONE );
pmat2.diffuse( 1, 1, 1 );
// checking the number of textures
if ( pmat2.getTextureUnitCount( ) == 0 ) {
} else {
// modifying the first one
pmat2.setTexture( "General", "child-computer.jpg" );
}
cube.material( &pmat2, true );
```

More, soon!

• #### frankiezafe 13:38 on 2017-02-17 Permalink | Reply Tags: dev, documentation ( 12 ), game engine ( 15 ), Ogre3D ( 50 )

new class in package: PMaterial.

This class is an helper that simplify the access to the multiple layers of Ogre’s materials.
There are 3 levels in a material:

• technique
• pass
• texture units

The usual Ogre way to access to modify a pass diffuse is looking like this:

```Ogre::MaterialPtr ptr =  Ogre::MaterialManager::getSingleton( ).load( "mat", "group" );
ptr.getTechnique(0)->getPass(0)->setDiffuse( 1,0,0 );
```

Using PMaterial, it looks like this:

```polymorph::PMaterial ptr;
ptr.diffuse( 1,0,0 );
```

Selection of technique and pass is optional. The image above shows the fog configuration:

```pmat.fogMode( Ogre::FOG_EXP );
pmat.fogDensity( 0.1 );
pmat.fogDistance( 10, 30 );
pmat.fogColor( 0.4, 0.4, 0.4 );
```

All methods are not yet there, do not worry, they will come soon.

• #### frankiezafe 22:39 on 2017-02-10 Permalink | Reply Tags: analysis ( 6 ), C++ ( 6 ), dev, Ogre3D ( 50 ), opengl ( 2 ), tools ( 3 )

I’ve learned something really important today: an OpenGL context can be accessed by one and ONLY one thread! See Under what circumstances would glGenBuffers/glGenBuffersARB fail?.

And this is the first time I feel annoyed by the singleton approach of Ogre3D. In my asset converter util, I use Ogre object, the MeshManager mainly, to convert xml files to .mesh files. Due to the limitation of OpenGL and the singleton pattern, I can’t declare a new OpenGL context in my conversion thread by using the Ogre managers…

I struggled for several hours with that before find the post on stackoverflow.

This implies a freeze during mesh conversion, wich prevent me to animate a progress bar and keeping the conversion strickly in background.

I’ll work on the loading and display of the processed meshes next week.

• #### frankiezafe 23:05 on 2017-01-31 Permalink | Reply Tags: dev, game dev ( 24 ), Pure Data ( 14 ), sound ( 5 )

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 19:56 on 2017-01-29 Permalink | Reply Tags: Camera, dev, matrix, Ogre3D ( 50 ), tutorial ( 7 )

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: dev, game dev ( 24 ), graphics ( 16 ), Ogre3D ( 50 ), 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 20:13 on 2017-01-10 Permalink | Reply Tags: dev, Ogre3D ( 50 ), tutorial ( 7 )

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