Vertex Buffer problem

3DRaddict · 12-03-2014 09:03 PM

I'm currently experiencing a problem accessing selected vertices in a simple grid mesh.
I'm trying one of Method A or Method B to do so:

Method A)

PHP Code:

// Method A
// --------
   // ------------------------------------------------------------------------------------
   // translating a vertex using hardware vertex buffer
   // ------------------------------------------------------------------------------------
   Byte *data=mesh.parts(0).render.vtxLock(LOCK_READ_WRITE);
   Int vtx_size=mesh.parts(0).render.vtxSize();
   Int pos_ofs=mesh.parts(0).render.vtxOfs(VTX_POS);
   Int tex0_ofs=mesh.parts(0).render.vtxOfs(VTX_TEX0);
 
   Vec pos;
   
   for(int i = 0; i < m; i++)
   {
      for(int j = 0; j < n; j++)
      {
         int k=i*n+j;
         pos=*(Vec*)(data + pos_ofs + k*vtx_size);
         
         if( i==0 && j==0) // edit to change (i,j) vertex
            *((Vec*)(data + pos_ofs + k*vtx_size)) = Vec(pos.x, 5, pos.z); // raise selected vertex by 5 units
         else 
            *((Vec*)(data + pos_ofs + k*vtx_size)) = Vec(pos.x, 0, pos.z); // all level 
      }
   }
   mesh.parts(0).render.vtxUnlock(); // NB unlock after all read/write is completed // all level
   
   // -------------------------------------------------------------------------------------- 

Method B)

PHP Code:

// Method B
// --------
   // ------------------------------------------------------------------------------------
   // translating a vertex on same mesh using CPU (software)
   // ------------------------------------------------------------------------------------
   Vec pos;
   
   for(int i = 0; i < m; i++)
   {
      for(int j = 0; j < n; j++)
      {
         int k=i*n+j;
         pos=mesh.parts(0).base.vtx.pos(k);
         
         if( i==0 && j==0) // edit to change (i,j) vertex
            mesh.parts(0).base.vtx.pos(k) = Vec(pos.x, 5, pos.z); // raise selected vertex by 5 units
         else
            mesh.parts(0).base.vtx.pos(k) = Vec(pos.x, 0, pos.z);
         
      }
   }
   mesh.setRender();
   
   // -------------------------------------------------------------------------------------- 

I've tested each method using the same 5x9 vertex grid.
For each method I've raised each of the corner vertices (0,0) , (0,8) , (4,0) and (4,8) five units above ground zero.
Here are the results for each method:

Method B)
vertex(0,0)
[Image: Problem_B_0_0.jpg]

vertex(0,8)
[Image: Problem_B_0_8.jpg]

vertex(4,0)
[Image: Problem_B_4_0.jpg]

vertex(4,8)
[Image: Problem_B_4_8.jpg]

Method A)
vertex(0,0)
[Image: Problem_A_0_0.jpg]

vertex(0,8)
[Image: Problem_A_0_8.jpg]

vertex(4,0)
[Image: Problem_A_4_0.jpg]

vertex(4,8)
[Image: Problem_A_4_8.jpg]

As you can see 'Method B' makes sense and works as expected.
'Method A' is nonsensical, and I fail to understand why the same vertex references do not give identical results as 'Method B'
This is probably the reason why I am not getting nice round ripples in my 'Custom Shader Training Project.

Here is the small demo project of this problem for investigation purposes.
VertexBufferProblem project files

3DRaddict · 12-05-2014 04:13 PM

@Esenthel:
I really would appreciate the courtesy of an acknowledgement or reply to my query.
After all, I did take the trouble to provide a fairly detailed example of my problem.

Am I doing something stoopid and illogical?
If I am, then please put me right.

If not, then please provide an explanation as to why it is not working similar to Method B, and a possible workaround.

Rofar · 12-05-2014 10:31 PM

I feel sure the Greg will not ignore your post. He probably has just not had time to look at it yet.

In taking a quick look at your 2 different methods, it looks like you are making the assumption that the vertex data in the hardware buffer is aligned in a sequential manor and I suspect that is not the case. When you access the vertices in the software buffer in Method B, you are referencing a list of vertices that are aligned sequentially.

I suspect the graphics driver does some optimization to the data and the order of the vertices in the buffer is not in the same sequence as the software buffer.

**Esenthel** · 12-06-2014 01:29 AM

Hello

When calling mesh setRender it has a parameter Bool optimize=true , which works by reordering the triangles and vertexes for more optimal performance.

3DRaddict · 12-06-2014 06:15 AM

At last... perfect round ripples! grin

just by changing 'myWater.setRender()' to 'myWater.setRender(false)'

I would of saved myself one helluva lot of bother and time if I'd known this sooner!

fatcoder · 12-06-2014 08:04 AM

Esenthel Wrote:Bool optimize=true , which works by reordering the triangles and vertexes for more optimal performance.

Maybe that should be added to the Mesh setRender header comment. smile

**Esenthel** · 12-06-2014 08:07 AM

Will be included in next release.

Vertex Buffer problem
Author	Message