Page 1 of 1

[2.1] Dynamic geometry

Posted: Fri Oct 12, 2018 10:58 am
by Slicky
So I am playing around with the dynamic geometry sample. I mostly understand it.

Here is the question. If say for example I wanted to do lines or points how would I accomplish that? Since Ogre isn't OpenGL or DirectX directly there isn't a book or online tutorial and the wiki is virtually non existent for 2.0+ stuff. I find myself using OpenGL just because I am also playing with mixing in OpenGL renders.

Anyway, should I just read generic online stuff or is there a specific approach to say for example draw points and lines the Ogre way?

Re: [2.1] Dynamic geometry

Posted: Fri Oct 12, 2018 2:11 pm
by al2950
Its easy! If you have looked at the Dynamic Geometry then you will have seen the following line

Code: Select all

        Ogre::VertexArrayObject *vao = vaoManager->createVertexArrayObject(
                    vertexBuffers, indexBuffer, Ogre::OT_TRIANGLE_LIST );
Ogre::OT_TRIANGLE_LIST is the key point here. It could be any of the following

Code: Select all

    enum OperationType
    {
        /// A list of points, 1 vertex per point
        OT_POINT_LIST = 1,
        /// A list of lines, 2 vertices per line
        OT_LINE_LIST = 2,
        /// A strip of connected lines, 1 vertex per line plus 1 start vertex
        OT_LINE_STRIP = 3,
        /// A list of triangles, 3 vertices per triangle
        OT_TRIANGLE_LIST = 4,
        /// A strip of triangles, 3 vertices for the first triangle, and 1 per triangle after that
        OT_TRIANGLE_STRIP = 5,
        /// A fan of triangles, 3 vertices for the first triangle, and 1 per triangle after that
        OT_TRIANGLE_FAN = 6,
        /// Patch control point operations, used with tessellation stages
        OT_PATCH_1_CONTROL_POINT    = 7,
        OT_PATCH_2_CONTROL_POINT    = 8,
        OT_PATCH_3_CONTROL_POINT    = 9,
        OT_PATCH_4_CONTROL_POINT    = 10,
        OT_PATCH_5_CONTROL_POINT    = 11,
        OT_PATCH_6_CONTROL_POINT    = 12,
        OT_PATCH_7_CONTROL_POINT    = 13,
        OT_PATCH_8_CONTROL_POINT    = 14,
        OT_PATCH_9_CONTROL_POINT    = 15,
        OT_PATCH_10_CONTROL_POINT   = 16,
        OT_PATCH_11_CONTROL_POINT   = 17,
        OT_PATCH_12_CONTROL_POINT   = 18,
        OT_PATCH_13_CONTROL_POINT   = 19,
        OT_PATCH_14_CONTROL_POINT   = 20,
        OT_PATCH_15_CONTROL_POINT   = 21,
        OT_PATCH_16_CONTROL_POINT   = 22,
        OT_PATCH_17_CONTROL_POINT   = 23,
        OT_PATCH_18_CONTROL_POINT   = 24,
        OT_PATCH_19_CONTROL_POINT   = 25,
        OT_PATCH_20_CONTROL_POINT   = 26,
        OT_PATCH_21_CONTROL_POINT   = 27,
        OT_PATCH_22_CONTROL_POINT   = 28,
        OT_PATCH_23_CONTROL_POINT   = 29,
        OT_PATCH_24_CONTROL_POINT   = 30,
        OT_PATCH_25_CONTROL_POINT   = 31,
        OT_PATCH_26_CONTROL_POINT   = 32,
        OT_PATCH_27_CONTROL_POINT   = 33,
        OT_PATCH_28_CONTROL_POINT   = 34,
        OT_PATCH_29_CONTROL_POINT   = 35,
        OT_PATCH_30_CONTROL_POINT   = 36,
        OT_PATCH_31_CONTROL_POINT   = 37,
        OT_PATCH_32_CONTROL_POINT   = 38
    };
You are interested in OT_POINT_LIST, OT_LINE_LIST or OT_LINE_STRIP. Of course your index buffer will have to make sense for each type, ie if its a line list, it should specify a list of lines with 2 vertices per line.

Re: [2.1] Dynamic geometry

