Clustered rendering, real time game play using producer / consumer pattern.

[gedw99]

Describe the project you are working on

I would like to build an open render farm for Godoy 4.0 that can be used with movie maker mode and of course also real time gaming .

Is there an API that I can hook I to for this ?

the other aspect is the notion of an actor . Imagine you have a ball travelling from Point A to Point B. When doing clustered rendering you can do rendering in non sequential mode if an a tie is the owner of that ball.

The same networking patterns can then be used such that the producer and consumer pattern is used both to farm out the rendering but also to tell all those rendering nodes where the ball is and where it would be on all the other future frames given that nothing else effects that state of the ball.

The other thing we can do with this that is hopefully obvious is to use this same pattern for game actors.

I can do it in rust or golang . I prefer golang.

Malis I saw that c# is usable with Fodor via what Microsoft call a Source generator. Golang has a similar thing too where you can also generate code at compile time so it might be easy to also make golang both a way script Godoy and for a networked actor system.

Hope I have explained this reasonably well and I looking forward to feedback on these ideas.

Describe the problem or limitation you are having in your project

Speed of rendering and perf as actors system .

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This will allow tiles based network rendering where the state of the red ball is shared between the cluster.

map you can do 8k rendering in real time as well as massive online gaming play.

The architecture gets both done using the same inherent approach

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

It’s the producer consumer pattern

The network transport or bus can be unix domain socket for IPC.
For across the network we can use quic , web sockets and tcp.

We can btw also use the quic for server side real time clustered rendering. Like what Google Stadia attempted . They did not do tile based rendering though ( as far as I know ) but we can an so deliver 8k games over a video stream.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Not applicable …

Is there a reason why this should be core and not an add-on in the asset library?

Part of it will perhaps be in the core but that’s up for discussion perhaps.

[gedw99]

The docs relating to this seem to be here:

https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html

My proposal would provide the following additions:

• client side load balancing . This would ensure that no load balances are needed.

• https3 quic web transport protocol which is a UDP stream. This works in browsers, desktops, mobiles, tvs etc.

• global clusters. The client will always connect to the nearest server . Typically in each DC you have 3 servers as a minimum. We can have unlimited number of data centers with gateways between each data center . This results in a client always connecting to the nearest data center but the state of something is shared and mutable by any server using Basic CRDT over the actir based producer consumer system.

• the cider steaming for server side rendering uses the same protocol as used for the data networking. YouTube’s traffic is apparently about 80% quic based.

so by unifying on quic for data networking and video networking we simplify things and get the absolute performance and interoperability . Safari is the only browser without quic but it’s getting default status quite soon.

https://caniuse.com/?search=quic

https://caniuse.com/webtransport

https://ably.com/blog/can-webtransport-replace-websockets

https://thenewstack.io/how-to-get-started-with-http3/