Before read, please consider two points:
1 - I know that UMG is some sort of WIP.
2 - I’m just talking about what I could get from reading engine code and experimentation.
Watching the code I’ve seen that without extend FSlateDrawElement and FSlateBatch and Batcher I’ll not achieve “Slate” rendering.
I’ve seen that Slate has some types defined to work with some sort of separated render of Elements (FSlateVertex, SlateIndex and such things) trough the Payloads Batching to each and some sort of “SlateDrawer” that builds geometry and renders it into the DrawElement layer. Would be amazing get access to such thing without need to deal with the F<Name> guys, dummy classes and pointers needed to get then working.
UMG/Slate code by now has 2 usages to exactly the same thing because FDrawElement::MakeCustom() doesn’t give us access to populate a Payload with Vertex and Indexes data (at least by what I’ve seen) it just get an Element that holds and creates its own FCanvas and writes to the Widget Backbuffer, what is a pain is to make it working as average coder. lol
But on digging the FViewport looking for some samples, I got to an inner MakeCustom() and a DrawRenderThread(), so, we have two EElementTypes doing almost the same thing.
I don’t know if it’s a good idea, but is there some way to ease the access to rendering from ET_Viewport and turn ET_Custom into some way to use that nice SlateElementRendering?
If it’s made this way because needs be this way, is there any chance of add an ET_Custom2DGeometry… to DrawElement::MakeCustom2DGeometry… and so on?
Here we go (feel free to point any logic/design errors or improvements)…
That’s my goal:
But, of course I would like to make this on UMG to get all hittests, input events and other features, how you can see it’s an UI Element that will be composed by many UWidgets stacked, and on an inner layer I would need an element that is not part “yet” from UMG…
Some desambiguation:
By UMG Built Geometries I mean the kind of proccess described on ElementBatcher.cpp, lines 150 - 164.
Since none of the FDrawElements::Make<whatever>() predicts such element, I thought about use the MakeCustom, but the only code sample I could get regarding ISlateCustomElement was the Engine FPreviewElement and FDebugCanvasDrawer, both doesn’t draws the polygon I need neither use UMG Built Geometries technique.
ElementBatcher as it is just predicts the EElementTypes drawing rules, personally I think it’s a waste of a so much elegant designed way to draw UI Elements as radar charts, area charts, and so on…
So my suggestion was about “also” get some easy way to just send some direct instructions to fill the BatchVertices and BatchIndices array, and send a FSlateBrush with a texture instead of need to deal with FCanvas, renderthread limitations… I confess that until watching all Epic did, I’m struggling to put MakeCustom() to work. lol
Hi Matt…
Well, you should be busy, I did a workaround to get the widget working trough a shader, I’m just worried now about how much a 177 instructions shader will impact on performance (it was placed inside an Image Widget, and Dinamically MIT).
Anyway, I now just depend uppon get buttons working with mouse (this problem is on another thread.
Because it’s a “HACK” mad, if slate get some easier way to draw custom polygons we’ll not need drawing triangles in the shader without access VertexBuffers neither use canvas to draw to a rendertarget “mimetizing” what slate/UMG already does internally.
