[Qt3d] Slow rendering of thousands of curves
-
I would like to pick an arbitrary number of face normals drawn at each facet of a mesh.
Once the number of normals (drawn as individual lines each with a QObjectPicker attached) exceeds a couple of thousand instances, the rendering speed slows to a crawl.
I feel like there must be a better way to do this that preserves rendering speed. Any suggestions?
-
Dear Burgreen,
I don't know much about Qt3D but I have much experience in 3D Programming. The picking engines always a problem. To pick an Object on a way like QObjectPicker the Rendering engine has to draw the whole Scene for every pick. That's sometimes acceptable with picking but not acceptable for moving the cursor over a scene and show some information in real time. Technics like QObjectPicker are helpful if you handle a small scene (same as picking mode in OpenGL). But for a big scene you have to use a binary tree like a K-D-Tree (Octree) or another kind of binary tree (There are more then one ways). Sorry that I can't demonstrate it with an example. To build a binary Tree from a Mesh is a lot of Code.
-
That is helpful advice, friend. So, I need to minimize draw calls by putting all my normals into a single VBO and perform picking in an off-screen binary tree. Then update the selected objects by redrawing the single VBO with selected entities having modified attributes. Is this a decent optimization? Are there other techniques or better options?
-
Dear Burgreen,
hm, yes you can minimize draw calls, but why you want use the ObjectPicker. It's not neccessary. If I have to implemented something like you. I indexed a mesh, calculate a point with the mouse cursor hotspot (I know that a pixel describe not a point) and "shot" a ray with the direction described by the Projection Matrix on the indexed Mesh. The Calculation time for a mesh with 100.000 - 300.000 Vertices not more then 1/100 Sec. It's fast enough for real time rendering. And you not get a IPC Overhead from a unknown system. But sure, you can use the binary Tree for minimize draw calls, too.
-
So, use the projection matrix to compute a ray in physical space, and then do an off-screen ray intersection with an indexed mesh? If so, how is that different than what QObjectPicker does? If not the same, how is what you are proposing different and what am I missing? Would you perform ray-intersections tests for mesh vertices or mesh faces? Can you point to a paper or implementation that does this?