[Blog] Request: updating geometry

Dear Roman Lygin,

I think all on this forum agree that you're blog is a very welcome addition, again, thanks for your efforts. Romain, as a newcomer to OCC, ( pythonocc, the python wrapped version developed by Thomas Paviot ) what is still pretty hard to understand is how one constructs associative operations. Simple example: if you subtract a sphere from a box, and move the sphere a little, what is the best idiom that the boolean operation should update? The same goes for a bunch of curves; what is the right idiom that the surface build from these input curves updates?

If you would be so kind to consider elaborating on this, that would be _much_ appreciated!

Many thanks in advance,

-jelle

Roman Lygin's picture

Hi jelle,

Thanks for your appreciation.
Let me clarify your question. Do you mean a technique often referred to as 'parametric modeling', i.e. when updating some construction parameter (e.g. radius of a fillet or dimension of the box) you would like to get the whole construction tree to re-run ?

jelle's picture

Hi Roman,

Thanks for your question. I mean basic associativity between in the construction tree, perhaps history is a better term? Correct me if I'm wrong, but parametric is a subset of associativity functionality, right? It sure would be interesting too, but parametrization seems a more mundane issue than getting the associativity going. So far, I haven't come across OCC idioms that do so, hence my interest. Thank you for your willingness to share your wealth of OCC knowledge!

Much appreciated,

-jelle

Roman Lygin's picture

OK, I put this on my todo list.
The subject is rather complex and I guess it will take me a some good deal of time ;-). There are several article drafts already, so I will have to finish them first. Stay tuned.

Thanks again for your interest.

jelle's picture

Terrific! I'm very curious to see what'll you'll come up with ;')
I'm hoping to write a class that'll easy the associativity issue, and really am lost before I even have started, so there you go...
Thanks Roman!

-jelle

Svetlozar Kostadinov's picture

The idiom you're asking for is called topological naming in OCC terms. I am just working with this subject right now and I could say that it's quite complex, confusing and briefly documented. The topological naming classes are packaged in TNaming package. TNaming_NamedShape keeps the history of a given shape. You have one NamedShape for each "evolution step" of a TopoDS_Shape. TopoDS_Shape don't have any history data between each other. Named shapes are used for this purpose. All the evolution changes must be defined by you through TNaming_Builder on creation(modification, deletion, selection) of shapes. The builder creates a NamedShape attribute on a given OCAF label. The NamedShape has internal references to the previous and next named shape in the evolution. Hope that you get the idea where to start looking.
I'll be very thankful if Roman or someone else shares his knowledge on this subject.

jelle's picture

Dear Svetlozar,

Thanks so much for sharing your knowledge regarding topological naming ( that term is really interesting and succinct really... ) thank you for sharing this critical information, that's a huge leap ahead. Very excited to hear OCC supporting the idiom.

Thanks again,

-jelle

Svetlozar Kostadinov's picture

I have a lot of problems trying to figure out the rules for custom topological naming of the result shape. I need full and clear definition of what is expected by OCC to solve correctly the naming. The info in docs doesn't give me the complete understanding.
The solving process needs all used shapes and subshapes of any level to be "named". If it isn't named you cannot use it in the parametric rebuilding. The term "Named" means to be in the map of TNaming_UsedShapes which is a map of TopoDS_Shape -> TNaming_NamedShape. If one operation has a shape argument the operation must know where its NamedShape is.

jelle's picture

Me too! Its really hard to figure out how Topological Naming really works...
The example given in ocaf_functionmechanism_wp.pdf is incomplete, hence pretty much useless in this state...
Which is a *real* pity, since it would be such valuable information...

Wang Chris's picture

Hi, Jelle,

Can you tell me where to find "ocaf_functionmechanism_wp.pdf"? Thanks a lot.

jelle's picture

Sure, have a look in:
OpenCASCADE6.3.0/doc/Overview/ocaf_functionmechanism_wp.pdf

Wang, if you succeed ( good luck to you! ) in building the example in the .pdf, would you be willing to share it?
It would be a *huge* help ;')

Also, somewhere on the forum the old 5.1 pdf docs were posted too. I found these helpful in understanding the TFuncation / Tnaming concepts. There's an example of a box with a fillet that is being scaled that is really good. Its the _modat_5_1.pdf.

-jelle

Wang Chris's picture

Thanks, jelle.

I will try them and let you know the results.

jelle's picture

Hi Wang,

Any luck so far on exploring Tnaming / Tfunction?
Curious to hear your findings...

P Dolbey's picture
jelle's picture

cool! so far these have been real helpful. much appreciated Pete!