Assembly3 preview

[realthunder]

New bug fix released.

Fixed the two A3 workbench bugs reported earlier. Fixed STEP export hanging problem. Fixed a few color override problem under VBO.

Still no clue about VBO performance problem though. My Linux machine has only 256MB graphics memory, and Windows machine mostly likely half or even less than that. There is not much acceleration on my Windows to begin with. I think OpenGL puts the VBO in system memory if there is not enough graphics memory, and automatically swap in and out when needed, which is why I didn't see that much of improvement. But at least I do see some changes on my machine. No idea why it is so much worse on easyw-fc machine. Anyone else care to report?

[easyw-fc]

Because the STEP import preference page is from Part workbench, you'll have to load the workbench first in order to see it. And when you import STEP file, Part workbench is auto loaded by FC. That's why you see it afterwards.

this discussion may be relevant
https://forum.freecadweb.org/viewtopic. ... 10#p182349
https://forum.freecadweb.org/viewtopic.php?f=10&t=23400

And about VBO, I found an email Jean Marie sent me about his VBO coding... may be this info could help about the VBO performance discrepancy

Hi Maurice,
I think I found the root issue of our low frame rate, and the patch is crazy simple in the end. When I started to work on the rendering issue the Bareleye model was running at 1.2 fps on my Macbook Pro.
With the first step (aka my VBO implementation) it went up to 12 fps.
This morning while digging into Coin3D code, I found a very stupid bug in FreeCAD (simple patches are the best), as Edges were drawn in Coin and Triangles in FreeCAD. If I bypass the Triangles call in FreeCAD and rely on Coin3D to draw them, I reach 30 fps on my Macbook Pro. In fact Coin3D is doing what I wanted do, build a global mesh of the scene, cache it into a VBO structure, and render it.
There is no need to rewrite code for that !, and my patch is just 1 line at the right place . This is just an x30 improvement on the fps. I suspect that on your machine you shall run around 45 fps on complex models or even faster after applying the patch.

[triplus]

What should i test when it comes to VBO. If i remember correctly i noticed a difference in the past tests when VBO support was initially added. Not sure if it was STEP related as AFAIK general bump of FPS was noticed.

Therefore in short what should i test?

[easyw-fc]

But at least I do see some changes on my machine. No idea why it is so much worse on easyw-fc machine. Anyone else care to report?

I'm running on a GeForce GTX950 with 2GB Memory ... it is a Game card that gets nice performance on graphic CADs

Rendering transparency disables VBO.

I also see a difference in A3 branch, if I toggle OFF VBO in A3 the speed is almost half.

What should i test when it comes to VBO. If i remember correctly i noticed a difference in the past tests when VBO support was initially added. Not sure if it was STEP related as AFAIK general bump of FPS was noticed.
Therefore in short what should i test?

EDIT: you need enough complex model to trigger the performance comparison

You can try it loading i.e.
http://terzo.acmesystems.it/download/me ... aMech.step
and compare the rotation speed on both branches (NB you need to have only one document open in each FC instance to get the best of VBO)
https://forum.freecadweb.org/viewtopic. ... 10#p238098

frame rate is still better in FC mainstream with VBO enabled...
a part the fps displayed, you can see that the FC mainstream board is turning faster than the A3 branch one...
I'm using the following code for spinning comparison

Code: Select all

FreeCADGui.ActiveDocument.ActiveView.startAnimating(0,1,0,0.2)

EDIT:
and the video which is more effective

phpBB [video]

[realthunder]

And about VBO, I found an email Jean Marie sent me about his VBO coding... may be this info could help about the VBO performance discrepancy

Hi Maurice,
I think I found the root issue of our low frame rate, and the patch is crazy simple in the end. When I started to work on the rendering issue the Bareleye model was running at 1.2 fps on my Macbook Pro.
With the first step (aka my VBO implementation) it went up to 12 fps.
This morning while digging into Coin3D code, I found a very stupid bug in FreeCAD (simple patches are the best), as Edges were drawn in Coin and Triangles in FreeCAD. If I bypass the Triangles call in FreeCAD and rely on Coin3D to draw them, I reach 30 fps on my Macbook Pro. In fact Coin3D is doing what I wanted do, build a global mesh of the scene, cache it into a VBO structure, and render it.
There is no need to rewrite code for that !, and my patch is just 1 line at the right place . This is just an x30 improvement on the fps. I suspect that on your machine you shall run around 45 fps on complex models or even faster after applying the patch.

Nice, I got misdirected. FC customized VBO for face rendering works the same on my branch. It is the edge and point that are different, and among these two, the point set is actually the main culprit of slow down. You can test it by change the global draw style to Shaded, the the frame rate should now be the same as upstream. Both point and edge set relies on Coin caching, and I disabled it in early development because of problem of shared instance with Link. Now, I just need to figure out how to turn on and off caching properly.

[easyw-fc]

Nice, I got misdirected. FC customized VBO for face rendering works the same on my branch. It is the edge and point that are different, and among these two, the point set is actually the main culprit of slow down.

Good to see my posting is useful

You can test it by change the global draw style to Shaded, the the frame rate should now be the same as upstream. Both point and edge set relies on Coin caching, and I disabled it in early development because of problem of shared instance with Link.

There is a doubling of rendering, still 3-4 times slower compared to main branch

fps-Coin.gif (872.51 KiB) Viewed 795 times

Now, I just need to figure out how to turn on and off caching properly.

Thx

[fosselius]

I guess its time to start to contribute, have made an pull request for a small typo in the solver.

I have noticed that the angle "offset/reference" is drifting? when i play around with the angle in PlaneCoincident. If I enter some various random angles it will suddenly have a new "offset", the same angle will successfully solve to a new position.

I will start to dig a bit in the code to see if i can understand what and why this happens.

Screenshot from 2018-06-12 07-08-57.png (52.73 KiB) Viewed 702 times

Screenshot from 2018-06-12 07-08-16.png (44.42 KiB) Viewed 702 times

If i change the angle of the fixed parts body inside the assembly, it will look like this for 0, 45 and 90 degree

Screenshot from 2018-06-12 07-44-25.png (62.89 KiB) Viewed 693 times

[realthunder]

I guess its time to start to contribute, have made an pull request for a small typo in the solver.

Thanks!

I have noticed that the angle "offset/reference" is drifting? when i play around with the angle in PlaneCoincident. If I enter some various random angles it will suddenly have a new "offset", the same angle will successfully solve to a new position.

I am not sure I understand your problem, but yeah, angles are notorious when used in constraint, because the constraining equation tests for sin/cos value of the angle, which obviously has multiple solutions.

[fosselius]

This might be a good test file, its exported from Autodesk Inventor
https://cdn.hackaday.io/files/157812675 ... ckaday.stp
its from this project
https://hackaday.io/project/157812-3d-p ... t-actuator

[realthunder]

A bit more digging at the render thing. I found that Coin's own cache is also a contributing factor. The shape nodes, i.e. the face set, line set etc. can hint the cache, but the ultimate control of caching is at their parent SoSeparator nodes. So I added a new option to expose this setting. By default, Coin uses auto cache. It uses some heuristics to decide whether to cache or not (see here).

My tests shows that the its heuristic will turn off caching if you select the object a few times. Maybe the overriding color makes coin think the data is changing. You can force the cache now with the new option. I think coin uses OpenGL display list for SoSeparator's cache. Once the cache is established, the shape node's render function is not even called. To see the actual acceleration effect of VBO, you'll need to turn off the cache. The advantage of Coin's cache is that it works even for selection, which has an overriding color. I don't how they are able to do this, maybe having multiple display list?