Is it possible to modify the shaders and other graphics-related implementations of the UI and 2D parts of Stride without modifying the source code?

[EsatMan]

Hello everyone, I have been researching UI textbox and font-related issues and trying to add my own shader implementation for my custom objects. However, after a period of research, I found myself stuck at the step of "defining the data sent to the shader."
It seems that the parameters to be passed are implemented in an unscalable way by the UIBatch-related source code (this implementation assumes that the type and content of the parameters and buffers to be passed are fixed).
I would like to ask if there is no way to easily extend this part of the implementation without starting from scratch to implement a complete set of UI rendering mechanisms?

[EsatMan]

I'm not sure if this approach is correct, but I've found what seems to be the most reliable solution for now.

Firstly, when writing a .sdsl file, a corresponding .cs file is automatically generated, which contains the ParameterKeys for each parameter. Relying on this instance, you can get an ObjectParameterAccessor<T> from EffectInstance.Parameters.GetAccessor(). This object is probably some kind of key as well. Then, you can set the values using EffectInstance.Parameters.Set(). The timing for setting these values is within the DrawBatchPerTexture method of the BatchBase<TDrawInfo> class. This method cannot be overridden, but the method that calls it can be, so in theory, I can inherit UIBatch and override some methods to insert my own shaders and data transfer. However, I'm still not quite sure about the details of the entire process and will continue to research.

[Basewq]

I don't think Stride's UI system currently exposes enough properties to extend the existing one easily.
Unless someone knows a better way, you are probably better off reimplementing the UI system and load your own shader effect so you can pass in the vertex data you want.

Here's an example project doing that:
https://github.com/Basewq/XenkoProofOfConcepts/tree/master/DialogueTextControlExample

[EsatMan]

Thanks for reply, I came to this conclusion, too. Seems that the default implementations not meet realistic needs.