Issue #784 resolved

Set values in Mesh:setVertex to not change if they are not supplied.

created an issue

If I just change the position of a vertex, while leaving the image coordinates the same, I do not want to get and set the image coordinates every single time.

I also do not want to change to color back to (255, 255, 255, 255) unless otherwise stated every single time, so perhaps they should behave the same way.

Comments (5)

  1. Alex Szpakowski

    On the one hand this would be pretty convenient if you don't keep the original table used to create the Mesh around.

    On the other hand, this would prevent some potential performance optimizations for Meshes. Getting data back from the GPU is always much slower than sending it - in some cases it could block for several milliseconds because the CPU would have to wait on the GPU to finish its current queue. To avoid this, LÖVE keeps an identical copy of the mesh data on the CPU-side for quick access, but it might not in all cases.

    I think this is sort of related to issue #768. Right now all the data for a single vertex (position, texture coordinates, and color) is packed together, but it makes it more difficult for just the colors of all vertices to be changed efficiently, for example.

    The other option would be to have the vertex data separated, so all the colors for all vertices would be separate from all the positions for the vertices (and the API would match.) If you aren't changing these individual components then it can reduce performance compared to the current method though.

    I think ideally the API would let you have control over how the vertex data is set up so you can choose the best layout for what you want to do, but I'm not quite sure what a nice API for that would look like.

  2. muddmaker reporter

    You would not necessarily be getting it from memory, you would just not change it.

    -- This is how it currently is (with a default of 0):
    function setFoos(foo1, ...)
        foo1 = foo1 or 0 -- This uses both a bool check and a set (both local)
        foo[1] = foo1 -- And another set (stored somewhere in ram)
    -- This is how it should be (with no default):
    function setFoos(foo1, ...)
        if foo1 then -- A bool check of a local value
            foo[1] = foo1 -- And a set (somewhere in ram)

    I know the code is in c++, but these principles can still apply. It also would be more efficient because it uses less setting.

    If there is something behind the scenes that prevents this from happening, then maybe it is more efficient to add methods for individual sections, like Mesh:setVertexPosition(x,y).

  3. Alex Szpakowski

    You would not necessarily be getting it from memory, you would just not change it.

    Well, in theory at least.

    In addition to the stuff about performance related to data layout in OpenGL I talked about, there's also the way LÖVE handles vertices in Meshes in the first place. The way they're written right now, the function to set a vertex replaces the entire vertex (this is also related to the way vertices are packed together instead of vertex components being separate.)

    The function might be able to be changed without hurting performance in the case where the entire vertex data is changed at once, but even then the current Mesh API is set up in general for operating on whole vertices instead of components. I'd rather fix the API to allow for both ways (which includes having different data layouts for the different ways) and have custom attributes at the same time.

    tl;dr: there are a lot of factors affecting the current API, and there is a lot of room for improvement but it should be done in a way that is carefully thought out to be good for performance, ease-of-use, and the extensibility that's a philosophy of Lua and possible with the GPU's APIs. I want to do it right. :)

  4. Alex Szpakowski

    Added the ability to have custom vertex attributes in Meshes (resolves issue #768.)

    Added new variants: newMesh(vertexformat, vertices [, drawmode, meshusage]) and newMesh(vertexformat, numvertices [, drawmode, meshusage]).

    Replaced the regular variants with newMesh(vertices [, drawmode, meshusage]) and newMesh(numvertices [, drawmode, meshusage]). To use an image or canvas with a mesh, use Mesh:setTexture.

    vertexformat is a table with the following prototype: { {attributename, datatype, components}, {attributename, datatype, components}, ... }

    Where attributename is the name of the vertex attribute (can be the built-in names 'VertexPosition', 'VertexTexCoord', or 'VertexColor', or a custom name for use in a vertex shader), datatype is the type of values used for the attribute ('float' or 'byte'), and components is the number of components in the vertex attribute (between 1 and 4.)

    The vertex format is used to determine the layout of the vertices in the mesh, for example the 'regular' newMesh variants use this vertex format: format = { {"VertexPosition", "float", 2}, {"VertexTexCoord", "float", 2}, {"VertexColor", "byte", 4}, }

    The mesh usage parameter accepts the same constants as the spritebatch usage hint in - "dynamic", "static", and "stream".

    Mesh:setVertex now sets all vertex attributes for a specific vertex in the Mesh.

    Added Mesh:setVertexAttribute(vertexindex, attributeindex, attributevalue1, ...), which sets the values for a specific vertex attribute in a specific vertex in the Mesh (resolves issue #784.)

    Added Mesh:getVertexFormat and Mesh:flush.

    Added Mesh:setAttributeEnabled(attributename, enable) and Mesh:isAttributeEnabled(attributename), to enable or disable the use of a specific attribute when drawing the Mesh.

    Added Mesh:attachAttribute(attributename, mesh), which makes the Mesh use a vertex attribute from another mesh when drawing the Mesh. This can be used to separate out vertex attributes which are updated at different rates into different meshes, and to share vertex data between multiple meshes.

    Removed Mesh:setVertices, Mesh:getVertices, and Mesh:setVertexColors.

    → <<cset f02774821e49>>

  5. Log in to comment