Skip to content

Conversation

@chenkasirer
Copy link
Member

@chenkasirer chenkasirer commented Jul 13, 2022

WIP: added initial implementation of a compas.geometry.BRep with a Rhino backend in compas_rhino.geometry.brep.

  1. Copied over the interface for BRep from compas_occ into compas.geometry.BRep and generalized.
  2. Started implementing the package compas_rhino.geometry.brep with wrapping types for brep, edge, vertex and loop.
  3. Implemented the serializing part of data (in some also the setter but not tested)

I could serialize a simple box brep with:

from pprint import pprint
from compas.geometry import Box
from compas.geometry import BRep
from compas.data import json_dumps

box = Box.from_width_height_depth(5., 5., 10.)
brep = BRep.from_box(box)

pprint(json_dumps(brep))

Opening this draft PR to start a conversation about the approach.

What type of change is this?

  • New feature in a backwards-compatible manner.

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

  • I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
  • I ran all tests on my computer and it's all green (i.e. invoke test).
  • I ran lint on my computer and there are no errors (i.e. invoke lint).
  • I added new functions/classes and made them available on a second-level import, e.g. compas.datastructures.Mesh.
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added necessary documentation (if appropriate)

Comment on lines 64 to 66
type : {TopAbs_COMPOUND, TopAbs_COMPSOLID, TopAbs_SOLID, TopAbs_SHELL, TopAbs_FACE, TopAbs_WIRE, TopAbs_EDGE, TopAbs_VERTEX, TopAbs_SHAPE}, read-only
The type of BRep shape.
orientation : {TopAbs_FORWARD, TopAbs_REVERSED, TopAbs_INTERNAL, TopAbs_EXTERNAL}, read-only
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also this constants seem to be occ specific, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes they are. we could wrap this and make it more general so it applies to both/all backends...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question about this: do we need an external/interface representation for these? In compas_occ I've only seen them being used via is_compound(), is_shell() etc.. If that's the case we don't really need a generic representation. Do you see a need?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, no need...

Copy link
Member

@tomvanmele tomvanmele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good start! :)

'NurbsSurface'
'NurbsSurface',

"Brep",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will need to expose vertex, edge, loop, and face as well...

class RhinoBRep(Geometry):
def __init__(self):
super(RhinoBRep, self).__init__()
self.rhino_brep = None
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self._brep?
and the same for compas_occ then, instead of self.occ_shape?


@classmethod
def from_faces(cls, faces):
brep = Brep()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be implemented.

While we're here, this part will have to be a bit different than compas_occ. BrepEdge, BrepFace and even BrepVertex all don't have a public constructor and can only be created via the Brep instance (e.g. Brep().Vertices.Add(Point3d)).

Consequently, de-serializing a compas_rhino.geometry.RhinoBRepVertex alone does not result in a Rhino.Geometry.BrepVertex instance. Therefore, I imagine the de-serialized building blocks will be containing COMPAS types and the actual reconstruction of the native Rhino Brep will take place here, in from_faces. It can then also "inject" the native types to each of the underlying objects.

Do you see a better way to go about it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, that makes sense to me. in fact, also in compas_occ we should try to funnel everything through the Brep class, and expose the other types only through the element accessors (.vertices, .edges, .loops, .faces), or for development pruposes.


class RhinoBRepFace(Data):

TOLERANCE = 1e-6
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need a better solution for this.
also just in general, we need a formal location to store compas-wide configuration options...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gonzalocasas mentioned once these can be handled with some global COMPAS precision system. I'll look into it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, i wouldn't necessarily call it a system, but there is indeed a precision setting compas.PRECISION :)
a more robust version of this that also allows for other settings would be a good thing...

@chenkasirer chenkasirer marked this pull request as ready for review July 26, 2022 15:13
Copy link
Member

@tomvanmele tomvanmele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is an old review i forgot to submit so it might be a bit outdated...

Comment on lines 70 to 78
"""
Parameters
----------
data
Returns
-------
"""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setters are meant to be documented on the getter...

Comment on lines 91 to 97
"""
Returns the native representation of this Brep.
Returns
-------
:class: `Rhino.Geometry.Brep`
"""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason some of the properties and others not? perhaps leave this one out as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean why there's public access to the native type in Brep but not in the others?

I found this is useful at the moment due to the lack of a BrepArtist for example. That way you can plug-in Brep.native_brep to a GH geometry component to visualize.

Maybe once there's more extensive support for Brep in COMPAS it would make sense to remove this one as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no sorry, there were some crucial words missing...

any reason some of the properties HAVE DOCSTRINGS and others not

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No particular reason ;)
Removed all docstrings from properties and added to Attributes instead.

from compas.data import Data


class BrepFace(Data):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if i remember correctly this creates major problem in ironpython with memory leaks etc

@chenkasirer chenkasirer merged commit ec1b9f8 into main Aug 26, 2022
@chenkasirer chenkasirer deleted the geometry_brep branch August 26, 2022 08:12
@chenkasirer chenkasirer mentioned this pull request Oct 4, 2022
7 tasks
@chenkasirer chenkasirer mentioned this pull request May 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants