BETA Release Network OGLAClient 091016

[Artlav]

Network OGLAClient alpha 091016:
orbides.1gb.ru/orbf/ogla_thinclient_091016.zip
Latest: http://orbides.1gb.ru/orbf/ogla_thinclient_091019.zip , info in post #12
Compatible with Orbiter beta 090729 and 091015.

What is it?
It is a set of 2 programs:
1. OGLAClient ( see http://www.orbiter-forum.com/showthread.php?t=10483 ) server, an Orbiter graphics client add-on that broadcasts Orbiter graphics client interface to the clients connected to it by TCP/IP.
2. Linux/Windows OGLA thin client - an graphics TCP/IP client to be connected to [1].

To run - Run Orbiter_ng, activate the OGLAClient_server module, run.
Then, run the client part with server as parameter. If server is not specified, localhost is used.
Client part accept parameters, --udp will receive the state vectors as UDP packets. For it to work, you should also set the server to send over UDP in visual settings configurator (button, right column, last checkbox).

What is it supposed to do?
[1] is a server part of OGLAClient, that can transmit the scene over network, to the clients that do the drawing.

For the moment it can show most of the scene - meshes are transmitted over the network, since there is no way to determine which is what, textures are loaded from the disk on client end.
Surface bases are not supported, some 2D stuff is sent over, but not drawn yet.

The input is accepted in the server's window, the clients can't send the input back to the server, for variety of reasons.

Why?
One scheme is to run Orbiter under WINE or some kind of VM, and let the platform-independent graphics part connect to it over the local network, thus allowing to run it with native performance. I guess it won't quite work.

Second scheme, one to be developed, is to have a server running on a big PC, while a bunch of thin clients on weak PC's will show the image and MFD's on multiple screens, like simpit.
With some work it would be able to transmit MFD's separately, or even run as graphics on main system, transferring MFD's to other place.

Third scheme - a server with a mission going on, and observers connecting the clients to watch the mission. With some optimization, the data rate will be way less than any streaming video of the same quality.

Any ideas are welcome
Consider it as open project - Linux, Windows, Network, OGLA engine.
What do you want to see being made out of these?
Also, does it even work, and why doesn't it work for you?

 

[Bj]

Looks like a good concept

Question: do the clients control the ships, or does the client just display the screen?

The input is accepted in the server's window, the clients can't send the input back to the server, for variety of reasons.

NVM

I think it would be cool if the clients were able to control the ship but then that might be too close to OMP wouldn't it?

 

[Artlav]

I think it would be cool if the clients were able to control the ship but then that might be too close to OMP wouldn't it?

Could be done, although tricky to.
Practically, if there are several clients, who's commands to prefer? The core can only handle one focused vessel at a time, so it will be a cramped pilot seat.

 

[TSPenguin]

Does it have a matchmaking service to verify stuff like planet specs, realism settings, and vessel specs?

No. It does not need to and it should not have it.
It is a mere rendering that is performed. If it had such a feature you'd need identical resources on all machines. This would be very unpractical.

 

[Bj]

Could be done, although tricky to.
Practically, if there are several clients, who's commands to prefer? The core can only handle one focused vessel at a time, so it will be a cramped pilot seat.

I didn't know that. What do you mean by handles? Couldn't the client computers connect to the server and simply 'act' on the vessel like Rcontrol does?

Oh and for the part of having multiple pilots on the same vessel, you could make it so that each vessel has 2 'seats'; pilot and co-pilot. Once the pilot seat is filled by a user, then only that user can control the vessel. Also the co-pilot can have functions over things like radio communications. When(if) the pilot wants to turn control over to the co-pilot, a switch or button can be pressed for the co-pilot to assume control over the vessel. Of course there can be other 'seats' for observers of the pilot/co-pilot and vessel.

 

[Artlav]

I didn't know that. What do you mean by handles? Couldn't the client computers connect to the server and simply 'act' on the vessel like Rcontrol does?

You could control a vessel, but nothing else will work - MFD's will aim at the main vessel, VC will not show right, all kinds of logic will break up.

 

[Zachstar]

I like the idea of "streaming" anyway. It seems FAR more effective than updating screen shots or trying to broadcast video live.

This sounds like solid gold for VSAs. Especially as one seems to be able to make their client render like the CGI views at mission control.

A question. This software seems to be a graphical engine using network data to "Render" an image correct? As such should it follow the same standards as the main engine?

For instance should GDI be used at all obviously you want it in the main client to render MFDs but it seems this has less of a need of traditional Orbiter MFDs and needs more OpenGL style rendered data graphics.

Such as advanced navigational tools not limited to a MFD window that render paths in textured 3D

Maybe I am taking this completely the wrong way but I saw this I at once thought "mission control"

 

[Artlav]

A question. This software seems to be a graphical engine using network data to "Render" an image correct? As such should it follow the same standards as the main engine?

For instance should GDI be used at all obviously you want it in the main client to render MFDs but it seems this has less of a need of traditional Orbiter MFDs and needs more OpenGL style rendered data graphics.

Not quite sure what the question is.
The thin client receives a stream of telemetry, in a sense. A set of state vectors for all objects, and the information about where the camera is, etc.
The MFD's are passed as a set of drawing calls, no images is being transfered. As such, nothing using GDI will ever be drawn.
The scene then is constructed and rendered on the client end.

 

[Zachstar]

Ok sorry to be confusing maybe you can describe how you will implement 2D rendering?

 

[n72.75]

Well this certially opens up worlds of new possablilties...

 

[Artlav]

A small update:
Network OGLAClient alpha 091019:
http://orbides.1gb.ru/orbf/ogla_thinclient_091019.zip
Compatible with Orbiter beta 090729, 091015 and 091017.

Changes:
-More stable connection
-5 times less state traffic
-5 times faster updates by default (10 upd/sec, so, same traffic)
-Partial input support

Now, mouse input over the network should somewhat work in this version, but Orbiter seems to want the mouse to be in it's window, so it may or may not work.

The data rate is much less, thanks to not sending every damn rock position in this version, about 1 kb/update. 10 upd/sec is the default.

Problems so far:
-Keyboard input passing to Orbiter window - it needs scancodes or something
-Mouse rotation
-Amount of 2D data to send over - drawing MFD's every time step (10000 FPS on the server!) won't work, getting them to draw at 10 times a second will make the server run at 10FPS or less, wrecking physics.
-UDP+NAT. An age-long issue.
-A way to load meshes locally - there are no names for meshes Orbiter sends to the client, so meshes have to be sent over the network.

Ideas are welcome.

For testing, there is an intermittent server at (There is no more). Should contain DG and Luna-OB1, views changing every now and then. If you try it, how well does it work over the internet, and what kind of link do you have? The sum of meshes is 1.7 Mb, so take care.

Ok sorry to be confusing maybe you can describe how you will implement 2D rendering?

2D rendering in OVP - a stream of commands (draw line, print string, blit onto this texture, use as MFD, etc). This will be transmitted over the network to the client. Best case scenario, there will be tags implemented by the core, allowing to distinguish MFD's from the rest. Panels are distinguishable now, but the traffic is somewhat too much for the moment.

 

[yagni01]

This looks like a really nice idea. I know one thing we've discussed in the flight deck forum is being able to choose different camera angles so each client could handle a specific "window". Rather than passing camera geometry from the server, would your method allow selection of different views on the client side at some point?

 

[Zachstar]

In my opinion why not free up space per update and just abandon Orbiter like MFDs in the client? Why not instead send Data from the API so that custom 2D stuff can be written?

MFDs in my opinion are traditionally more suited to pilot and co-pilot operations. This client in my opinion needs to have custom 2D stuff written to serve VSAs and remote operations.

 

[Hielor]

In my opinion why not free up space per update and just abandon Orbiter like MFDs in the client? Why not instead send Data from the API so that custom 2D stuff can be written?

MFDs in my opinion are traditionally more suited to pilot and co-pilot operations. This client in my opinion needs to have custom 2D stuff written to serve VSAs and remote operations.

What if you want one of your client views to be that of an MFD so you can put it on an external monitor?

 

[Zachstar]

If the API is sent the program can be intrusted to have that API available for other things to render in my opinion. And besides does OGLA already not have multi views?

 

[Artlav]

In my opinion why not free up space per update and just abandon Orbiter like MFDs in the client? Why not instead send Data from the API so that custom 2D stuff can be written?

There is Orb:connect, that does this, there are open-source MFD's, so that approach is already available.

Rather than passing camera geometry from the server, would your method allow selection of different views on the client side at some point?

Offset can be defined on the client's side, yes. The scene is what is being transmitted, so the client is free to put the camera whereever it wants.

 

[Zachstar]

If that is a case is it too much to request the ability to set the camera from another craft? So that VSAs can render views from tracking aircraft?

About the MFDs if that approach is already available that even further reduces the needs to transfer MFD data. Yes I see the uses but if its going to be a mess to control or nonstandard MFDs acting up. I think just having clientside MFDs would work better in my opinion.

 

[Artlav]

If that is a case is it too much to request the ability to set the camera from another craft? So that VSAs can render views from tracking aircraft?

You will be able to watch, but not control. Not for now, at least.

About the MFDs if that approach is already available that even further reduces the needs to transfer MFD data. Yes I see the uses but if its going to be a mess to control or nonstandard MFDs acting up. I think just having clientside MFDs would work better in my opinion.

Ok, then changing the focus.
Unless an easy way is found to transmit 2D commands, the scene itself is the main object now.

A program, aimed at viewing an Orbiter session in real-time, like someone does the flight, several clients connect to it, and get passenger seats views.
Or, a training scenario - a pilot flies, the students watch.

Consequently, the server is now merged with the actual graphics client, allowing you to play and transmit at once.

The clients will no longer have an ability to send input to the server (as if it worked anyway), but will have their own camera controls instead.

What about MFD's? I can put in an orbit MFD and some kind of statistics MFD, but anything more will be too much work. Where do they come from, where do you want them?

Also, following a talk at Orbiter IRC, it seems that at least someone took the phrase "thin client" literally, that is, a client that needs no Orbiter files.
That turned out to be an interesting idea, so now the client will transmit textures over the net if none are found.

That way, the client program is all you will need to view an Orbiter scene remotely.

So, how does this sound?

---------- Post added at 12:07 PM ---------- Previous post was at 11:58 AM ----------

And, a stray thought - what about Orbiter 2006? There aren't that much reasons the server part can't work with it, newer changes considered.
Waste of time?

 

[Zachstar]

Why not just send down basic info?

Solar system specs..
Data all standard Orbiter MFDs need to function
All in an "Client" Api so as to not be interpreted as standard Orbiter AI

Afterwards I guess just make it so an addon can pop up an OpenGL 2 window from the client and write stuff into it I guess.

Edit to your Edit: Waste of time in my opinion Orbiter 09 is in RC mode and after it is out there will be massive confusion if this supported both.

---------- Post added at 03:23 AM ---------- Previous post was at 03:15 AM ----------

I diddnt detail that last post correctly.

This client as you mentioned is more for rendering "Views" without sending video. As such its focus is different. MFDs are made to be controlled with a finger during active flight.

Clientside MFDs (Or data display systems) In my opinion serve more as displaying info and computing stuff to serve the pilot. This serves VSAs because you could in my opinion. "Build" a scene inside a building with each client having the ability to "use" the data from the master in different ways. Maybe one person is viewing a camera from the RMS on the shuttle? While another is watching another camera aimed at the earth while he refines a TI burn to send to the pilot. This stuff is "built" into a client addon seperate from orbiter.

 

[Artlav]

Why not just send down basic info?

Solar system specs..
Data all standard Orbiter MFDs need to function
All in an "Client" Api so as to not be interpreted as standard Orbiter AI

Afterwards I guess just make it so an addon can pop up an OpenGL 2 window from the client and write stuff into it I guess.

That's pretty much what is being sent - data on all objects and state vectors, along with the meshes&textures. It is, after all, a remote rendering add-on, not a remote API one.

Clientside MFDs (Or data display systems) In my opinion serve more as displaying info and computing stuff to serve the pilot. This serves VSAs because you could in my opinion. "Build" a scene inside a building with each client having the ability to "use" the data from the master in different ways. Maybe one person is viewing a camera from the RMS on the shuttle? While another is watching another camera aimed at the earth while he refines a TI burn to send to the pilot. This stuff is "built" into a client addon seperate from orbiter.

Getting more and more confusing...
Should it be a separate add-on, or some way to define MFD's in this one?