Wed, 07/28/2021 - 15:27
Forums:
Initially after loading CAD files (using STEPCAFControl_Reader for example), if I hide that object using AIS_InteractiveContext::Erase, it does not hide. When I then make if visible again with Display and then Erase it again, it finally becomes invisible and it works as it is supposed to. So why is it not hiding on the very first time ??? Some kind of initialisation missing ???
Wed, 07/28/2021 - 15:28
This youtube video shows it: https://www.youtube.com/watch?v=W6jJpb0jtjg&ab_channel=LucWens
Wed, 07/28/2021 - 15:30
Adding is done with RecurseAdd:
When I put DisplayMode fix to 1, then it does hide from the first time, but then my STL meshes are not shown proper anymore.
show/hide is done with RecurseShowHide
Wed, 07/28/2021 - 15:31
Here is the source file
Thu, 07/29/2021 - 15:05
I'm wondering if this is a bug, so the next line
makes that AIScontext->Display and AIScontext->Erase work like expected.
The next line, having the AIS_Object using its own displaymode, and in practice returning 0 for Shaded, makes Display and Erase behave differently:
Makes no sense to me ......
Thu, 07/29/2021 - 16:17
Your code relies on Parent/Children relationship logic between AIS_InteractiveObject presentations. This API is currently somewhat incomplete and not well defined - in particular behavior with inconsistent display modes used for children and parents.
Fill free to report bugs and suggest patches to mentioned functionality if you found it useful for your application. Current development snapshot of OCCT 7.6.0dev also includes one bugfix in Parent/Children visibility logic, though I cannot say if it affects the problem described in this topic anyhow.
Otherwise, I would suggest avoiding Parent/Children relationships between AIS_InteractiveObject's and implement logic propagating necessary attributes (transformations / visibility / etc.) from tree-like structure to a plain list of AIS_InteractiveObject basing on application requirements.
Thu, 07/29/2021 - 19:41
It does indeed relate to Parent/Children relationship.
I have a small demo project that shows the problem and will add this to a bug report.
I'll need to rethink the hierarchy in my current main project.
Tnx
Mon, 08/02/2021 - 17:03
Still a question: would using OCAF make a difference? The hierarchy is inherent to my application: a 6DOF coordinate system to which CAD files can attached and that is positioned by input of dynamic optical 6DOF measurements. I guess OCAF would allow me to retain this hierarchy, but I'm not sure if OCAF would suffer from the same bug
Mon, 08/02/2021 - 20:15
I don't see how OCAF could make any difference. OCAF is focused on data model storage, not on visualization - so that it is up to application to decide how to replicate hierarchy in OCAF document within the AIS viewer.
Usually, the main thing to reproduce in the viewer from the tree structure in the document is proper part transformation, inheriting transformation of all parents. This doesn't require creation of AIS_InteractiveObject with parents and children - you may define local local transformation (TopLoc_Location/gp_Trsf) of each AIS_InteractiveObject as a final transformation with all parents premultiplied, and take care to update object location AIS_InteractiveContext::SetLocation() on update of any parent.