Posted: Fri Oct 12, 2018 2:14 pm
by Slicky
Ok thanks for that I will give it a try. Often things I think might be easy tend to become a rabbit hole.

Re: [2.1] Dynamic geometry

Posted: Fri Oct 12, 2018 8:35 pm
by Slicky
I am making some progress using lines. However, I've noticed that if I don't change the vertices values of them in the update function they do not all get drawn. I then went back to the DynamicGeometry example and if I just provide the same values each time the cube (in the examples case) no longer renders as a cube. Is this expected behaviour?

Code: Select all

//First dynamic buffer example.

        //Dynamic buffers assume you will be fully uploading the entire buffer's contents
        //every time you map them.
        //"Partially" mapping or filling the buffer will not result in desired results
        //(data uploaded in previous frames will get mixed with with the
        //new data you're uploading)

        //You should NEVER read from cubeVertices pointer. Beware that something as innocent as
        //++(*cubeVertices) or cubeVertices[0] += 1; or cubesVertices[1] = cubesVertices[0];
        //implies reading from the mapped memory.
        //
        //Reading from this memory may return garbage, may return old data (from previous frames)
        //and will probably be *very* slow since the memory region is often write combined.
        //Sometimes you need to check the assembly to see the compiler isn't reading from
        //that memory even though the C++ code doesn't.
        float * RESTRICT_ALIAS cubeVertices = reinterpret_cast<float*RESTRICT_ALIAS>(
                    mDynamicVertexBuffer[0]->map( 0, mDynamicVertexBuffer[0]->getNumElements() ) );

        for( size_t i=0; i<8; ++i )
        {
//             cubeVertices[0] = c_originalVertices[i].px * cosAlpha - c_originalVertices[i].py * sinAlpha;
//             cubeVertices[1] = c_originalVertices[i].px * sinAlpha + c_originalVertices[i].py * cosAlpha;
//             cubeVertices[2] = c_originalVertices[i].pz;
// 
//             cubeVertices[3] = c_originalVertices[i].nx * cosAlpha - c_originalVertices[i].ny * sinAlpha;
//             cubeVertices[4] = c_originalVertices[i].nx * sinAlpha + c_originalVertices[i].ny * cosAlpha;
//             cubeVertices[5] = c_originalVertices[i].nz;

			cubeVertices[0] = c_originalVertices[i].px ;
			cubeVertices[1] = c_originalVertices[i].px ;
			cubeVertices[2] = c_originalVertices[i].pz;

			cubeVertices[3] = c_originalVertices[i].nx ;
			cubeVertices[4] = c_originalVertices[i].nx ;
			cubeVertices[5] = c_originalVertices[i].nz;

            cubeVertices += 6;
        }

        mDynamicVertexBuffer[0]->unmap( Ogre::UO_KEEP_PERSISTENT );
Image

Re: [2.1] Dynamic geometry

Posted: Mon Oct 15, 2018 3:14 pm
by al2950
I am not sure I understand. The code you are using:

Code: Select all

cubeVertices[0] = c_originalVertices[i].px ;
cubeVertices[1] = c_originalVertices[i].px ;
cubeVertices[2] = c_originalVertices[i].pz;

cubeVertices[3] = c_originalVertices[i].nx ;
cubeVertices[4] = c_originalVertices[i].nx ;
cubeVertices[5] = c_originalVertices[i].nz;
Does not make sense.... its only using x, and z coordinates of the original, it misses out y. I think you may have a copy and paste mistake. The original code was doing some extra maths which you have deleted which effectively ends up creating a 2d shape not a 3d shape!

It should be:

Code: Select all

cubeVertices[0] = c_originalVertices[i].px;
cubeVertices[1] = c_originalVertices[i].py;
cubeVertices[2] = c_originalVertices[i].pz;

cubeVertices[3] = c_originalVertices[i].nx;
cubeVertices[4] = c_originalVertices[i].ny;
cubeVertices[5] = c_originalVertices[i].nz;
 

Re: [2.1] Dynamic geometry

Posted: Mon Oct 15, 2018 4:09 pm
by Slicky
You are right I did just copy then cut off the extra calculations.

It was more to test why some lines that I was creating don't appear unless I change their positions. I will have to look closely if I am doing some other simple mistake. I thought I'd test the original cube not being updated to make sure it still rendered. I'll check back with findings.