Crash (Multi-User Rhino) 1.4.2-beta has been released!

ahhh right :upside_down_face: that would make sense!

Here’s what I get in the cmd terminal:

warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]
      Failed to determine the https port for redirect.

And it does appear to open the docs/help in a browser tab though it’s an empty/blank page on my end?

I see “Welcome to Crash!” with the localhost subtext on the browser tab but the page itself is a blank white page with no content.

@michaelvollrath
Are you opening http://0.0.0.0:8080 or http://localhost:8080 ? The terminal will offer http://0.0.0.0:8080. You’ll want to navigate to http://localhost:8080.

Failed to determine the https port for redirect.

We’re using http locally (not https) so it will fail, not something to be worried about (locally)

1 Like

Ah, in this case then, Crash would be a better solution. Ideally you’d create some kind of app for the Vision pro which hosts a crash client and talks to the crash server and then you could walk around the model (I’ve not used the vision pro but I’m imagining you can do things similar to Virtual Reality goggles).

Yes you’re right, in this case, pixel for pixel won’t cut it.

Where would you open the pull request? Crash is a plugin for Rhino, are you running Rhino on the vision pro?

Regarding Grasshopper crash does not currently communicate anything about the ghostly grasshopper objects or components. But crash does have a wip plugin api that could allow for these things to be transmitted.

I’m looking at the vision pro specifically because of the strong object permanence which appears better than any other device right now. You are right it will probably have to be it’s own app. I anticipate needing to modify the stream somewhat to better suite vr/ar needs especially since I will focus on just realtime visualization to start. That’s specifically what I would be looking to make a pull request around, adding maybe some stream setting options to accommodate.

I caveat all of this with I might be fully wrong how I do this and change my mind as I better learn and understand the back end and general mechanics of Crash.

I don’t think you should need to modify the Crash change packets that get submitted, they should offer everything you need. At least for a prototype. I haven’t yet added streaming endpoints to the server or the app yet but I do intend to. But as I said, it shouldn’t be an issue, crash communicates each change to keep the data sent low.

Here’s a little diagram of data flow, langs and issues I forsee

  • Green = Good stuff nice and easy
  • Blue = Cloud stuff
  • Red = Not readily available or possible afaik

2 Likes

Thank you, yes I have used that address with no luck. I have tried on Brave, Chrome, and Edge browsers.

What does that page look like on your screen?


It looks like this
Can you paste your terminal output / PM me with it if it’s sensitive?

Hello @CallumSykes,
unfortunately I’m not able to see the welcome page under http://localhost:8080 as well.
Same as @michaelvollrath reported I see “Welcome to Crash!” as browser tab title but an empty page below. And in the terminal it says Failed to determine the https port for redirect.
Were you guys able to find a solution for this problem yet?

On the terminal I get the same warning as Michael reported:

warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]
Failed to determine the https port for redirect.

1 Like

I’ll take a look at this next week and we’ll get this resolved, apologies for the issues :slight_smile:

1 Like

Hey sorry @CallumSykes I realized I never shared my terminal output but happy to do so if it helps,

Just PM me and I’ll send that! Thanks

1 Like

Awesome product! I was wondering if there are any plans to release support for blocks, layer and attribute data. I assume that layers and attribute data and potential groups could be solved in one go since they are all categories of attributes of rhino geometry.

Blocks seems like it could be more challenging since you have the block instance and the underlying block definition. Seems like this could be tricky if the block is linked. Ideally, any linked blocks would be migrated to the cloud as well, but then we are getting into DAM (Digital Asset Management)

I think this is what makes cloud-based software like Figma so powerful. Not only can you collaborate on a document but there is a way to share and manage assets across teams. That would require some sort of website with users and Auth. . . and some sort of SaaS to cover the costs of the server. . .

Are there any plans to commercialize this and turn this into a full fledged collaborative platform?

Hey @Benjamin_Paolo_Fortu,

Thanks for the interest!

I was wondering if there are any plans to release support for blocks, layer and attribute data

The goal is to slowly move towards 100% support for Rhino Objects, including custom.
I’ve already started with layers, attribute data etc and it’s going quite well. I’m coming up on some fun UX issues of course which is always a lark.

Blocks seems like it could be more challenging

Blocks and groups are … tricky … BUT not impossible. They’ll be something I’ll likely tackle later on. But with the way Crash is written anyone could do this :slight_smile:

That would require some sort of website with users and Auth. . . and some sort of SaaS to cover the costs of the server. .

I’m slowly working on such as user authentication, and ideally a website where you can see and manage models, users etc etc etc. I think ultimately I’d love for people to be able to have Rhino models cloud hosted and make them super easy to share and collaborate with.

Are there any plans to commercialize this and turn this into a full fledged collaborative platform?

:woman_shrugging: is my best answer to that

– cs

1 Like