Issue with updating vertices data of plane

So my actual use case here is (in case your first thought is why are you doing this), I have a function which draws a plane between two points in my actual code which works well, however it requires changing the position/rotation/anchor of the mesh being drawn. – I am trying to optimize some things, so I want to cache a mesh with a particular material (which I enable/play as an effect), to avoid having to rebind the material to a different mesh, because as I understand that is the expensive part. – So I am drawing a blank mesh using my drawPlane function, which calculates size/rotation correctly, and I am trying to update another mesh which already has the material bound to it, using the measurement meshes vertices data.

So basically this is the issue I’m seeing, when I try to update a plane using updateMeshPositions, it gets cut off / only renders one side of it. Comment out line 63 to see what I’m expecting it to look like.

Am I doing something wrong, or do I need to do something else also?

I got it working using a ribbon, but am having strange issues with the texture, i.e. the shader material gets applied rotated incorrectly when using a ribbon, and when I use {invertUVs} option, it ALMOST looks correct, except I’m having issues with the texture I can’t fully explain like its cutting off the top and bottom by 10% or so, even though everything is square (texture is 512x512, mesh is square). - And texture looks fine on a blank square mesh. So I’m trying using CreatePlane and updating manually in hopes that those things will go away when using different strategy.

Well updating a mesh vertex data is FAR slower then just changing the material (like 100 times slower) but maybe I do not understand completely the need.

To your question:
Just removed the painful lodash thingy :slight_smile:

You can see that your new positions are not ordered correctly if you compare with previous values. So as your face indices are not changing you have to produce the vertices in the same order: (see line 5)

@Deltakosh awesome thank you! – I forget that es6 has forEach now been using lodash each for so long, still no map though :slight_smile:

I was referring more to the GPU performance of switching the material on the mesh, isn’t switching materials of meshes discouraged because GPU has to rebind the texture to fit on the mesh or something like that? – Obviously if you are referring to setting the material in javascript land, versus updating the vertices, it will be slower, but LMK if you think it will still be slower going the update vertices.

To give a better idea, I am using it for a beam mesh, so cards shoot a beam from 1 position to another, but there will only be 1 beam ever playing at a time, and the only thing that changes on the beams, is the start and end positions, along with sometimes the material. So my thinking was to leave 1 mesh per material (disabled unless animation is playing), and then if I shoot a particular beam again, just redraw the mesh from new point A to new point B by updating the vertices.

The alternative strategies are:

  1. Draw a cached mesh between point A and point B, for each permutation of the points (which since it’s a card game, there’s not a ton of variance of positions here), then before mesh is enabled, bind whichever beam material onto it that I need to, but still probably many extra meshes sitting around disabled this way
  2. Just have 1 mesh dedicated to the beams, still update vertices, but once again, switch out the material before hand each time a different material beam is fired. But least amount of meshes this way.
  3. Don’t cache the meshes at all, create from point A to point B, don’t update vertices, but bind material onto mesh when created. At least in terms of visible lag, this feels the slowest, which is why I’ve been caching lots of mesh/material combos.

If you have strong opinions regarding performance of any of these please lmk as GPU often seem to do the opposite of what I expect it to when optimizing :slight_smile:

Well there is also a cost on the GPU for the vertex update. Furthermore Babylon.js is optimizing texture cache so updating a material will not be that expensive

But that is pure theory, the best way to know is to benchmark all solutions :smiley:

On a complete random try I would have go for solution #1

1 Like

Awesome thanks for the explanation!