It’s working really well, but I’ve also noticed that the block definition making up the instances isn’t surfacing in the filtering menu, and is not visible in the scene:
This is exactly as I’d expect, but seems like a special case, as this doesn’t happen with things like alignment profiles, which are also abstract graphs, made up of lines and curves, but they do get rendered in the viewer.
BlockDefinitions are currently hardcoded to be skipped if found in the tree for traversal purposes, and because the geometry associated with them is not detached, they get excluded as well.
Then, block instances are hardcoded to look up and use the skipped geometry in the definitions.
Regardless, I think my key thing is it would be good to control the “abstractness” of geometry with a bit more consideration - it’s been raised in other places, but in the example below
is the actual preview data, a compound curve of both graphs.
If we already have a special case way of labelling geometry as abstract or outside the scene (referencing them only through the defintion field of an instance), it’d be good to be able to make that explicit.
// marker for the traversal tree that any preview data below this point should be skipped unless directly referenced elsewhere
AbstractGeometry : Base
//Additional functionality for Revit and Rhino
Block : AbstractGeometry
BlockDefinitions are currently hardcoded to be skipped if found in the tree for traversal purposes, and because the geometry associated with them is not detached, they get excluded as well.
Then, block instances are hardcoded to look up and use the skipped geometry in the definitions
The GeometryConverter handles geometry strictly. It takes in TreeNodes and constructs their raw geometric representation. Block nodes or any other instance nodes do not have any inherent geometry, that’s why they are being skipped.
On the other hand, if there are displayable objects missing from your scene, then that’s an issue that we need to look into, but it won’t be caused by the GeometryConverter. From your linked stream (the one with the snowmen), what displayables are missing from the 3D view?
If I explicitly drop a reference to a BlockDefinition into the tree, it will render the geometry in the sub elements, but if I only reference them through instances, then it won’t. That feels like a special case to me, as I can’t get that behaviour to replicate elsewhere.
If I explicitly drop a reference to a BlockDefinition into the tree, it will render the geometry in the sub elements, but if I only reference them through instances, then it won’t
Not sure I perfectly understand this, so could you perhaps exemplify with two streams that do one then the other?
