Ramses – A distributed system for rendering 3D content | Hacker News Reader

Ramses – A distributed system for rendering 3D content

github.com

136 pointsdesdiv25 comments

I dont see a demo on their github page. Anyone find any?

Nothing here: https://www.youtube.com/results?search_query=bmw+ramses

https://at.projects.genivi.org/wiki/display/DIRO/RAMSES

I couldn't find anything either. A distributed 3d rendering system isn't very useful if it doesn't produce nice looking pictures. They should really add some sample renderings to the their wiki.

I think it's more distributed in terms of heterogeneous systems displaying data/UIs on heterogeneous displays. Not making a fast rendering system.

Golem Project has dozens of engineers working on distributed computing and have rendering capability today. GitHub: https://github.com/golemfactory and website is https://golem.network/

I do not mean to be harsh, but this sounds exactly like an ad for golem which, IMHO, is not the right place nor time for.

You're right--I could have made my point differently. I just pulled up the Ramses Github and didn't see much activity whereas I knew of a different repository with thousands of lines of working code.

Thanks, BMW! From the docs:

    # Example


    In a very simplified example, a client instance (e.g. the Navigation process) will create a 3D scene and "publish" it within the connected RAMSES applications (e.g. the renderer of each HMI).


    These renderers will "subscribe" to the published scene and show it on the screen.

So not just for the giant grids you see at CES. But also applicable to thin clients, LAN party play, art gallery installations, etc.

My suspicion, particularly with that example, is that this is something they use in their cars to present various interfaces.

Any guess as to what type of network layer they use there?

I thought cables are short enough in a car that they can attached the displays directly to rendering hardware. Are there other advantages? Provide a fallback in case one render process fails?

Not really, but car manufacturers have actively used network based electronics for easily twenty years or more. (In the early 2000's, I did some work on CAN interfaces for PC's that were often used to connect them to car hardware.)

The network simplifies the wiring and reduces the amount of wire used. Material cost reductions across the life of the car (from design to use).

At one point BMW were very into their fibre networks in-car, but I think they moved away from that for reliability. EDIT: here it is. https://en.m.wikipedia.org/wiki/MOST_Bus

# Example

In a very simplified example, a client instance (e.g. the Navigation process) will create a 3D scene and "publish" it within the connected RAMSES applications (e.g. the renderer of each HMI).

These renderers will "subscribe" to the published scene and show it on the screen.

Slightly off topic, I remember another distributed UI system that was posted to HN or mentioned in the comments not that long ago. I think it supported normal 2d widgets and maybe 3d as well. It was nothing web/js based but had native clients. Anyone remember this? I tried searching for it to no avail.

I am fascinated by such systems. In the best case you get screen/tmux re-attachment features for GUIs, down to the application level, not desktop level (x11/xpra does some of this). And you do not just stream pixels across a network (like x11) but have at least some of the render logic locally. If you can then use local graphics hardware that seems like an unbeatable combination.

Maybe some websockets/webgl/webassemly which does all that will become the de-facto platform agnostic GUI platform in the future.

was it vvvv?

https://vvvv.org/

https://vvvv.org/propaganda

No, I think it was not windows only, and not as "fancy" or versatile, just something like gtk or Qt with built-in networking.

But this looks neat as well, I did not know that one nor found it during my search.

GTK3 has had an HTML5 rendering backend for a while now, but it does fall under the "streaming pixels" category: https://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/

I made a message queue based thing several years ago. https://github.com/th0ma5w/live-jython-processing if you have a repl then hooking it up to a queue is trivial. You could probably whip something up for Clojure for instance in a couple of hours.

VirtualGL, maybe? https://virtualgl.org/About/Introduction

Off-topic: At that point do we run out of software names? At least "Ramses" is an acronym for something reasonable, it feels like a lot of them intentionally make no sense.

They just get recycled. I've worked on projects with the same code name at different companies.

By the way, if your company is in desperate financial difficulty, circling the drain with increasing speed, and the management cobbles up a "save the company" project and they name it "Falcon" it is WELL past time to polish your resume and bug out. I've seen that code name several times, and it's spelled utter doom (two bankruptcies and one buyout that was worse than going bankrupt).

In my head the conversation goes something like this:

----

[Int. meeting of High Management]

MARKETING HONCHO: "This is it. We're going to save the company with this new product. We're calling it Project Phoenix. Rise from the ashes! When can engineering start?"

ENGINEERING DIRECTOR: "Uh, don't Phoenixes burn themselves to death? Isn't that kind of a negative thing? The teams are a little burned out from the last save-the-company death march."

"You have a point. Let's call it something like . . . Fee-- no, um, Fun--, no . . . um, Falcon. That's it. Project Falcon."

"I guess that's better."

"Go save the company."

"Right. I'll just pop down to engineering and cancel all the vacations. When can you tell us about the product?"

"Later, when we decide what color it should be."

----

I have insufficient data, so it's possible that any project named after a large bird is bad juju. Stay safe :-)

I have a pet theory that as an organization increases in size, the probability that it will develop a tool named Fusion approaches unity.

PayPal and U.S. Bank have internal tools named Fusion. (I want to say that Cisco Systems does too, but I can't remember for certain.) Oracle, VMWare, and Autodesk all have products named Fusion (Fusion Applications, VMWare Fusion, and Fusion 360, respectively). IBM has two products named Fusion (Fusion Commerce and FusionAnalytics). Google used (naturally) to have a product named Fusion Tables.

What did I miss?

The first time I have seen any code from the trillion dollar automobile sector make it into the Open Source world, not that I go looking. What else could there be?

Let's try General Motors:

https://github.com/GeneralMotors

Yep, that is empty.

Actually this is General Motors too:

"The GENIVI Alliance is a non-profit automotive industry alliance committed to driving the broad adoption of open source, In-Vehicle Infotainment (IVI) software and providing open technology for the connected car. The GENIVI Alliance was founded on March 2, 2009 by BMW Group, Delphi, GM, Intel, Magneti-Marelli, PSA Peugeot Citroen, Visteon, and Wind River Systems"

https://github.com/cruise-automation/webviz (GM Cruise LLC)

I'm looking forward to seeing more of the technology working in the AV space get opened.

https://developer.ford.com/

Reply on news.ycombinator.com