Jit.gl.node anomalies
Hi everyone, again. Since I’ve been using Jitter a lot lately, I’ve been running into some strange behavior from time to time. Maybe it’s my mistake, or maybe it’s a bug to fix. I’m posting here to learn more about it and to get some opinion from who knows more about.
I’ve noticed that jit.gl.node, when used as a 3D shapes aggregator, exhibits two “suspicious” behaviors:
1. The shapes created with jit.gl.node don’t seem stable in the 3D plane of jit.world. They move on their own in strange ways when using jit.gl.handle with the mouse.
(In the patch I built, try zooming in and out of the 3D space with the mouse, and you’ll see that the shapes created with the left algorithm jit.gl.multiple+jit.gl.gridshape always remain consistent and stay in their positions, while those created with the right algorithm, which also uses jit.gl.node → jit.gl.multiple+jit.gl.node with 2 jit.gl.gridshape, do not remain consistent in space)
Maybe i need to link jit.gl.node to jit.gl.handle too in some way?
2. Jit.gl.node slows A LOT down the calculation in a way that is not linked only to the number of 3d vertices used, but there is more. Is that extra necessary or bug?
(In the patch I’ve built, try entering a high value for N (a high value for N depends on your computer: 300 generated shapes might be high for some and low for others) and generate N shapes using the algorithm on the left (jit.gl.multiple + jit.gl.gridshape), and notice how the movement of the jit.gl.handle remains Always smooth (low computational cost even with high number of shapes generated); however, even if you set N/2 in the algorithm on the right that uses jit.gl.node (so, since jit.gl.node uses 2 jit.gl.gridshape instances, the total number of vertices used remains the same with N/2), there is a massive slowdown. At first, I thought there was a bottleneck between the GPU and CPU, but when you remove the jit.gl.node, this doesn’t happen, even when the number of shapes constructed, and thus the number of vertices used with jit.gl.multiple, is very high.
What's going on?
both issues (incorrect transforms, and poor fps) can be alleviated by "flattening" the jit.gl.node multiple target. matrixoutput mode 2 and a jit.concat @concatdim 1 does the trick in this particular case.
The jit.gl.node / jit.gl.multiple interaction could be updated to do this "flattening" internally, and I'll make a ticket to investigate this.
If for some reason this doesn't get you unstuck with your actual patch, please provide more details on the actual use case.
Hey Robert, thanks for answering my question. I created this patch as an example to illustrate the problem, and I see how you solved it. In my actual workflow, however, I'm not using two jit.gl.gridshape grouped with jit.gl.node and then feed into jit.gl.multiple; instead, I'm using two shapes I created myself with 2 jit.gl.mesh, which I then group with jit.gl.node and pass to jit.gl.multiple. It seems I can’t use @outputmatrix parameter on the 2 jit.gl.mesh.
you should be able to simply apply transforms to the matrices via jit.gen and then concat with jit.concat in the same way as demonstrated above. alternatively just use a second jit.gl.multiple. happy to demonstrate either if it's not clear. feel free to post your patch.
not sure about this jit.gl.node issue, happy to look at a patch (that doesn't involve jit.gl.multiple multiplying a jit.gl.node)
Hey Robert, I solved both the problems I wrote about with your help. I replaced jit.gl.node with 2 jit.gl.multiple. I deleted the part of message about 2d/3d jit.gl.node problem because I tested it and I wasn't right about it.