ViewProvider specific clip plane, yes or no?

[abdullah]

... ping ...

We have been giving it a go to showing a section when editing sketches (mostly DeepSOIC has ):
https://forum.freecadweb.org/viewtopic. ... 20#p233278

It seems to work:

SectionView.gif (183.65 KiB) Viewed 1730 times

My question is code related. This currently works via TempoVis by inserting a SoClipNode on all the viewproviders other than that of the sketch:
https://github.com/abdullahtahiriyo/Fre ... is.py#L272

I have implemented a ViewProvider specific permanent SoClipNode in here:
https://github.com/abdullahtahiriyo/Fre ... a9e1ec2c3e

My questions are:
1) Is my permanent SoClipNode code acceptable?
2) Do you think it may be useful? Also for other projects like FEM?
3) Is the current solution in TempoVis of inserting nodes in viewproviders acceptable?

What I am trying to discern is whether I should send the permanent SoClipNode idea > /dev/null or not, and to make sure we arrive to a section solution that is mergeable with master.

How should we proceed?

[looo]

1) Is my permanent SoClipNode code acceptable?

I think it's the way how it should be implemented. But maybe the clip-node should be inserted when the scenegraph is created.

In an ideal world every view-object should decide on it's own how to deal with a clip-plane: shell: clipping, solid: clipping + capping, 2d-objects like sketch: no clipping. So I think inserting 3 clip-planes (half-views, quarter-views ...) at the root of the scenegraph is a future prove concept.

[abdullah]

Thank you so much for replying.

I think it's the way how it should be implemented. But maybe the clip-node should be inserted when the scenegraph is created.

I am not sure I understand (My coin knowledge is reduced). The scenegraph hangs from the 3D Viewer. The 3D Viewer "multiplexes" ViewProviders. This clip-node is inserted on creation of a ViewProvider, so when the ViewProvider is added to the 3D Viewer, it already has a clip node. On the Constructor of ViewProvider, the clip-node, the transform-node and the switch-node are added (in this order). Do you mean that it should not be added on construction?

In an ideal world every view-object should decide on it's own how to deal with a clip-plane: shell: clipping, solid: clipping + capping, 2d-objects like sketch: no clipping.

I admit to have googled capping with coin without success. But I think I am starting to understanding what you mean here, what about creating a virtual function (e.g. initializeScenegraph) in ViewProvider, and moving the node insertion from the constructor to there (still calling it from the constructor). This way, any ViewProvider could overload the function in order to "not add clipping nodes", "add one, two, or whichever nodes are necessary to implement the clippingnode" ? Then the functions to interact with the clipping plane should be made virtual too, so for example, if I set a clipping plane node (defining the plane of clipping), in the case of the sketcher the function will be made virtual to ignore it as there is no clipping plane, in the clipping+capping object, it will operate with both the clipping and the capping (whatever that is)... is something like this what you would like to see?

So I think inserting 3 clip-planes (half-views, quarter-views ...) at the root of the scenegraph is a future prove concept.

Here I cannot follow you. By scenegraph you are referring to the view scenegraph or the ViewProvider portion of it. What for 3 clip-planes and how do they relate to the half-views, quarter-views,...?

I take advantage of your great Python knowledge. I wanted to set an SbPlane from Python to c++ here.

I did not manage to make it, so I am passing a full "SoClipPlane *". Do you know by any chance how this could be accomplish? The thing is that for a SoClipPlane is already a little bit hackish, but if this would be implemented with other nodes in other circumnstances (I have no idea how capping is implemented), the passing a SoClipPlane to just to define a plane when a SoClipPlane may not even be used, that is a little bit ackward...

[microelly2]

In an ideal world every view-object should decide on it's own how to deal with a clip-plane: shell: clipping, solid: clipping + capping, 2d-objects like sketch: no clipping. So I think inserting 3 clip-planes (half-views, quarter-views ...) at the root of the scenegraph is a future prove concept.

+1
the idea to have methods to add clip planes for each shape separately would be a great thing. methods to manipulate subtrees of the scene graph
would allow to look inside a complex model without cutting the inner layers.

[looo]

I am not sure I understand (My coin knowledge is reduced). The scenegraph hangs from the 3D Viewer. The 3D Viewer "multiplexes" ViewProviders. This clip-node is inserted on creation of a ViewProvider, so when the ViewProvider is added to the 3D Viewer, it already has a clip node. On the Constructor of ViewProvider, the clip-node, the transform-node and the switch-node are added (in this order). Do you mean that it should not be added on construction?

I once read about limitation of the number of active clip-planes in the scene. So I think it's not the best idea to add a clip node to every view-object. In my mind there should be some clip-planes permanently in the scene but not always active. If edit mode of a sketch is started one of the clip-planes get adjusted and on command/key the clipping gets activated. I haven't read your code, but from your describtion I got the impression it is done in a similar way.

I admit to have googled capping with coin without success.

capping is doable with some opengl functionality. I once made a simple implementation which was quite promising: https://forum.freecadweb.org/viewtopic. ... 88#p170708

