+1 on this. This is how we’re handling it for now (but it’s not pretty):
The thing is that resource.set_buffer(res, new_buffer)
sets the resource named res
to the contents of buffer
.
If all mesh components use the same resource (in you case /main/quad.bufferc
), you’ll get the scenario you now have.
As Marius hinted, there’s a way around this, by declaring resources for future use, as resource properties in your script. You can set such a resource, and then call go.set(mesh_url, "vertices", res)
to change the resource that the mesh component uses.
Ideally, soon we’ll have a way to be able to create some resources on-the-fly. It’s not something we’ve had on the roadmap yet though, and I wouldn’t want to rush into making such an api, but I can see some benefits to it for very dynamic content.
Thanks! Now I understand that I missed the resource managment guide.
Seems resource.buffer()
has not presented here:
and in the editor autocomplete too:
@dapetcu21 Now that I wanted to add the missing documentation, I wonder how you actually use that anonymous buffer?
When I use this code, I get an error, since it cannot find the resource (the hash is empty):
go.property("my_buffer", resource.buffer())
function init(self)
print("BUFFER", self.my_buffer)
go.set("#mesh", "vertices", self.my_buffer)
end
yes, get an error:
go.set failed with error code -10
Those buffers properties are connected to some .buffer
JSON files in the editor. In my case I don’t need to write into the buffers, I just use them as input for some mesh vertices (and for some manual collision calculations), but in @Dragosha’s case he could just create a bunch of files with empty data and do resource.set_buffer()
on them.
it’s ok, just need to keep in mind. Also need to remembering that each mesh component requires to one drawcall.
How to set a shader constant for Mesh?
I found this way:
msg.post("#mesh", "set_constant", {name_hash = hash("tint"), value = vmath.vector4(0.5, 0.5, 0.5, 0.5)})
Is it right?
To set shader constants, use go.set()
.
If the docs are missing, we’ll need to update them.
The ”set_constant” message is deprecated.
@Mathias_Westerdahl
Hi, there is an issue when create a mesh through a factory: original mesh blinks on the first frame at zero coordinate and going to set position on the next frame only.
See on center of this screencast (“prefab” doesn’t blink every time, because video didn’t captured at 60fps)
local p = vmath.vector3(x, y, z)
factory.create("#factory", p)
Thanks!
I’ll look into it!
Same here:
timer.delay(0.2, true, function(self)
local x = (math.random() - 0.5) * 2
local y = (math.random() - 0.5) * 2
local m = factory.create("#factory", vmath.vector3(x * 500, y * 300, 0))
end)
I downloaded the MeshTest project but I’m seeing that for the cube model that the “dae” file is missing under the path /assets/meshes/cube.dae
Can anyone explain how to create this file or why it doesn’t exist?
Thanks for any help anyone can provide
The cube.model which references the missing cube.dae is actually not used. You can remove the cube.model (and the quad.model).
Sidenote: we should probably include the cube.dae and quad.dae in builtins.
I have been developing a block-building game for a month, and it’s built using Mesh component. I have found these issues so far:
- The engine uploads Meshes vertex data to the GPU every frame. My scene contains 70K-90K triangles, 6 vertices per quad, 32 bytes per vertex; 30 fps is the target. To sum up, I see in the profiler that I waste a lot of CPU/GPU time just to upload vertex data.
- That’s why I optimize my vertex data a lot, and I use
int8
,int16
to reduce the size of the vertex, and I didn’t find how to set thenormalized
attribute. What I have to do to normalize data in vertex shaders:
var_uv = uv.xy / 32767.0;
Also, could you please point me by what criteria does Defold sort meshes? I want to draw them front-to-back, but I see in RenderDoc that my meshes are rendered back-to-front.
The redundant vertex buffer uploads are indeed an issue. We decided to ship the mesh component feature knowing this issue would eventually become a bottleneck. I’m almost finished with a fix, and it should be in the 1.2.175 release. Issue 5167.
Sorting front-to-back will be a good addition (as well as “no sorting” for e.g. particles). Issue 5168. Currently we sort on increasing Z values for game obejects. See MakeSortBuffer() and
the sort predicate.