Mesh Component

Announcements
#60

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.

9 Likes
#61

Finally got a usage for the Mesh component in my new project. And immediately having an issue.
Setting up vertex buffer with go.set() works, but setting up a texture doesn’t. In the docs there is “tex0” property, but using it gives a runtime error. When using “texture0” instead, I can get the default texture and setting it doesn’t produce a runtime error, but the texture doesn’t change on the screen.

go.property('other_texture', resource.texture())

function init(self)
	go.set('#component', 'texture0', self.other_texture)
end

After go.set(), go.get() correctly returns the new texture reference. I tried changing tex0 to texture0 in the shader, but without success.

Is there anything wrong that I am doing?

2 Likes
#62

Not sure. @JCash and @aglitchman might know?

2 Likes
#63

I have no obvious explanation. Looking through the code it seems correct. :thinking:
If you wouldn’t mind create a small example for me I can try out, I can help out faster :pray:

2 Likes
#64

Here is a test project. In main.lua I am setting the texture for two boxes.
MeshTextureTest.zip (141.3 KB)

Thanks!

2 Likes
#65

Could it be that when calling FillRenderObject, the textures should be taken not from the mr variable, but component variable?

FillRenderObject(ro, mr->m_PrimitiveType, material, mr->m_Textures, vert_decl, vert_buf, 0, elem_count, component->m_World, component->m_RenderConstants);

change to

FillRenderObject(ro, mr->m_PrimitiveType, material, component->m_Textures, vert_decl, vert_buf, 0, elem_count, component->m_World, component->m_RenderConstants);

?

2 Likes
Vertex color (again and again)
#66

That seems likely! Compare with GetTexture which checks both arrays.

2 Likes
#67

Is it an easy fix? Do you think would it get into the next release?

2 Likes
#68

Yes I believe so.
I hope to fix it tomorrow, so that we can play more with the mesh component :slight_smile:
And it should land in the next release.

4 Likes
#69

There’s now a PR awaiting review for the texture fix.

2 Likes
#70

Trying to create a Patch-9 scalable object based on the mesh component and it’s a bit annoying to have so many duplicate vertices. A single point inside a Patch-9 object consists of 6 duplicate vertices (4 quads around the point = 8 triangles minus 2 outside ones).

I would rather much appreciate indexed vertices. Do you plan on adding this option for buffers?

3 Likes
#71

There’s currently no plan. Simply because we haven’t really thought much more than putting the feature out there to see what requests we get. Your suggestion is a good one.
If you wouldn’t mind, please add a feature request in the repo! :slight_smile:

6 Likes
#72

Just opened my project with the new editor and immediately I saw the changing textures!

4 Likes
#73

Any known performance advantage of using Mesh vs Model for simple 2D plane(quad) or circle ? (maybe for as a render buffer[render.draw] or shaders)

1 Like
#74

There’s not really much difference between them, other than that the Model has some more features (i.e. skinning).

2 Likes
#75

I would second the index buffer request :wink: Would make life a touch simpler.

3 Likes
#76

I’ve been trying to make a gameobject, that generates a vertex buffer on init. That works fine. The problem is, whenever I create another another instance of the go (either through factory or just plonking more in in the collection editor), the previous ones get the same vertices. I’m guessing it’s because all the meshes have the same .buffer file, and it’s that that is getting updated. Is it possible to create instances of a go with different vertex buffers at runtime somehow?

Flix - Procedural training and Movie making
#77

I guess this question got lost in the shuffle.

I believe the short answer is, “No”.
But the long answer is, you need to decide how many buffers you will need, max, and create a buffer file for each one in the editor, and load each one—either with a mesh component or a script property.

go.property("buf1", resource.buffer("/main/common/meshes/buffer1.buffer"))
go.property("buf2", resource.buffer("/main/common/meshes/buffer2.buffer"))
go.property("buf3", resource.buffer("/main/common/meshes/buffer3.buffer"))
go.property("buf4", resource.buffer("/main/common/meshes/buffer4.buffer"))

You can save these properties in a module for other scripts to use.

5 Likes
#78

Thanks, figured something like this out as well. Shame there isn’t a nicer way, but eh, this works as well.

1 Like
#79

I’m trying to take advantage of meshes in the “world” vertex space as the direct replacement of built-in sprites (to make some stunning fx, actually).

Is this the right way to change a buffer in a mesh?

go.property("buf", resource.buffer("/assets/meshes/star.buffer"))
-- ...
go.set("#mesh", "vertices", self.buf)

I’m asking about this because the game reports about leaked resources on shutdown:

ERROR:RESOURCE: Leaked resources:
ERROR:RESOURCE: Resource: /assets/meshes/gun.bufferc  ref count: 125
ERROR:RESOURCE: Resource: /assets/meshes/ball.bufferc  ref count: 125
ERROR:RESOURCE: Resource: /assets/meshes/eye.bufferc  ref count: 150
ERROR:RESOURCE: Resource: /assets/meshes/star.bufferc  ref count: 125

Is this a bug, or am I doing something wrong?

I attached the demo project:
issue_mesh_buf_change.zip (51.1 KB)

5 Likes