I am rolling my own GUI as an experient. I want it to be really simple and run flawlessly on mobile devices.
I noticed that currently each panel/image (Geometry in principle) that I have is rendered as separate object, which kills the framerate on mobiles. So I would like to know how other GUI authors overcome this?
Hey, thanks for reply!
I have looked also into Lemur for inspiration, but for learning purposes I just decided to go from scratch and only reuse if I really get stuck (probably will reuse Lemur’s multitouch picking anyway).
In any case I simplified my wishes to 2D so I am currently making a game in GUI node and I figured that rolling my own GUI would be the most sane thing currently.
Have just tried BatchNode and must admit that it works a bit strange. Even though I create new material instance for each of my panels and assign different colors/textures to them, they still get batched together (I usually get just one big black or randomly colored quad instead of separate colored quads). Also, how to solve picking when geometries are batched?
Batch node still leaves the geometries separate so picking should still work. At least in theory.
As to the other, I don’t know why it would batch stuff that is using different parameters. In fact, there used to be the opposite bug where it wouldn’t batch things even if they had the same parameters.
Else I cannot say why in your case it’s not working.
Maybe any idea on how to debug batching?
I am kinda not able to get the list of batches from node.
I am not even able to implement my own BatchNode, since the existing one accesses some fields and functions of Geometry class that are package private. I am trying to batch based on actual instance of the material instead of comparing all Material properties with contentEquals() function, so I could manually control that.
For now I extended Material class to override this function, but still looks like it is batching some things in a wrong way. Probably because not all materials in a scene are actually extended - BitmapText for example.
Could we update BatchNode to provide extensible method for material comparison?
Changing the material of a batched geometry is not supposed to be supported. And actually when you change the material, you should have an UnsupportedOperationException. Here…since you change the color of the material, there is no real way to detect the change anyway.
If there is no change in the already batched geoms in the subgraph the batchNode won’t rebatch them when you call batch()(it will only append newly added geoms to the existing batch)
That said, you can force a geom to be marked as “rebatch this” using the unassociateFromGroupNode() method.
Note that it will rebatch the whole subgraph though.
So basically :
g3.unassociateFromGroupNode(); // <- here we go
I mean, my issue is that when using BatchNode for GUI parent node, batches are created in a weird way. I would like to have more control over that (for example to define exactly which geometries in the tree of nodes will get batched and which will be left alone). Maybe I am using the wrong tool and BatchNode is actually not the solution for this. My use-case is kinda: have a whole tree of nodes/geometries that correspond to GUI layout, have them batched automatically according to the knowledge that I provide. So don’t batch dynamic parts of GUI or parts that will later change color/material, just batch the static parts (back panels, static indicators, background).
I have this GUI with 3 panels, each is a node with more elements attached (name, creature picture, properties, etc.).
Each quad is kinda its own object. Each creature is random and it can change with time.
What I would like is for example to batch only these white-transparent back-quads behind the text, because they never change. So go from 3 x 4 = 12 draw calls to just 1.
But after I batch the root node of those panels I get this result:
Note that some properties (like creature texture and selection quad) are added later after other geometries are already batched.
Maybe I am not supposed to batch different geometries from different node subtrees? Or maybe the batched geometry mesh doesn’t take into account local transforms of geometries in subnodes?
What do you advise to solve this problem?
Heheh, thank you nehon, tried it and it works fine!
Well, almost fine in my case.
The result of batching those white-transparent text backgrounds:
The layering is obviously mixed up now, but this could as well be my fault, because the batched geometries become new children of the node for which I manage the Z coordinate. I suppose even using Lemur’s layering system wouldn’t help here?
Also for future adventurers in this direction, picking doesn’t work as well on batched geometries. Probably would need special handling for that also, to somehow find the “actual” clicked geometry.
Any idea how to implement that?
In my opinion, if BatchedNode isn’t passing collideWith on to the real children then it’s broken.
I know there’s a way to use BatchNode that deletes the children after batching… making sure you aren’t doing it that way? It might be nice to see a little code to confirm and in case it jogs @nehon’s brain.
You don’t have to. Node’s collideWith method will call collideWith on all the Node’s children.
In case of the batchNode those children are : the batches’ geometries, and the original geometries.
The thing is, the batches’s geoms overlap with the original geoms so you might get them first (or not) in your collision result.
You can identify a batch geometry by its name. It will be of the form <BatchNodeName>-batch<number>.
You can check the name of the geometry in the collision result and exclude those that match this pattern.