Independent Rhino Obj -> Compas Obj converter based on rhino3dm

[xarthurx]

Feature Request

As a [role], I want an independent converter so that I can convert Rhino Obj -> Compas Obj outside Rhino Env.

Details

Is your feature request related to a problem? Please describe.
With the Hops plugin, users are able to send Rhino Object to a remote / local HTTP server and process all computation outside Rhino. (whether it is geometry related or not).

However, if main computation is conducted with compas, we need to convert Rhino Object to Compas Object now outside Rhino, whereas the conversion functions provided by compas_rhino has to be run inside a Rhino Environment.

Describe the solution you'd like
While McNeel provides open-sourced rhino3dm for basic Rhino Obj processing, it is possible to conduct whole computation/conversion outside Rhino Environment, and only use Rhino as Input + Visualizer.
It is possible to remove the dependency of Rhino module for compas_rhino.conversion, and allow users to convert objects in pure Cython environment.

Describe alternatives you've considered
Additional python script to convert Rhino Obj inside GH before connecting to Hops. Though not ideal.

[tomvanmele]

i am not sure i understand your point.

would you not have to do a conversion anyway in the outside environment, especially if indeed the bulk of your computation is already in COMPAS and Rhino is just used as input + viz?

is it then not more transparent to convert Rhino objects involved in the outside computation before sending them, so the outside environment knows what to expect?

apart from that, afaik rhino3dm is a CPython package. therefore, using it as the basis for conversions would make compas_rhino unusable in Rhino 7 and in the (still existing) IronPython Editor in Rhino 8. COMPAS 2 does not yet drop support for IronPython unfortunately...

[xarthurx]

i am not sure i understand your point.

would you not have to do a conversion anyway in the outside environment, especially if indeed the bulk of your computation is already in COMPAS and Rhino is just used as input + viz?

is it then not more transparent to convert Rhino objects involved in the outside computation before sending them, so the outside environment knows what to expect?

Some more background here:
I'm using the Hops plugin, where there're some default I/O and you need to comply the data format into Rhino's format:

@hops.component(
    "/cmdProcessor",
    name="cmdProcessor",
    description="Processing Fabrication Cmd",
   
    # icon="",
    inputs=[
        ghs.HopsString("cmd", "cmd", "fab command to process."),
        ghs.HopsPlane("Plane", "P", "default plane for construction"),
        ghs.HopsCurve("PolyCurve", "PC",
                      "default polyline-curve for assembly")
    ],

The HopsXXX are default classes and maintained by the McNeel team. So it is not possible (at least for now) to pass compas object out of Rhino through this approach.

I understand that most of the BRG team are not working inside GH platform, so this might be unusual case. If you need more info, let me know.

apart from that, afaik rhino3dm is a CPython package. therefore, using it as the basis for conversions would make compas_rhino unusable in Rhino 7 and in the (still existing) IronPython Editor in Rhino 8. COMPAS 2 does not yet drop support for IronPython unfortunately...

Does it mean there won't be support on this issue in the near future?

[tomvanmele]

since most of your computation is done in COMPAS anyway, why do you not just use the RPC functionality of COMPAS itself (https://compas.dev/compas/latest/userguide/advanced.rpc.html) instead of Hops?

i am not questioning the need for running certain parts of your computation in a remote environment while working in Rhino/GH. this is done quite often by COMPAS users (using compas.rpc) in both Rhino and GH. i am suggesting that the approach to doing this and to the related/required data conversions might not be the correct or most suited one...

[xarthurx]

since most of your computation is done in COMPAS anyway, why do you not just use the RPC functionality of COMPAS itself (https://compas.dev/compas/latest/userguide/advanced.rpc.html) instead of Hops?

Because with hops you can then host the computation on a remote computer, with only HTTP API provided through Internet -- A potential for Cloud-based computing. And this can further extend to non-COMPAS computation.
I'm not sure if you can do this with RPC. But AFAIK, the RPC protocol is really depending on how you wrote it and less standard than the REST API (which is also newer and less error-prone).

Especially that now Hops is maintained by McNeel and is supposed to have a larger user group.
For industrial applications, I will prefer it to the RPC.

[tomvanmele]

as said, unfortunately we can't drop support for IronPython in COMPAS 2. a CPython-only version is planned for COMPAS 3, but the development for this version will only start close to the summer.

in the meantime perhaps this is something you could consider... https://github.com/compas-dev/tutorials/blob/main/fastapi/README.md

with here a browser-based application... https://github.com/compas-dev/compas-webviewer/blob/main/server.py

[gonzalocasas]

I'm not sure if you can do this with RPC. But AFAIK, the RPC protocol is really depending on how you wrote it and less standard than the REST API (which is also newer and less error-prone).

Yes, you can. RPC Is actually just an http server, so you can host it anywhere you want. RPC does not use the REST style of API architecture, but I think Hops doesn't really do REST either (I know mcneel refers to it as REST in their docs, but in the examples I've seen so far, I got the impression it's just an HTTP API using JSON).

That said, I do agree that Hops provides a very streamlined mechanism to do all of this, and the abstraction of local file/remote server is very clean. (Hops basically does what @tomvanmele was showing right above, but it's wrapped into a very clear UI from the Grasshopper side so it feels very simple)