high level coin access

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!
looo
Posts: 2749
Joined: Mon Nov 11, 2013 5:29 pm

high level coin access

Postby looo » Thu Dec 11, 2014 4:13 pm

What would be the best way to make a high level coin api for python? (Boost-python, a python layer on pivy, swig, ...) After using pivy a lot I think that most of the things there aren't needed and could be simplified.
I am thinking of a module which makes it easy to extend the scene with graphics-primitives, interactors, manupulators and so on. Not like pivy which is nearly the same level as coin. This could also be a step towards python3 as pivy isn't supporting python3 yet.
does anyone has allready tried something like this? How much work would it be?

So this:

Code: Select all

from pivy import coin
object = coin.SoSeparator()
ls = coin.SoLineSet()
data = coin.SoCoordinate3()
color = coin.SoMaterial()
color.diffuseColor = COLORS[color]
object.addChild(self.color)
object.addChild(self.data)
object.addChild(self.ls)
becomes something like this:

Code: Select all

import pycoin
line = pycoin.Line([pts])
line.color = pycoin.color.red .......
ickby
Posts: 2914
Joined: Wed Oct 05, 2011 7:36 am

Re: high level coin access

Postby ickby » Thu Dec 11, 2014 6:13 pm

Are you sure this is a good idea? The scene graph is performance critical and a high level api may not reflect that.
After using pivy a lot I think that most of the things there aren't needed and could be simplified.
I do not share this opinion. Coin (and pivy) is already pretty high level for a openGL scene graph, but as I said, performance is critical here. One can not go too far away from how the rendering works in opengl.

For example your line code. You can not simply add a seperator with a coordinate and color node for every line, this will kill FreeCAD with only a few hundred of them, maybe less. Of course one can create an api that allows to extend one line node when other linea are created, but then it will most likely be not much simpler that what is available now.
And for keeping track of the openGL states it is important to keep in touch with the graph structure, as without it is impossible to know what state changes when. So you cannot realy omit the nodes.

Every scene graph creation should give the user the possibility to create fast code and that means a certain level of "handwork". Maybe a few things could be automated with a small layer above pivy, but then one has to understand pivy nonetheless to find out how to write performant code.
looo
Posts: 2749
Joined: Mon Nov 11, 2013 5:29 pm

Re: high level coin access

Postby looo » Thu Dec 11, 2014 9:56 pm

For example your line code. You can not simply add a seperator with a coordinate and color node for every line, this will kill FreeCAD with only a few hundred of them, maybe less.
I thought of it like this:
line([a,b]).... one line
line(list of points) .... like a wire
line(nested_points) .... many lines in one seperator

Every cad object in freecad has it's own separator... Also a Line from a to b. so what is the problem about it?
Every scene graph creation should give the user the possibility to create fast code and that means a certain level of "handwork". Maybe a few things could be automated with a small layer above pivy, but then one has to understand pivy nonetheless to find out how to write performant code.
If someone want to make a tool performant he can do it with c++ and coin. But for people who want to make a parametric tool that has to handle things it is (or should be) easier to do it with python. And an easy to handle graphical tool will definetly help to develop something faster.
In most cases the limitating issue is the geometry calculation and not the scene. (at least it was/is for our project). But most limitating are the apis to get familiar with. The gui should be as easy as possible to implement, so someone can concentrate on the main application. It definetly does not make sense if the development of the gui last longer then the application development. I think there was an discussion about this issue some time ago.