Regression on AIS_InteractiveConnect and AIS_MultipleConnected support in 6.8.0

Roman Lygin's picture

Version 6.8.0 apparently introduced some significant change about how the IO's can be connected.
The former use case as explained in my blog post (http://opencascade.blogspot.ru/2013/11/ais-connecting-objects.html) has been broken.
In particular an exception is currently thrown in ConnectedInteractive:

void AIS_ConnectedInteractive::Connect (const Handle(AIS_InteractiveObject)& theAnotherObj)
{...
else
{
Standard_ProgramError::Raise ("AIS_ConnectedInteractive::Connect() - object without own presentation can not be connected");
}
}

The change seems to be introduced in #25371 (http://tracker.dev.opencascade.org/view.php?id=25371), to which access is denied for
community members to get further details.

The use case as explained in the above blog post is to create a hierarchy of AIS_IO's via connection of CI and MC. Here is
an excerpt as pseudo-code:

Handle_AIS_InteractiveObject CreateIO (const SceneGraphElement& e)
{
Handle_AIS_InteractiveObject r;
if (e is a Part (i.e. leaf of scene graph)) {
r = create_concrete_interativeobject();
} else if (e is Instance) {
Handle_AIS_InteractiveObject ref_r = CreateIO (e->reference); //recursion
Handle_AIS_ConnectedInteractive i = new AIS_ConnectedInteractive;
i->Connect (ref_r, location);
r = i;
} else if (e is assembly) {
Handle_AIS_MultipleConnected m = new AIS_MultipleConnected;
for (all childs in assembly) {
Handle_AIS_InteractiveObject c = CreateIO (child_i); //recursion
m->Connect (c);
}
r = m;
}
return r;
}

Thus, there never exists a presentation for any IO which gets connected and any interim IO will ever be displayed itself.

Neither the Release Notes nor the Visualization User's Guide invalidate the formerly valid and working use case. So please do
restore the possibility existed before and meanwhile please advise on a proper work-around.

Thank you in advance,
Roman

Roman Lygin's picture

#25560

http://tracker.dev.opencascade.org/view.php?id=25560

Posted to keep tracking to the Mantis

kgv's picture

Roman Lygin The change seems

Roman Lygin

The change seems to be introduced in #25371 (http://tracker.dev.opencascade.org/view.php?id=25371), to which access is denied for
community members to get further details.

The change has been introduced by publicly available #24837 (revise design and implementation of connected Interactive Objects). The patch for #25371 does not change the behavior but just marks (new) API misuse explicitly - otherwise your code would not throw any exceptions but would not work anyway.

san's picture

Change in connection API

Hello Roman,

As Kirill has already pointed out, the exception is just the way to indicate API misuse.

Since 6.8.0, the correct way to build the object hierarchy is to use AIS_MultipleConnectedInteractive class at both "instance" and "assembly" levels of your example.
Please, refer to AIS_MultipleConnectedInteractive::Connect() overloads and check their arguments, normally you should find all necessary options there.

Perhaps, you will also want to have a deeper look inside the code of AIS_MultipleConnectedInteractive: this class is just a convenience layer over the two base mechanisms included into OCCT 6.8.0 visualization:

  • Instancing based on AIS_ConnectedInteractive class
  • Building the object hierarchy - or a scene graph - using PrsMgr_PresentableObject::AddChild() method

It would be great to know if your code works after migration!

Meanwhile, we will enhance the Visualization User's Guide by a detailed description of the new connection mechanism and its usage. This should have been done in the scope of issue 25343 (see point 9 in the description) prior to release 6.8.0 but corresponding piece of documentation did not reach the repository for some reason, alas.

Best regards,
Sergey

Roman Lygin's picture

Work-around

Hello Sergey,

Thank you for suggested redesign. Good to know there is it. Let me take some time for that.
If MCI is supposed to be used both for "instance" (i.e. ref + trsf) and "assembly" (i.e. children) then what is a use case for CI ? In which circumstances should it be used (where MCI cannot) ?

Best regards,
Roman

san's picture

Re: Work-around

MCI is always suitable, it uses internally CI when needed and handles all connection cases properly.
However, if you just need to create a translated instance of an IO having real geometry (presentation) inside, you can use CI for this directly.

Roman Lygin's picture

Hi Sergey, Have just got back

Hi Sergey,

Have just got back to porting of our development branch on OCC6.8.0. This had to be deferred for the time being.
Indeed, the following change per your suggestion did the trick:
#if OCC_VERSION_HEX >= 0x060800
Handle_AIS_MultipleConnectedInteractive r = new AIS_MultipleConnectedInteractive;
#else
Handle_AIS_ConnectedInteractive r = new AIS_ConnectedInteractive;
#endif
r->Connect (theObject, aLoc);

The way MCI are constructed has not been changed:
...
__CADEX_DEFINE_HANDLE_BY_STATIC_CAST(AIS_MultipleConnectedInteractive, aM, myResult);
aM->Connect (theObject);
...

So thank you again.
Best regards,
Roman

san's picture

Thanks for feedback!

Hello Roman,

Thank you for finding time to confirm the solution!
Hope this might help the others to make the most from the reworked connected objects in OCCT.

Best regards,
Sergey

www.opencascade.com

Copyright 2011-2016
OPEN CASCADE SAS
Contact us