GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
vocx
Posts: 4296
Joined: Thu Oct 18, 2018 9:18 pm

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by vocx » Thu May 28, 2020 5:33 am

kryptokommunist wrote:
Thu May 28, 2020 5:04 am
  • check that the selected object is valid, if not display an error message (should this be a pop up or just raise an Error to be displayed in the Report View at the bottom?
  • make sure that aborting the selection at any step works without side effects
I would leave the make_array function alone, and instead, try to modify make_polar_array. In the future we will want to split the Array classes into their own files, so right now make_array is a necessary evil, but we shouldn't add more code to it.

I don't like that you define an observer inside a class method, and the observer is a class itself that defines its own methods. Surely there is a less nested way.

You add and remove the callbacks, I think this is correct, but what I don't like is that now we go back an forth between the gui_polararray and the task_polararray files. Ideally, we should try to put this in one place only. I admit that when I wrote those files I didn't know the best strategy because I was also looking into the parent class of the Gui Command, the GuiCommandBase (gui_base) which is basically a simplified DraftTool (gui_base_original). So, this can change to accommodate a better workflow.
Always add the important information to your posts if you need help.
To support the documentation effort, and code development, your donation is appreciated: paypal.

User avatar
looo
Posts: 3343
Joined: Mon Nov 11, 2013 5:29 pm

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by looo » Thu May 28, 2020 7:40 am

kryptokommunist wrote:
Thu May 28, 2020 5:25 am
I'd like to ask you all interested in this topic, if you have a use case in mind on how you would use IPython and/or Jupyter Notebook with the ability to display the 3D view without having to start the FreeCAD-Desktop app. In the end the result will be the ability to render the OpenInventor scene graph in a web browser (regardless of the IPython/Jupyter integration). What would you like to do with that possiblity? I mean there alreay is a WebGL export but it has some issues right now as far as I can tell.
use-cases:
- parameter-optimization of freecad-objects and visual checking the results
- documentation of geometry, simulation results (eg. report on a fem simulation)

One example I have in use is an optimization of line-lengths of a paraglider. The lines are optimized for tangentiallity to ribs. This is a complex task as lines depend on forces and geometry of connected lines. Having a visual representation of the scene in jupyter would be a big advantage.

If it is possible to also get more complex nodes drawn in the notebook (eg. full representation of the scene in webgl with callbacks and so on) this would be for sure another big advantage.

User avatar
yorik
Site Admin
Posts: 11930
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by yorik » Fri May 29, 2020 12:16 pm

Regarding your fix to the Draft Array tool, that seems perfect (thanks @vocx for the review)! In any case it demonstrates perfectly that you can find your way around FreeCAD, and with this community. I think this fullfills perfectly what is expected from this GSOC bonding period.

Regarding jupyter and 3D export of the FreeCAD scene, a couple of preliminary ideas:

I think there are two strategies to choose. Currently,if you don't have the GUI open, although you are able to import and manipulate somehow the FreeCADGui module, you don't have all the visual settings of objects. The only way to achieve that is to show the FreeCAD GUI, even if hiding it immediately afterwards, to turn on all the Qt events loop. See examples in this thread (old, but the concept is still valid).

So I think you have to choose here between 1) not using the GUI module, and building alternative ways to manage visual info (colors, etc) or 2) using the GUI and finding ways to minimize/address the problem. Might be quickly show/hide the GUI, or anything else.

I think both ways are valid. 1) would be quicker, would allow you to work fully in Python, and is not necessarily a bad way at all. Even without the GUI, you would still be able to do almost everything you need. Check the OfflineRenderingUtils.py, it contains much stuff already to works that way. One way I'm imagining this could work is basically to have a special module (or even add methods at runtime to the GUI module), that would allow someone, inside jupyter to do something like this:

Code: Select all

import FreeCAD
import Part
import FreeCADJupyterTools

d = FreeCAD.newDocument()
sh = Part.makeSphere(10)
obj = d.addObject("Part::Feature","MySphere")
obj.Shape = sh

print(obj.ViewObject) # this returns None as the GUI is not used

FreeCADJupyterTools.setColor(obj,(1.0,0.0,0.0)) # this would store the obj/color relationship somewhere. Maybe even in the object itself
FreeCADJupyterTools.render(d) # this would show the webGL scene inside the notebook
2) The second way is more in sync with what oyu wrote in your GSOC proposal, basically a way to have this:

Code: Select all

import FreeCADGui

# here at the moment you need to do this to trigger ViewObjects functionality
FreeCADGui.showMainWindow()
mw = FreeCADGui.getMainWindow()
mw.hide()

obj.ViewObject.ShapeColor = (1.0,0.0,0.0)
Then you could gather the coin nodes from every object (obj.ViewObject.RootNode) and have a coin-to-webgl conversion happen.

Note that Shape and Mesh objects (such as 'sh' in the example above) all have a writeInventor() method, that outputs a very simple inventor node (without any material), that is less refined than from obj.ViewObject.RootNode, but that might be totally sufficient to start with, so even with method 1), a coin-to-webgl convertor seems a good way to follow.

The only FreeCAD objects that have no Shape or Mesh are very few, basically some Draft objects (texts, dimensions) and Path. But for all these, it might not be hard to do the same thing as above, basically add some writeInventor() method to them.

User avatar
bernd
Posts: 10098
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by bernd » Fri May 29, 2020 1:14 pm

yorik wrote:
Fri May 29, 2020 12:16 pm
The only FreeCAD objects that have no Shape or Mesh are very few, basically some Draft objects (texts, dimensions) and Path. But for all these, it might not be hard to do the same thing as above, basically add some writeInventor() method to them.
We have a lot of them in FEM. In which regard is this important?

vocx
Posts: 4296
Joined: Thu Oct 18, 2018 9:18 pm

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by vocx » Fri May 29, 2020 3:47 pm

bernd wrote:
Fri May 29, 2020 1:14 pm
We have a lot of them in FEM. In which regard is this important?
This is only important if you want to display them on screen. I think in FEM there are many objects that don't need to be displayed; they are just there for the user to interact with the information, like the Analysis or Solver. You can't actually display these on the screen, so they don't matter for this discussion. It's only the objects that hold visual information, for example, the FEM Mesh. Does the FEM Mesh have an actual Shape? Or is it just a coin representation on screen?
Always add the important information to your posts if you need help.
To support the documentation effort, and code development, your donation is appreciated: paypal.

User avatar
bernd
Posts: 10098
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by bernd » Fri May 29, 2020 7:34 pm

vocx wrote:
Fri May 29, 2020 3:47 pm
bernd wrote:
Fri May 29, 2020 1:14 pm
We have a lot of them in FEM. In which regard is this important?
This is only important if you want to display them on screen. I think in FEM there are many objects that don't need to be displayed; they are just there for the user to interact with the information, like the Analysis or Solver. You can't actually display these on the screen, so they don't matter for this discussion. It's only the objects that hold visual information, for example, the FEM Mesh. Does the FEM Mesh have an actual Shape? Or is it just a coin representation on screen?
FemMeshs ViewProvider is all done directly with coin, no Shape. see https://github.com/FreeCAD/FreeCAD/blob ... tForce.cpp Furthermore constraints have a lot of graphical stuff like arrows and symbols which are not saved in a shape property but are directly made with coin. For example the force symbols https://github.com/FreeCAD/FreeCAD/blob ... d.cpp#L115

vocx
Posts: 4296
Joined: Thu Oct 18, 2018 9:18 pm

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by vocx » Fri May 29, 2020 10:01 pm

bernd wrote:
Fri May 29, 2020 7:34 pm
... a lot of graphical stuff like arrows and symbols which are not saved in a shape property but are directly made with coin. ...
Okay, so in that case, you'd need to write the Inventor representation manually, I think.
Always add the important information to your posts if you need help.
To support the documentation effort, and code development, your donation is appreciated: paypal.

User avatar
kryptokommunist
Posts: 46
Joined: Fri Mar 27, 2020 6:29 pm
Location: Berlin
Contact:

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by kryptokommunist » Tue Jun 02, 2020 4:48 am

Quick update on what I have been doing, I am still working on the Draft Array tool with an slightly extended scope. The posting on that moved to this thread. I think I might need up to 2 more days to finish it, if this is okay with everyone since yesterday the coding phase officially started and strictly speaking I should work directly on the project and the Draft Array tool is still part of the ramp up. But I think it'd be good to finish this. I created a project on Github where I put in all the preplanned tasks for this month and I'll update it if something new comes up.

