Amen! I thought I was the only one š

]]>http://labs.qt.nokia.com/2010/05/18/a-qt-scenegraph/

It’s mostly about this same issue… optimizing OpenGL in user interfaces. It seems that in the Qt camp, they’re trying to do it with a scene-graph. I’ve only briefly skimmed through the Hybrid code, but it seems you’ve got something similar, but maybe not? Maybe it wasn’t a tree, just lists of rectangles or something. But anyway, the article above discusses what I meant with the “compositing the geometry in the right order”. I mean just that, that if I’d make a tree out of it, and then optimize the drawing order based on textures and OpenGL state changes needed.

I’m just puzzled if it really would speed up my drawing, as then I would have to do a lot of maintenance in CPU (like matrix calculations etc.) And in the case of a tree, I’d be creating a tree, and then traversing it every frame, instead of the current situation where I only traverse through the natural parent-child tree of my widgets. So, maybe a tree would be overkill, and just a list of rectangles and foreaching through that might be enough.

Oh, well. If I’ll get the time, I’ll try to go with the scene-graph tree thing…

30-50 frames is not too fast, I’m afraid. You’re likely to be heavily CPU-bound with such a batch-heavy approach. You should be aiming for drawing everything in a single batch, really. Not always possible, especially with viewports which do external rendering, but if you pack icons and text together into a single large texture, you should get down to a few batches. And if you have complex geometry to clip, you could try storing the plane equations in textures and rolling shaders which extract the proper sets of planes for each widget from them — that gives you clipping on the GPU while not having to do Sutherland-Hodgman.

As for me — I’m about to graduate, working on my insane renderer ATM: http://h3.gd/code/nucleus/

Good luck with your commercial app!

]]>I know my performance is bad anyway… I already was submitting each primitive separately, as my rendering system isn’t very clever or good. But the software clipping was just getting too heavy on my brain! I’m also doing glTranslate before every widget. I’ve been thinking that maybe I should have all my rectangles in one OpenGL space, and then somehow composite them in the right order, and propably optimize it so that rectangles with the same textures would be drawn in one batch, if possible. But I really have no idea how to write such a system. It’s easier for me to just go through my tree of rectangles and draw them all. If you have better ideas and clear explanations on how to do it better, I’d be glad to hear about it, but as I’m not an expert coder, I might just leave it in a state where I can understand it. Unless someone else is willing to code it for me/with me!

On my laptop I’m mostly getting over 50 frames per second with a couple of widgets, but it will get below 30 with a lot of text. So, it could definitely be faster.

It would be nice seeing what you are doing lately. I might try to release a small commercial application in “a couple of months”, if I’m lucky. But I’m not making any promises here, as it’s usually so that I can’t fulfill them!

]]>http://flipcode.com/archives/3D_Geometry_Primer_Chapter_1-Introduction.shtml

http://flipcode.com/archives/3D_Geometry_Primer_Chapter_2-Issue_01_Appendix.shtml

It’s really simple once you grok vector ops including the dot and cross products. E.g. your “It seems that the order of them somehow dictates which side of it will be clipped and which side will be visible” actually stems from properties of the cross product.

In a brief, given a vector [A, B, C] in R^3, all points which yield the same value of the dot product with this point lie on the same plane. So all points (x, y, z) for which Ax+By*Cz = some constant lie on a plane perpendicular to this vector. The plane equation is Ax+By+Cz+D=0, therefore you to find the plane equation on which some point (x, y, z) resides, you substitute D=-(Ax+By+Cz).

All points for which Ax+By+Cz+D > 0 are on the positive half-space of the plane. All of them for which Ax+By+Cz+D < 0 are in the negative half-space (these are the points you want clipped out).

Now, to get a plane equation defined by any 3 points (let's call them p0, p1, p2) in R^3, you first find the [A, B, C] vector (called a normal) as the cross product of (p1-p0) and (p2-p0). The order in which you specify p0, p1 and p2 defines in which direction the normal points. In a right-handed coordinate system which OpenGL uses by default, you can visualize it to yourself such that the "front side" (the side from which the normal points towards the viewer) of a triangle is the one from which you see the vertices in counter-clockwise order (that's pretty ad-hoc but should suffice for the purpose of this explanation).

Finally, when you have the normal vector (and hence A, B and C of the plane equation), you calculate D as mentioned earlier, substituting any point into the equation, hence e.g. D = -(p0.x * A + p0.y * B + p0.z * C).

BTW, it's rather unfortunate that you're switching from hand-clipping primitives to clipping planes in GL – this means that you need to submit each differently clipped primitive as a separate batch, thus hurting performance. I'm planning to do the exact opposite of what you're doing. For clipping arbitrary polygons, just go with http://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm

Oh yea, and *what Jarrett said*. Except the result/output param is by convention the last one, not the first š

]]>Instead, have the function take a double[4] to store the results, and pass one in.

void planeEquation( double[4] result, float x1, float y1…);

double[4] eq = void;

planeEquation(eq, ix1, iy1…);

glClipPlane(GL_CLIP_PLANE3, eq.ptr);