For Unity, Unreal Engine and I think ThreeJS as well, the only option for rendering meshes is to define each face as a triangle. This means quads, n-gons and breps are not supported at all in these environments.
As a result, manual mesh triangulation and using display values is currently the best I can do in these environments which then means that updating a stream’s geometry within on of these clients becomes impossible because I can’t convert my changes back into the n-gon / brep format without some serious and messy overhead in the client code.
I can’t think of a solution to this but would the 2.0 rewrite enable some slick new oportunity to help in these cases?
This way, even the web viewer can be used for some basic modelling and adjustments.
Thanks for starting this discussion! I’ll begin by saying that Speckle has never promised “seamless interoperability” and that we’ll always have to work within existing software’s capabilities.
Speckle 2.0 doesn’t change how we’re dealing with this issue:
objects will have a displayMesh property containing their mesh representation only when possible
this will be the primary way of showing objects in the web viewer (three.js) and most likely in Unity / Unreal
if an object doesn’t have a displayMesh we’ll default to whatever baseGeometry it has (if supported)
Now let’s say that you are sending a Revit wall to Unreal, the speckle wall object in Unreal will have 2 geometrical properties:
baseGeometry (a line, representing the wall base line)
displayMesh (a boxy mesh representation of the wall)
If you wanted to modify the wall, you could still let the user modify the base line, it would then be up to you deciding if it’s worth trying to re-create a corresponding displayMesh by using the width and height properties of the object. To be honest, I don’t think it’s worth the effort because of the complexity and limited applicability (eg wouldn’t work with most other Revit families).
That’s the same approach we’ve taken in Grasshopper with the schema builder component, yes you can create “BIM/Revit” objects but they won’t have any displayMesh.
I’m inclined to think it’s easy to triangulate a given ngon on the receiving end, just before pushing into the display pipe, if I’m correct in my mental assumptions, even if that borks sending stuff out again cleanly (in which case @teocomi’s suggestion might help). There’s no silver bullet.
I guess, for exchanges between host software that support ngons (ie, blender) supporting them is fine. For threejs, etc. fallback to triangulation is an acceptable compromise?
I think that’s correct: it’s the job of the receiving app to triangulate, or just not support N-gons. Generally, if you’re just displaying the model, then you won’t be sending anything back out again, but I’m sure there are edge cases…