yorik wrote:
Fri May 29, 2020 12:16 pm
So I think you have to choose here between 1) not using the GUI module, and building alternative ways to manage visual info (colors, etc) or 2) using the GUI and finding ways to minimize/address the problem. Might be quickly show/hide the GUI, or anything else.
The main issues I see with using the GUI are:

  • The size of the UI views might not be suitable for being displayed inside a limited space in the Jupyter Notebook
  • You won't be able to send someone a notebook and expect a person to fully understand exactly how to reproduce the saved content because the UI interaction is not recorded
2) The second way is more in sync with what oyu wrote in your GSOC proposal, basically a way to have this:

Code: Select all

import FreeCADGui

# here at the moment you need to do this to trigger ViewObjects functionality
FreeCADGui.showMainWindow()
mw = FreeCADGui.getMainWindow()
mw.hide()

obj.ViewObject.ShapeColor = (1.0,0.0,0.0)
Do I understand correctly that this proposal is to create access to the features that are currently only available through the GUI? Would definitely seem more elegant to me. Currently my gut feeling is telling me to favour this solution. Ideally I'd think that all the visual settings would get an API that has Code only usage without an GUI in mind and then the GUI tools would use these. I mean is there a reason why this wasn't done?

looo wrote:
Thu May 28, 2020 7:40 am
One example I have in use is an optimization of line-lengths of a paraglider. The lines are optimized for tangentiallity to ribs. This is a complex task as lines depend on forces and geometry of connected lines. Having a visual representation of the scene in jupyter would be a big advantage.
Wow if that is built I would be honoured to have contributed something that makes this easier :D

If it is possible to also get more complex nodes drawn in the notebook (eg. full representation of the scene in webgl with callbacks and so on) this would be for sure another big advantage.
Do you mean WebGL callbacks for enabling zooming/panning inside the view?

ickby
Posts: 2963
Joined: Wed Oct 05, 2011 7:36 am

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by ickby » Tue Jun 02, 2020 7:05 am

I did not follow the whole discuccion yet, but IMHO we need to work with the coin3d scene graph. Lots of stuff is build in coin only (FEM, Path etc) and it's important for the usability to capture that (and also to not to die during re-implementing everything). So we need to look into how to access the scene graph without GUI open. I had a working implementation for that a few years ago. I need to see if this would still work. We could talk about that in the kickoff.

My jupyter notebook usecase:
- Modelling of simplified geometries (Needs UI lookup of intermediate steps, and to get naming of elements, e.g. extrude edge1)
- Meshing of Geometries (needs a way to check in UI naming of elements, e.g. which Edge in UI has which name, for mesh groups)
- FEM analysis, partially with FreeCAD FEM partially with external packages (FENICS)
- Plotting of results of FEM analysis (mostly outside FreeCAD in jupyter directly)

User avatar
looo
Posts: 3343
Joined: Mon Nov 11, 2013 5:29 pm

Re: GSoC 2020: A better IPython and Jupyter Notebook Integration for FreeCAD

Post by looo » Wed Jun 03, 2020 9:51 am

kryptokommunist wrote:
Tue Jun 02, 2020 4:48 am
Do you mean WebGL callbacks for enabling zooming/panning inside the view?
I thought about more advanced scenes where a coin.SoCallback() node is added to the scene which calls a (python) function. But I think such things should not be part of this the project. Better to concentrate on static elements.
ickby wrote:
Tue Jun 02, 2020 7:05 am
I did not follow the whole discuccion yet, but IMHO we need to work with the coin3d scene graph. Lots of stuff is build in coin only (FEM, Path etc) and it's important for the usability to capture that (and also to not to die during re-implementing everything). So we need to look into how to access the scene graph without GUI open. I had a working implementation for that a few years ago. I need to see if this would still work. We could talk about that in the kickoff.
+1 I think this would also make it possible to have a webgl viewer for pivy (without dependency on freecad) which would give the possibility of more direct testing. With pivy/coin it should be possible to write the scene to a buffer without showing the scene (I never tried that, but there is an example[1]). If there is a webgl library that is able to read the output and draw the scene in the jupyter-notebook this should be a possible way.

[1] https://grey.colorado.edu/coin3d/classS ... 9581774bc7

Post Reply