Are IXBimGeometryObjects available in scene or are they just intermediates to create XBimShapeGeometry?

Belrius commented 3 years ago

Hi,

I'm looking to get a hold of the BRep representations of products.

Processing appears to go...

IIfcGeometricRepresentationItem -> XBimGeometryObjects -> XBimShapeGeometry -> XBimShapeInstance

XBimGeometryObjects like XBimSolid give access to these but I don't see a how to get to these working back from the XBimShapeInstance or XBimShapeGeometry from the scene.

Are they thrown away? In XBim3DModelContext I see that there is a class called XbimCreateContextHelper which seems to cache these so they can be used for CSG / Boolean operations. But they don't seem to be kept.

I can use XBimGeometryEngine to create these myself from each IIfcGeometricRepresentationItem. I seem to be getting frequent cases of corrupted memory when doing this though.

Not sure if these corruptions exist and are being caught when XBim creates the scene, or if creating the same object more than once is causing an issue?

Any thoughts on this welcome.

Many thanks Andrew

SteveLockley commented 3 years ago

You can call the geometry engine functions directly to get the BREP

Create an Instance of XbimGeomtryEngine Then call the relevant function to create a BREPSolid, shell, face etc

If you look in the test project there are loads of examples of how to do this

Belrius commented 3 years ago

Hi Steve,

Yes, that’s what I’m doing at the moment, thank you.

I was wondering if these were stored and could be reached from the shapeInstances, as these have references to the material ID’s. IXBimGeometry objects don’t.

I think I am getting to understand the code well enough that I can find ways around it though.

Many thanks for your reply.

Andrew

SteveLockley commented 3 years ago

OK sorry Andrew, I didn’t realise you were the person wanting to materialise faces etc. I just responded a bit blind. I have started some work on this in the version 6 branch and hit a few issues below

There are a couple of approaches

The recommended Opencascade way is to create effectively a dictionary that links OCC shapes to any other ID/Object (in unmanaged code), they have support for this in their higher level visualisation libraries
We could adapt the very base level OCC TShape so that it holds a simple ID (maybe an int). The OCC argument against this is it is not extensible, but maybe we only want one ID (the IFC label?)
Bring it to the top level and extend the XbimShapes (XbimSolid, XbimShell, XbimFace etc) to allow maps to other objects

These all have different merits and problems

This provides one place to look up a material effectively through the object pointer of the TShape. We would have to provide a managed interface to this dictionary but we have good examples from OCC on how to do it. It might help us with consideration of how to assign materials to shapes after Boolean operations.
Merit is that during processing the TShape is the only representation of the geometry that is persistent, the manage objects are volatile. So the link to the shape will persist whilst processing. The overhead of an int to every shape (vertex,edge,wire,shell,solid etc) might be significant with some very large objects, but probably not in 64 bit systems. Other issue is we have to pass material ids all the way down to every shape. So if we build an extruded shape, all the faces are created inside OCC code and we have to retrospectively add the material and have some kind of cascade model for identifying materials. OCC is really bad at looking up the cascade chain. To think about is the fact that most TShapes we create are NOT related to IFC objects. i.e what do you do with a face that has been cut in a Boolean operation by another solid, which material does each face take?
The plus and minus of this is that we need to consider making OCC our surfaced representation and not triangulation. i.e we triangulate after materialisation. This potentially will give the best results.

The approach I have adopted so far in Version 6 is a combination of 2 and 3. Extend the XbimShape objects to be aware of materials but to store/persist the information in the OCC native object (because XbimShapes are volatile). i.e. pass the material information down as we build the shapes and potentially give every shape an explicit material ID, so no cascading (Maybe stop at faces). Alternatives would be to give every OCC shape a unique ID and keep a managed dictionary linking material and shape (maybe a multiValueDictionary), this may have some issues with object lifecycle management and garbage collection, it could mean all objects are kept alive for a lot longer.

Bit of a ramble, sorry

Belrius commented 3 years ago

Thanks Steve,

I’ll spend some time digesting this and get back to you.

Best regards Andrew

Belrius commented 3 years ago

Hi Steve,

I’d figured that this must have been a complex task. Boolean intersections of objects with different materials were not something I’d considered but I can see how it would be a nightmare.

My use case is much simpler than this in general.

I need to determine which parts of a wall are brick / cladding / plasterboard etc.
I cut walls and add and remove doors and windows when applying new floor plan options (eg a different kitchen or garage). Since I’m doing this in unity I’ve written my own routines to do this.

