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
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.
I had a brief look at the projects you found. Let me give you some first impressions:
: 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.
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.