Cant move GreaseLineMesh that is an InstanceMesh of other GreaseLineMesh

It looks like the position does not effect the instanced Version of the grease line?

I have a situation where we are saving out grease lines as glbs and them are re-importing them (hence why in this PG you see me make a new material from the vertexData.)

How can I first have the position on the greaseLine instanced mesh take effect?

cc @roland the amazing mind behind the greased line

1 Like

I’ll check your PG a bit later but here is a PG which use the createInstance function for now:

You can’t modify the VertexData directly because GreasedLine builds its own buffers according to the properties provided to the builder function or to the constructor of the mesh.

You can use these properties to get or set colors and points:

            const colors = instance.greasedLineMaterial.colors
            const colorPointers = instance.colorPointers
            const colorsTexture = instance.greasedLineMaterial.colorsTexture
            const points = instance.points

            console.log('colorPointers', colorPointers)
            console.log('colors', colors)
            console.log('colorsTexture', colorsTexture)
            console.log('points', points)

The three other props are obvious, I think.

Let me know if you need more info,

How can you set vertex alphas then? The colors only accepts Color3s?

And why would setting the vertex color buffer prevent the instance from going into the correct position when that has nothing to do with where the points are located?

In this example I’m not modifying any of that but the instance still will not reposition? Even going into the inspector and trying to move it does nothing?

Also can you explain the colors vs the colors textures? Its kind of confusing to have three difference references to colors. Id imagine you only need the colorsTexture and pointers or just the colors, seems kinda redundant?

Also after looking at your example vs mine I was able to deduce that create Instance function only works if you are using paths.

Vertex colors are supported:

Sorry, I was not quite precise when I wrote that you can’t set the VertexData. However when you are dealing with PositionKind it’s a different story. There are three other buffers created when setting the points. These buffers are needed for the camera facing feature.

This is seems to be a bug in GreasedLineMesh because it works with GreasedLineRibbonMesh so it’s not about paths. I wil check it. I’ve created a lot of PG’s for testing but I’m sure I didn’t cover all scenarios. Thank you for pointing out the issue.

There are multiple examples in the docs how to use these features:

If you provide the colors option it will create a colorsTexture but you can set the texture manually as well. The colorsTexture can be shared between multiple lines. So you can create the texture manually and set it to multiple lines however if you create each line with colors it will create one colorsTexture for each line.


Perfect explanation thank you!

1 Like

@Evgeni_Popov Hi!

EDIT: using finalWorld instead of world seems to solve the problem.

Can you please have a quick look at this PG?

Do you have any idea why is it loosing world in the shader when the instance is created? If you don’t I will start to debug. :wink:

Thank you!

1 Like

Indeed, you should always use finalWorld, which will contain the right world matrix in all circumstances (morph, instance, thin instance, skinning), whereas world is not always defined (as you experienced!).

1 Like

@Evgeni_Popov My visualization tests started to fail for the ShaderMaterial after I changed to finalWorld as you suggested and I tracked down the problem. If the mesh has instances it needs finalWorld but if there are no instances of the mesh it needs world. I tried to look at the generated shader code for some defines I can use to distinguish the two situations but I didn’t find anything. How to correctly deal with this issue? Thanks!

EDIT: My bad, INSTANCES:wink:

If you are using the #include<instancesVertex> include it should work, because the code of the include is:

	mat4 finalWorld = mat4(world0, world1, world2, world3);
	#if defined(PREPASS_VELOCITY) || defined(VELOCITY)
		mat4 finalPreviousWorld = mat4(previousWorld0, previousWorld1, previousWorld2, previousWorld3);
	    finalWorld = world * finalWorld;
		#if defined(PREPASS_VELOCITY) || defined(VELOCITY)
			finalPreviousWorld = previousWorld * finalPreviousWorld;
	mat4 finalWorld = world;
	#if defined(PREPASS_VELOCITY) || defined(VELOCITY)
        mat4 finalPreviousWorld = previousWorld;

So, finalWorld is defined with or without instances.