Maninesan wrote:After a deep walkthrough over the code, I'm get confused about python bindings! Multiple wrapper/extension techniques are found there, like SWIG, Boost.python and Cxx! What's purpose of that?
FreeCAD itself uses Cxx for wrapping its objects and functions to python. AFAIK Swig and BoostPython are used for projects which provide python wrappers created with them, for example Pivy. but I need to investigate this a bit further myself
Also If we want to create those open inventer actions in C++ to manipulate the javascript,we need to bind some javascript engine with this project! Is there any javascript binding available now?
No, the idea is not to have a JavaScript wrapper. There should be no live connection between the c++ and JavaScript side, only a "static export". You already found the current webgl/html exporter. What it does is to create html + javascript code as string whiich is then saved as html file. The same idea should be used for IPython. Create a Javascript code as a string and pass it to ipythons display functions which accept javascript code. This does not need any JavaScript backend in FreeCAD, and also no wrapping. It is more like a static export in the sense that we export a javascript code which can be executed standalone in any browser and by Ipython. (Note: once created this should also replace the current webgl export, as it is very limited)
Have a look at the ipython display system, and how it can work with javascript and html:
https://ipython.org/ipython-doc/3/api/g ... splay.html
Note that a "live connection", a wrapper do access the scene graph, render and manipulate it from javascript, would also be nice, but definitely is out of scope of this gsoc project. This may be something interesting to continue after GSoC or as a next year project. Maybe even add it as optional item in your proposal, just in case some time is left at the end.
I saw one webgl import action in "src/Mod/Arch/" directory,but it is written in python? So can we write those inventor actions in python?
The code you found is a good resource to understand the general concept. But if you have a close look at the code you see that the current exporter does not export the scene graph, but only a very limited set of document objects. In "getObjectData" you find that only Part::Feature and Mesh::Feature objects are exported. This is a nice start, but not sufficient. The problem with the idea of exporting document objects separately is that for every new object the exporter needs to be adjusted, which is much work and a maintenance hell. Furthermore there is no way to manipulate materials, colors etc. in the output. This is why the GSoC project aims at exporting the scene graph instead of the document objects, it is way more complete and general.
The current exporter is written in python. You can also access the open inventor scene graph from python, search the wki for "pivy", which is the inventor python wrapper we use. So it is possible to write the action, which creates the javascript, in python. But note that the scene graph can get big, and hence it can become a performance issue to use python. The choice is in the end up to you, both c++ and python are possible.
I had a brief look at the projects you found. Let me give you some first impressions:
https://github.com/kwahoo2/nwgl: This resembles the idea we have very well, it creates a standalone webgl bsed html file. It does however have the same issue as our current html export: it works on a document objects. We want something more general, hence we want to mimic the whole scene graph.
Pythreejs: This seems to be a interesting tool for the "live connection" kind of javascript/python interaction. It is not what we want for the GSoC project. One of the nice things of the "static export" as opposed to a pythreejs version is that it can be saved together with the notebook and be displayed even if freecad is not installed on the machine. For the pythreejs version everyone wanting to open the notebook and having a look at the 3d scene needs pythreejs and freecad installed and needs to execute the code.
Annother note: most of the code we already reviewed uses threejs for webgl. This is of course possible also for this gsoc project, it is your choice which library you use. But there are others out there, for example scenejs. I would choose a library where the openinventor nodes are easily ported to. For example exporting a openinventor scenegraph to threejs seems cumbersome, as threejs does not use a scenegraph structure. It therefore needs much logic handling. Maybe for scenejs, which also is based on scenegraphs, it is a simple one to one mapping, eg. a opennvetor node becomes a scenejs node. This would be much simper. It is your task to analyse the available projects and find a good fit.
