LinkDaily branch 3D view experimental renderer

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
User avatar
-alex-
Veteran
Posts: 1861
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

LinkDaily branch 3D view experimental renderer

Post by -alex- »

OS: Debian GNU/Linux 10 (buster) (LXDE/LXDE-pi)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.27742 (Git)
Build type: Unknown
Branch: LinkStage3
Hash: 0a157a307c91d241a370cdda6d8f0471b7c48915
Python version: 3.7.3
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/France (fr_FR)
realthunder wrote:ping
I've read you introduced an experimental 3D view renderer in Linkstage3 2021-03-28 release: https://github.com/realthunder/FreeCAD_ ... 3/releases
The Daily branch introduces an experimental renderer that bypasses Coin3D and do its own rendering. It renders much faster than Coin3D for complex and deep assembly hierarchies (works for assembly STEP imports). You can enabled it in Preference -> Display -> Render cache -> Experimental. The renderer does not yet work with nodes that uses texture, e.g. text labels in Draft.

I have sync your branch yesterday but I can't find this setting in Preferences/Display menu though. Does I get you wrong?
Does this renderer need some additional libraries?
I would like so much to test such alternative to Coin3D on my Raspberry PI4 system :)
Last edited by -alex- on Thu May 13, 2021 7:06 pm, edited 1 time in total.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Linkstage3 branch 3D view experimental renderer

Post by realthunder »

-alex- wrote: Thu Apr 01, 2021 10:35 pm I have sync your branch yesterday but I can't find this setting in Preferences/Display menu though. Does I get you wrong?
Does this renderer need some additional libraries?
I would like so much to test such alternative to Coin3D on my Raspberry PI4 system :)
The renderer is in the LinkDaily branch. Once compiled, you can enable it in Preference -> Display -> Render cache -> Experimental. Right now, the renderer is just a proof of concept. It takes the Coin3D scene graph, and build its own render list sorted by material just like most of the real time renderer out there, and uses OpenGL to render it. In the future, the OpenGL part will be replaced by other library for other fancy graphical effects.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
-alex-
Veteran
Posts: 1861
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Linkstage3 branch 3D view experimental renderer

Post by -alex- »

realthunder wrote: Thu Apr 01, 2021 11:07 pm The renderer is in the LinkDaily branch. Once compiled, you can enable it in Preference -> Display -> Render cache -> Experimental.
I've read that but I had not fully understood. Now I get it, So now I have to compile your linkdaily branch, thank you.

BTW I'm also gonna change my other post I've made about your toponaming algorythm here
User avatar
-alex-
Veteran
Posts: 1861
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Linkstage3 branch 3D view experimental renderer

Post by -alex- »

realthunder wrote: Thu Apr 01, 2021 11:07 pm Right now, the renderer is just a proof of concept. It takes the Coin3D scene graph, and build its own render list sorted by material just like most of the real time renderer out there, and uses OpenGL to render it. In the future, the OpenGL part will be replaced by other library for other fancy graphical effects.
If I get your meaning, you mean OpenGL rendering from Coin3D could be replaced by Vulkan rendering for eg? Right?
The Coin3D scene graph could be used by Vulkan lib thanks to your experimental renderer?
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Linkstage3 branch 3D view experimental renderer

Post by realthunder »

-alex- wrote: Thu Apr 08, 2021 5:22 pm If I get your meaning, you mean OpenGL rendering from Coin3D could be replaced by Vulkan rendering for eg? Right?
The Coin3D scene graph could be used by Vulkan lib thanks to your experimental renderer?
Yes, sort of. I intend to those library (e.g. DiligentEngine) that can abstract away the actual graphics library calls, such as OpenGL, Direct3D, Vulkan, etc.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
-alex-
Veteran
Posts: 1861
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Linkstage3 branch 3D view experimental renderer

Post by -alex- »

realthunder wrote: Mon Apr 12, 2021 6:41 am Yes, sort of. I intend to those library (e.g. DiligentEngine)
Wow, seems very promising 8-)
Furthermore Vulkan 1.0 is available on Raspberry PI4 board, I would be so happy to try it with FC to see how much it could speed up the 3D view framerate and if that will fix some segfault crashs :-)
Keep forward! :-D
User avatar
-alex-
Veteran
Posts: 1861
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Linkstage3 branch 3D view experimental renderer

Post by -alex- »

realthunder wrote:ping
Hi, I've compiled your LinkDaily branch on my Raspberry PI4. Experimental render cache works fine :)
But it works slowly compare with master branch, maybe there is some reason which explain this statement, I don't know.
I performed some test with an array of 7290 Part_Cube with transparency 90% :

2021-05-12-185855_1920x1080_scrot.png
2021-05-12-185855_1920x1080_scrot.png (764.02 KiB) Viewed 2738 times
cube_array.FCStd
(205.16 KiB) Downloaded 52 times

While rotating the model in 3D view I get:
- with master branch render cache=auto: -> about 12fps
- with LinkDaily branch render cache=auto: -> about 4.5fps
- with LinkDaily branch render cache=experimental: -> about 6fps

I understand that's a work in progress, is it the intended result at this stage? Or I did something wrong?

OS: Debian GNU/Linux 10 (buster) (LXDE/LXDE-pi)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.27927 (Git)
Build type: Unknown
Branch: LinkDaily
Hash: c9afa55c7adb347b2e903d818956843ef0f5a978
Python version: 3.7.3
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/France (fr_FR)
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: LinkDaily branch 3D view experimental renderer

