I started experimenting with speckle 2.0 and tried to send some VisualArq objects (e.g., a slab and a few columns) from within Rhino to the speckle server. From the results on the browser I figure that VisualArq objects may not be supported. The objects seem to be placed on the origin (perhaps they are all overlapped) and there are some points on the locations where they were inserted in the model. I imagine this must be related with how VisualArq creates the objects as blocks.
So the question is what can be done to improve the compatibility of VisualArq with speckle?
Thanks for reporting this. I’m not an experienced VisualArq user and I must confess it’s not something that was in my radar for testing
The fact that they are all placed around the origin makes me think that VisualArq has a different way of dealing with the relative position of objects than native rhino geometry? My guess is that this could potentially improve with the new support for blocks that @clrkng has been working on. But I’m not sure of the implications of this.
Anyway, thanks for reporting this. I’ll have a discussion with the team about how to deal with this case. We’ll keep you posted on this thread.
I would love to have a look at the streamed objects. Is that stream in the speckle.xyz server? If so, could you add me as a reviewer (alan@speckle.systems) so I can have a look?
Done!
In the meantime I exploded the VisualArq objects and sent these objects in a new stream. These are now correctly placed, which confirms my supposition that is related with the way VisualArq handles the blocks.
I will cross post this issue on discourse.mcneel, maybe fsalla can chime in.
Awesome! Thanks for sharing @filipejsbrandao ! Just confirming with @dimitrie, VisualArq objects are being sent as blocks through Speckle, so they must be blocks in some form. We think it may be one of two things (or both!):
Currently the viewer doesn’t know what a “block” is (pending feature, coming soon!) so it will not apply any transforms to it (which is why you were seeing the blocks located around the origin) although the transform info is being sent.
The block implementation still needs some time to “grow”, and it is my understanding that currently nested blocks are not being dealt with properly (not sure if VisualArq uses nested blocks… but I would guess so)
Both of these changes are already on the roadmap and will be dealt with pretty soon, so hopefully we’ll we can provide you a better experience then. I’ll post the GitHub issues here when they’re created.
This is Enric Marques, a VisualARQ lead developer from Asuni!
I can confirm that VisualARQ custom objects are just Rhino blocks with extra features. Most of them are using an ECS (element coordinate system), so if Speckle is not applying the block transform, it is normal that they appear in a fixed position at the world origin.
I can also confirm that in some cases, there are nested blocks:
If the user has a user instance definition that contains VisualARQ objects
Some VisuaARQ objects contain nested VisualARQ objects (for example, a roof contains its slabs in a nested block).
Please, let me know if there is anything we can do to improve VisualARQ ↔ Speckle compatibility.
If nested blocks are important to support, we can bump that feature up in priority!
Currently, non-nested blocks should still be received correctly back in Rhino, even if they are not displayed properly in the viewer - let me know if you’re having issues with this.
The transform property for our Speckle block is expecting a 4x4 transform matrix where:
the 3x3 sub-matrix determines scaling and rotation
the 4th column’s 1st 3 entries define translation
the 4th row is an identity row
Does VisualARQ use the same convention for block transforms?
VisualARQ object instances do always use affine transformations, so yes, I think we use the same convention.
But take into account that users can create user blocks, and the matrix on those blocks is not managed by VisualARQ. It is true that users can only modify this matrix using Rhino commands (like Rotate, Move, Scale, Shear, etc), but other plugins may apply a projective transformation on a block, although I don’t know if that is even supported by Rhino.
Good to know! In any case, we should be handling cases of non-affine projective transformation matrices in our converters - will add that to our sprint
I’m glad to see efforts to support Visual ARQ. I was just testing if it works and it places the geometry in the right places, but converted to regular Rhino blocks. Any chance to retain original VA objects?