regarding: https://www.khronos.org/registry/OpenGL ... pPlane.xml
you can at least use 6 clip-planes, but there is a max number depending on the used opengl. So thats why I said to not add a clip-plane to every view-object. Better use a special node or an callback at the beginning and the end of the traversal of an view-object. Capping can be done in a similar way, but here the scenegraph underneath the view-object-node has to be traversed several times (some buffers have to be filled first...)

My idea back then looked like this:
- add some permanent coin.SoClipPlanes() at the beginning of the scene-graph-seperator
- create some special nodes which adds the funtionality to select the clipping style (solid, shell, none)
- insert this special nodes at the beginning of every view-provider-seperator

[DeepSOIC]

you can at least use 6 clip-planes, but there is a max number depending on the used opengl. So thats why I said to not add a clip-plane to every view-object.

Geometry is always clipped against the boundaries of a six-plane frustum in x, y, and z. glClipPlane allows the specification of additional planes, not necessarily perpendicular to the x, y, or z axis, against which all geometry is clipped. To determine the maximum number of additional clipping planes, call glGetIntegerv with argument GL_MAX_CLIP_PLANES. All implementations support at least six such clipping planes. Because the resulting clipping region is the intersection of the defined half-spaces, it is always convex.

Sounds like this limitation is only about the number of clipping planes active simultaneously. In our case, once a viewprovider rendering is finished, it's clipping plane is disabled, before the next one begins to render.

We can have pile-up of clipping planes if we enable clip planes for containers, e.g. Part has a clip plane, Body has, and Pad has, then we end up with a nesting of 3. With a sufficiently deep container nesting, this can potentially be a problem. But my implementation of sketch-plane clipping takes care to not enable such nesting.

[abdullah]

I am not sure I understand (My coin knowledge is reduced). The scenegraph hangs from the 3D Viewer. The 3D Viewer "multiplexes" ViewProviders. This clip-node is inserted on creation of a ViewProvider, so when the ViewProvider is added to the 3D Viewer, it already has a clip node. On the Constructor of ViewProvider, the clip-node, the transform-node and the switch-node are added (in this order). Do you mean that it should not be added on construction?

I once read about limitation of the number of active clip-planes in the scene. So I think it's not the best idea to add a clip node to every view-object. In my mind there should be some clip-planes permanently in the scene but not always active. If edit mode of a sketch is started one of the clip-planes get adjusted and on command/key the clipping gets activated. I haven't read your code, but from your describtion I got the impression it is done in a similar way.

I see. The idea is slightly different. Clipping the whole viewer with the sketch plane does not work properly, for example the red points of the sketcher are gone. This is true even when offsetting the plane slightly. The idea here is to clip the visible objects other than the sketch. So instead of working at Viewer level, working at ViewProvider level.

For this to be done, there are two ways:
1) insert a clipping plane node into all the visible ViewProviders when the section view is required, and deleting the same when they are not longer required
2) let each ViewProvider have a first node being a clip-plane from the beginning with the default plane. It is possible to set the plane from Python. By default this plane is disabled (so no penalty in execution). It can be enabled/disabled by python. So basically the same as in 1) is done, but without inserting /removing nodes, but just setting the plane and enabling the already present SoClipPlane.

My question is whether 2) is preferred over 1). DeepSOIC's working current solution is based on 1). I have written code for 2). So more or less the question is whether it makes sense that I push into master my work (if it is useful, because if it is not >/dev/null).

Of course, what I have written, may be enriched with community-ideas...

[microelly2]

I vote for the possibility to have clipping planes for individual objects separatly.
But I think this should not be restricted only to sketcher but should be available in general:
Define a clipping or more for an object and customize it
having this I can go into an assembly and "open" it wherever I want.
more intersting is to link the root nodes of the objects in combination with clip planes or other items to other viewareas to have different views of the same object the same time.
lets play a bit to see what is possible and what make sense.

[abdullah]

I vote for the possibility to have clipping planes for individual objects separatly.
...
lets play a bit to see what is possible and what make sense.

With my current code you have a clipping plane per view provider, no more, no less. This is more or less a clipping plane per each tree element (not sure about containers).

Because you can find your way in Python and I am sure you will come with great ideas, consider checking the AppImage below.

You can mangle the default clipping planes as described in this commit message:
https://github.com/abdullahtahiriyo/Fre ... a9e1ec2c3e

Just cooked AppImage:
https://github.com/abdullahtahiriyo/Fre ... Plane_v0.1

[looo]

Clipping the whole viewer with the sketch plane does not work properly

you can simple use opengl language to get some objects clipped and others not.

Code: Select all

glEnable(GL_CLIP_PLANE0)

I guess a proper solution for capping/clipping would need some more efforts to get implemented. Maybe microelly2 comes up with some ideas. I would also vote for testing the possibilities before implementing something which maybe is in conflict with a more advanced implementation.

edit:
we could use a callback-node to enable the clip-style with opengl for every object.

The default case is

Code: Select all

glDisable(GL_CLIP_PLANE0)

a clipped object adds:

Code: Select all

glEnable(GL_CLIP_PLANE0)

a solid object needs some more advanced opengl-code..