I think with the improved understanding that I have of how the back end works I can apply my own logic for the application of materials in my limited use case now.

Still keen to touch base, but I’m not sure how useful I’ll be in the heroic battle you have on your hands with providing a general purpose solution.

Best regards Andrew

Belrius commented 3 years ago

Hi guys,

Apologies, something’s come up. Could we postpone or cancel this meeting?

Regards Andrew

From: Andrew Hoadley Sent: Friday, 25 September 2020 3:22 PM To: xBimTeam/XbimGeometry reply@reply.github.com; xBimTeam/XbimGeometry XbimGeometry@noreply.github.com Cc: Author author@noreply.github.com; Greg Lane greg.lane@situsystems.com Subject: RE: [xBimTeam/XbimGeometry] Are IXBimGeometryObjects available in scene or are they just intermediates to create XBimShapeGeometry? (#284)

Hi Steve,

I’d figured that this must have been a complex task. Boolean intersections of objects with different materials were not something I’d considered but I can see how it would be a nightmare.

My use case is much simpler than this in general.

I need to determine which parts of a wall are brick / cladding / plasterboard etc.
I cut walls and add and remove doors and windows when applying new floor plan options (eg a different kitchen or garage). Since I’m doing this in unity I’ve written my own routines to do this.

I think with the improved understanding that I have of how the back end works I can apply my own logic for the application of materials in my limited use case now.

Still keen to touch base, but I’m not sure how useful I’ll be in the heroic battle you have on your hands with providing a general purpose solution.

Best regards Andrew

From: Andrew Hoadley Sent: Tuesday, 22 September 2020 5:30 PM To: xBimTeam/XbimGeometry reply@reply.github.com<mailto:reply@reply.github.com>; xBimTeam/XbimGeometry XbimGeometry@noreply.github.com<mailto:XbimGeometry@noreply.github.com> Cc: Author author@noreply.github.com<mailto:author@noreply.github.com> Subject: RE: [xBimTeam/XbimGeometry] Are IXBimGeometryObjects available in scene or are they just intermediates to create XBimShapeGeometry? (#284)

Thanks Steve,

I’ll spend some time digesting this and get back to you.

Best regards Andrew

From: Steve Lockley notifications@github.com<mailto:notifications@github.com> Sent: Tuesday, 22 September 2020 5:05 PM To: xBimTeam/XbimGeometry XbimGeometry@noreply.github.com<mailto:XbimGeometry@noreply.github.com> Cc: Andrew Hoadley andrew.hoadley@situsystems.com<mailto:andrew.hoadley@situsystems.com>; Author author@noreply.github.com<mailto:author@noreply.github.com> Subject: Re: [xBimTeam/XbimGeometry] Are IXBimGeometryObjects available in scene or are they just intermediates to create XBimShapeGeometry? (#284)

OK sorry Andrew, I didn’t realise you were the person wanting to materialise faces etc. I just responded a bit blind. I have started some work on this in the version 6 branch and hit a few issues below

There are a couple of approaches

The recommended Opencascade way is to create effectively a dictionary that links OCC shapes to any other ID/Object (in unmanaged code), they have support for this in their higher level visualisation libraries
We could adapt the very base level OCC TShape so that it holds a simple ID (maybe an int). The OCC argument against this is it is not extensible, but maybe we only want one ID (the IFC label?)
Bring it to the top level and extend the XbimShapes (XbimSolid, XbimShell, XbimFace etc) to allow maps to other objects

These all have different merits and problems

This provides one place to look up a material effectively through the object pointer of the TShape. We would have to provide a managed interface to this dictionary but we have good examples from OCC on how to do it. It might help us with consideration of how to assign materials to shapes after Boolean operations.
Merit is that during processing the TShape is the only representation of the geometry that is persistent, the manage objects are volatile. So the link to the shape will persist whilst processing. The overhead of an int to every shape (vertex,edge,wire,shell,solid etc) might be significant with some very large objects, but probably not in 64 bit systems. Other issue is we have to pass material ids all the way down to every shape. So if we build an extruded shape, all the faces are created inside OCC code and we have to retrospectively add the material and have some kind of cascade model for identifying materials. OCC is really bad at looking up the cascade chain. To think about is the fact that most TShapes we create are NOT related to IFC objects. i.e what do you do with a face that has been cut in a Boolean operation by another solid, which material does each face take?
The plus and minus of this is that we need to consider making OCC our surfaced representation and not triangulation. i.e we triangulate after materialisation. This potentially will give the best results.

The approach I have adopted so far in Version 6 is a combination of 2 and 3. Extend the XbimShape objects to be aware of materials but to store/persist the information in the OCC native object (because XbimShapes are volatile). i.e. pass the material information down as we build the shapes and potentially give every shape an explicit material ID, so no cascading (Maybe stop at faces). Alternatives would be to give every OCC shape a unique ID and keep a managed dictionary linking material and shape (maybe a multiValueDictionary), this may have some issues with object lifecycle management and garbage collection, it could mean all objects are kept alive for a lot longer.

Bit of a ramble, sorry

From: Andrew H notifications@github.com<mailto:notifications@github.com> Sent: 22 September 2020 01:56 To: xBimTeam/XbimGeometry XbimGeometry@noreply.github.com<mailto:XbimGeometry@noreply.github.com> Cc: Steve Lockley steve.lockley@xbim.net<mailto:steve.lockley@xbim.net>; Assign assign@noreply.github.com<mailto:assign@noreply.github.com> Subject: Re: [xBimTeam/XbimGeometry] Are IXBimGeometryObjects available in scene or are they just intermediates to create XBimShapeGeometry? (#284)

Hi Steve,

Yes, that’s what I’m doing at the moment, thank you.

I was wondering if these were stored and could be reached from the shapeInstances, as these have references to the material ID’s. IXBimGeometry objects don’t.

I think I am getting to understand the code well enough that I can find ways around it though.

Many thanks for your reply.

Andrew

From: Steve Lockley notifications@github.com<mailto:notifications@github.com<mailto:notifications@github.com%3cmailto:notifications@github.com>> Sent: Monday, 21 September 2020 9:19 PM To: xBimTeam/XbimGeometry XbimGeometry@noreply.github.com<mailto:XbimGeometry@noreply.github.com<mailto:XbimGeometry@noreply.github.com%3cmailto:XbimGeometry@noreply.github.com>> Cc: Andrew Hoadley andrew.hoadley@situsystems.com<mailto:andrew.hoadley@situsystems.com<mailto:andrew.hoadley@situsystems.com%3cmailto:andrew.hoadley@situsystems.com>>; Author author@noreply.github.com<mailto:author@noreply.github.com<mailto:author@noreply.github.com%3cmailto:author@noreply.github.com>> Subject: Re: [xBimTeam/XbimGeometry] Are IXBimGeometryObjects available in scene or are they just intermediates to create XBimShapeGeometry? (#284)

You can call the geometry engine functions directly to get the BREP

Create an Instance of XbimGeomtryEngine Then call the relevant function to create a BREPSolid, shell, face etc

If you look in the test project there are loads of examples of how to do this

Hi,

I'm looking to get a hold of the BRep representations of products.

Processing appears to go...

IIfcGeometricRepresentationItem -> XBimGeometryObjects -> XBimShapeGeometry -> XBimShapeInstance

XBimGeometryObjects like XBimSolid give access to these but I don't see a how to get to these working back from the XBimShapeInstance or XBimShapeGeometry from the scene.

Are they thrown away? In XBim3DModelContext I see that there is a class called XbimCreateContextHelper which seems to cache these so they can be used for CSG / Boolean operations. But they don't seem to be kept.

I can use XBimGeometryEngine to create these myself from each IIfcGeometricRepresentationItem. I seem to be getting frequent cases of corrupted memory when doing this though.

Not sure if these corruptions exist and are being caught when XBim creates the scene, or if creating the same object more than once is causing an issue?

Any thoughts on this welcome.

Many thanks Andrew

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/xBimTeam/XbimGeometry/issues/284, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB6XPJJR5Y5XZCAAVGC5RRTSG3ZBHANCNFSM4RUFDEVQ.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/xBimTeam/XbimGeometry/issues/284#issuecomment-696052082, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALHONILC6QC5AGN5V4PJ3LSG4ZDTANCNFSM4RUFDEVQ.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/xBimTeam/XbimGeometry/issues/284#issuecomment-696457375, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB6XPJMGBRPAF4TIIH7TVLDSG7YZRANCNFSM4RUFDEVQ.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/xBimTeam/XbimGeometry/issues/284#issuecomment-696546490, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALHONJPAZEPMITIJNKIYLTSHBEAPANCNFSM4RUFDEVQ.

andyward commented 3 years ago

[Admin note: I just tidied up the email chain a bit]

xBimTeam / XbimGeometry

Are IXBimGeometryObjects available in scene or are they just intermediates to create XBimShapeGeometry? #284