Is it possible to use a shader material with mesh-instance-2d?

dotted

After nosing around I find that supposedly using a canvas item material should work but all I get is white blankness

dotted

Here is a simple example: I am trying to use mesh-instance-2d with the mesh-shapes offered (and normally used in 3d).

How can one make the rectangle black as the canvas material should(?) make it?

It seems like this should be straight forward.

No I cannot use a sprite.

xyz

Assign a CanvasItemMaterial to the mesh and use modulate property to adjust the color (in inspector under CanvasItem/Visibility)

Alternatively you can assign ShaderMaterial instead and write a simple shader that will set the color:

shader_type canvas_item;
void fragment(){
	COLOR = vec4(0.0, 0.0, 0.0, 1.0);
}

dotted

If you inspect the example project I have a canvas item material applied.

Ah so it is buried under 'visibility' which without any distinction is now a expandable section. I mean WTF visibility is normally a boolean in 3d context in the editor

More muddled and inefficient UX. Why isn't it labeled with something consistent like Color or Rendering options?

Thanks.

dotted

@xyz said: Assign a CanvasItemMaterial to the mesh and use modulate property to adjust the color (in inspector under CanvasItem/Visibility)

Alternatively you can assign ShaderMaterial instead and write a simple shader that will set the color:
shader_type canvas_item;
void fragment(){
	COLOR = vec4(0.0, 0.0, 0.0, 1.0);
}

Wait, so one must conjure a canvas item material to even have a option to apply Color under 'visibility'?

crack UX.

dotted

So the next question is: Is there a way to apply a texture to the2d mesh and color it in ways parallel to 3d meshes?

Normally this would all be under the albedo property of a material but the 2d version has no such similarity

Oh OK now you add a texture to the texture property.

wow. three scattered opaque UI elements to configure to simply use mesh 2d.

ouch. :(

xyz

Properties are not scattered. They are grouped by parent classes in node's inheritance chain. This is quite convenient when your workflow is a mix of coding and tweaks via gui. Which is almost always.

dotted

@xyz said: Properties are not scattered. They are grouped by parent classes in node's inheritance chain. This is quite convenient when your workflow is a mix of coding and tweaks via gui. Which is almost always.

I don't agree and I mean scattered differently from what you are thinking of. Grouped by inheritance vs functionality are distinct and at odds when thinking in terms of function.

A 3d mesh material setup is clear (aka discoverable) and the relevant rendering parameters are embodied by its material. The 2d mesh scatters this functionality over canvas item material, 'visibility>modulation' and its texture. As a result, I can't simply define a material resource that specifies its color, texture and compositing and apply it as a single property.

I will also point out the numerous queries to godot-engine, reddit and elsewhere regarding mesh2d configuration that simply don't exist for the 3d variant. all of this comes down it someone pointing out the details you mentioned above.

xyz

@dotted said: I don't agree and I mean scattered differently from what you are thinking of. Grouped by inheritance vs functionality are distinct and at odds when thinking in terms of function.

A 3d mesh material setup is clear (aka discoverable) and the relevant rendering parameters are embodied by its material. The 2d mesh scatters this functionality over canvas item material, 'visibility>modulation' and its texture. As a result, I can't simply define a material resource that specifies its color, texture and compositing and apply it as a single property.

You have to understand that 3d mesh and 2d mesh are different beasts, despite the name similarity. This will become apparent if you compare inheritance chains for both classes. 2d mesh needs to conform to the canvas item concept while 3d mesh adheres to visual instance concept. So it's not really a UX issue but rather an architectural one.

You can have a single resource controlling the appearance though. Simply assign a shader material with a simple shader that handles color, texture etc.. All shader's uniforms will be conveniently grouped one after another.

dotted

@xyz said: You have to understand that 3d mesh and 2d mesh are different beasts, despite the name similarity. This will become apparent if you compare inheritance chains for both classes. 2d mesh needs to conform to the canvas item concept while 3d mesh adheres to visual instance concept. So it's not really a UX issue but rather an architectural one.

Please note I have written several back end modules

Again, I point to the numerous questions peppering reddit or godotengine, and note that it means they cannot make progress in towards their goals.

The 'architectural issue' is in their way. It isn't clear how to setup the appearance of a mesh2d.

You can have a single resource controlling the appearance though. Simply assign a shader material with a simple shader that handles color, texture etc.. All shader's uniforms will be conveniently grouped one after another.

Yes, and I also could add a native module material doing all those things, it would then be a built it within the existing architecture that would make UX better, which is my point.

xyz

@dotted said: Yes, and I also could add a native module material doing all those things, it would then be a built it within the existing architecture that would make UX better, which is my point.

Well, what's stopping you? If you think many people would benefit from it, just go ahead and make the module.

Megalomaniak

Don't forget the pull request.

edit: I should be more specific. If you think you have an idea how to improve the UX and have the skills to implement then you should first of all open a issue/topic on the proposals repo(and mention in the proposal that you intend to work on this too) then go ahead and make a fork of godot and start implementing it.

Once you feel it's at a testable state open a pull request. It won't be immediately merged but now the implementation can be tested and proposal properly evaluated.

dotted

@xyz said:

@dotted said: Yes, and I also could add a native module material doing all those things, it would then be a built it within the existing architecture that would make UX better, which is my point.

Well, what's stopping you? If you think many people would benefit from it, just go ahead and make the module.

Because I got stuff to do.

Megalomaniak

You could still write up a proposal on the proposals repo to start the discussion there. Talking about it here is probably going to achieve little.