display.newMesh bug when vertices are initialised at 0

Audio and Graphics
#1

Hi, I’m using display.newMesh to draw a trail behind my character and I’m in trouble. For perfomance purpose, I want to avoid to make a new mesh each frame as I can just initialize my mesh at the start of my app and move the vertices to follow my character position. My basic approach is to initialize all vertices at 0,0 coordinates when creating the mesh and then set the vertices at correct positions each frame. But I’m facing a strange “bug” and I would like to know what’s is happening exactly. I’ve made a real short peace of code to show you the problem.

Here is a basic mesh that displays a white square at the topleft corner of the screen :

mesh = display.newMesh( { x=0.01, y=0.01, mode = "strip", vertices = { 0,0, 0,0, 0,0, 0,0 } }) mesh.path:setVertex(1, 0, 0) mesh.path:setVertex(2, 0, 100) mesh.path:setVertex(3, 100, 0) mesh.path:setVertex(4, 100, 100) print(mesh.path:getVertex(4)) print(mesh.path:getVertexOffset())

If I remove the x=0.01 and y = 0.01 params of the display.newMesh method and set them to 0, it does not work anymore, the mesh is not displayed and I want to know why? Hell it’s just a 0.01 offset. I’m 100% sure something is hapenning behind the scene with vertex offset being equal to zero or something divided by zero?

The debug log print the same output in both case but in one case I see my mesh and in the other case I don’t.

I can also remove the x=0.01 and y = 0.01 and put random positions for vertices in the display.newMesh as they will be set correctly on each frame but I want to know why I can’t set all of them to 0,0. What are the hidden calculations?

If I just display.newMesh everyframe and set correct positions directly in the “constructor” and not by calling setVertex each frame, of course it works. But I really want to avoid calling display.newMesh each frame.

#2

  1. Thanks for posting a clear question with simple example.

  2. This is just my opinion, but it seems like the real problem is the initial mesh.  I feel like a 0,0,0,0… mesh is illegal in some way.

I modified your code as follows and it seems work OK:

mesh = display.newMesh( { x=0, y=0, mode = "strip", vertices = { 0,0, 1,0, 0,1, 1,1 } })
#3

Yes, that’s how I solved the problem too, but I just wanted to know what’s happening behind the scene when setting such 0,0,0,0,0… :slight_smile:

#4

Perhaps corona need to support a mesh 0,0,0,0,0…

#5

i prefer to start with something like this for a quad (in strip order):

vertices = { -1,-1, -1, 1, 1,-1, 1, 1 }

because it’ll keep your offset at 0,0 forever, so you can just ignore them.  vertices are not recentered as moved after initial creation, so offset isn’t recalc’d either.  now you can freely move around mesh.x/y and/or setVertex() to wherever you want and it should hopefully “just make sense” without having to subtract out an offset.

#6

  1. Thanks for posting a clear question with simple example.

  2. This is just my opinion, but it seems like the real problem is the initial mesh.  I feel like a 0,0,0,0… mesh is illegal in some way.

I modified your code as follows and it seems work OK:

mesh = display.newMesh( { x=0, y=0, mode = "strip", vertices = { 0,0, 1,0, 0,1, 1,1 } })
#7

Yes, that’s how I solved the problem too, but I just wanted to know what’s happening behind the scene when setting such 0,0,0,0,0… :slight_smile:

#8

Perhaps corona need to support a mesh 0,0,0,0,0…

#9

i prefer to start with something like this for a quad (in strip order):

vertices = { -1,-1, -1, 1, 1,-1, 1, 1 }

because it’ll keep your offset at 0,0 forever, so you can just ignore them.  vertices are not recentered as moved after initial creation, so offset isn’t recalc’d either.  now you can freely move around mesh.x/y and/or setVertex() to wherever you want and it should hopefully “just make sense” without having to subtract out an offset.