Post by realthunder »

Hmm... maybe you didn't enabled VBO? I just tested the file. Yes, it does seem to be slower comparing upstream with 'Auto' caching, but 'Experimental' has the same performance. The difference between 'Auto' and upstream is in how transparency is handled. In my branch the triangle sorting is handled in FreeCAD instead of Coin3D to workaround problem of rendering artifacts of transparent faces at certain angle. But the performance should be about the same. I'll investigate later.

The reason I decide to implement my own render caching is two fold. For one, with customized caching, it is now possible to handle rendering entirely in my own code, which makes it much easier to use other rendering library as mentioned in my previous post. Second, the Coin3D render caching is not good at handling hierarchies, more specifically, it is not good at handling cache changes in the hierarchy. If the cache is always clean, then the performance is good, but if it becomes dirty or got disabled (e.g. because of selection highlight), the performance will drop because it has to traverse the hierarchy for rendering. My experimental renderer caches the geometries in a flattened data structure, so it will always have the same rendering performance regardless of changes in the scene hierarchy.

To demonstrate the problem, you can select one face in the cube array (or just pre-select a face and spin the 3D view) and see huge drop of rendering performance in upstream. This is because Coin3D render cache is disable if there is element selection in transparent object. This problem can be solved by changing how selection highlight is rendered. In my branch with `Auto` render caching, you have the option to render pre selection highlight on top. And this makes it possible to keep using the Coin3D render cache. However, with other more advanced effects, such trick won't be so effective. For example, in my branch, with 'Selection on top' enabled, the selected object will become transparent and rendered on top with alternative hidden line style, all of which affects the rendering performance if using Coin3D. But with my 'experimental' caching, the performance is the same.

phpBB [video]

https://youtu.be/DIAvTmqjZ9Q

Zolko's lego house is a more suitable files for benchmarking, as it contains deep hierarchies. Another one is this, which has large amount of Link instances to relatively simple geometries with hierarchies. I got only 5fps for rendering the later model using 'experimental' renderer. I expect this type of scene to perform a lot better if using shader with OpenGL instancing.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
-alex-
Veteran
Posts: 1861
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: LinkDaily branch 3D view experimental renderer

Post by -alex- »

Late reply sorry.
realthunder wrote: Fri May 14, 2021 1:50 am Hmm... maybe you didn't enabled VBO?
yes VBO was activated
I just tested the file. Yes, it does seem to be slower comparing upstream with 'Auto' caching, but 'Experimental' has the same performance.
Yes it is, on my Raspberry4 auto=70ms and upstream=40ms about the same scene (no selection)
The difference between 'Auto' and upstream is in how transparency is handled. In my branch the triangle sorting is handled in FreeCAD instead of Coin3D to workaround problem of rendering artifacts of transparent faces at certain angle. But the performance should be about the same. I'll investigate later.
I trust you :D
To demonstrate the problem, you can select one face in the cube array (or just pre-select a face and spin the 3D view) and see huge drop of rendering performance in upstream.
Yes I've seen that indeed.
But with my 'experimental' caching, the performance is the same.
I've seen that as well, and that's very cool!
Thanks for your explanations and video, that's very interesting.
Right now I'm going to compile your last 05.28 LinkDaily release to test your last improvements about rendering.
That's very exiting.

Offtopic: thank you for your measurment tooltip, that's a great tool, very convenient:
Image
User avatar
-alex-
Veteran
Posts: 1861
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: LinkDaily branch 3D view experimental renderer

Post by -alex- »

realthunder wrote: Thu Oct 28, 2021 12:15 am
-alex- wrote: Wed Oct 27, 2021 11:12 pm Offtopic: I've seen 3 days ago you added Diligent engine to renderer modul in Linkdaily branch :P
Does it mean your Linkdaily branch now would support Vulkan API?
I assume that would be great for RPI4 users of FreeCAD because https://www.raspberrypi.com/news/vulkan ... erry-pi-4/ :roll:
I actually added both bgfx and Diligent engine. And I got bgfx OpenGL backend working already (just for rendering their examples, not FC objects yet), but not Diligent, as it demands OpenGL 4 which my current machine don't have. For a smoother transition, we have to support older OpenGL, and also legacy code that renders using their own OpenGL code. What I am trying to do is to write my renderer using those libraries to render into a framebuffer/texture, and then copy into FC OpenGL framebuffer. So if the machine supports extensions for sharing between Vulkan and OpenGL, then yes, we can have Vulkan rendering there. The same goes for D3D rendering on Windows, and Metal on MacOSX.
Thanks for those good news and for explanations. So I assume Dliligent engine is out of reach for a long time as the RPI4 is concerned because of OpenGL 4.5 requirement.
I'll will give it a try with bgfx, furthermore they claims it's suitable for Raspberry machines.
So, does your renderer already plugable to glx pipe if some Vulkan driver is installed? How to proceed?
That's just a question, no pressure.

JFI:

Code: Select all

pi@raspberrypi:~ $ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Broadcom (0x14e4)
    Device: V3D 4.2 (0xffffffff)
    Version: 19.3.2
    Accelerated: yes
    Video memory: 3359MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Broadcom
OpenGL renderer string: V3D 4.2
OpenGL version string: 2.1 Mesa 19.3.2
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 19.3.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
Post Reply