BETA Release Network OGLAClient 091016

[Zachstar]

Sorry about the confusing. I do hope I can relay my thoughts more clearly in the future.

When I say addon I mean user created content to YOUR software not Orbiter itself your addon does not need to create anything except maybe a simple example display window mimmicing Orbit MFD done with OpenGL instead of GDI.

Please bear with me Artlav. I am not the best at relaying my thoughts in this case.

Lets say for the sake of argument Random VSA's Admin asks a developer in the org to make an addon for the clients to make a control room sort of like mission control houston.

Developer creates mesh of mission control room interior with consoles that have faces defined to display info.

Developer uses API to generate a "Face" for the screens that uses Open GL to Display such things as Orbit, track, and text data. On the wall a display shows results from a camera defined on the spacecraft in orbit to simulate a video feed from the shuttle.

Make any better sense?

 

[Artlav]

Lets say for the sake of argument
...
Make any better sense?

Yes, that makes sense, and pretty much describes what OUIPC or Orb:Connect can do, plus a way to transmit a render feed. Like, a lib you include into your program that gives you remote Orbiter API and a way to render a scene from a given point into OGL surface, give or take a feature?
I just didn't expected the scale of what you're proposing.

Might be a good idea, but it's not the time yet. The Orbiter 2009 should be released first, and someone should want this before i'll do it.

 

[Zachstar]

The issue with that is it requires two different feeds. One from your client and one from Orb:connect that could cause issues in my opinion. Would adding some API calls (Just enough to make an Orbit MFD clientside) directly into your feed be too much to ask for now.

I understand my idea is big and grand in nature and will likely require some changes in the render client. perhaps a middle ground for now is just for someone to be able to render basic info clientside?

Again let me detail this just to make sure I get my thoughts clearer. Can your client create an area on screen that stuff like an MFD be "drawn" into regardless of camera position? perhaps a window that can be dragged around and resized?

 

[Artlav]

Would adding some API calls (Just enough to make an Orbit MFD clientside) directly into your feed be too much to ask for now.

Many API calls won't need an entire feed to work - the data needed to draw the scene is already mostly enough to do an orbit MFD, you just need to add mass and maybe a few other minor things, and that's it.

Again let me detail this just to make sure I get my thoughts clearer. Can your client create an area on screen that stuff like an MFD be "drawn" into regardless of camera position? perhaps a window that can be dragged around and resized?

Can is not the question. What kind do you want is. It was supposed to render 2D commands into pretty much any surface, scene or screen. I can even add the nice windows, a-la OSH.
The problem is, it needs a system and some thought to become a useful thing instead of a mish of features.

 

[Zachstar]

Its hard to describe what could be useful to a VSA. Perhaps a simple view client for now and perhaps you could work with a VSA to define useful features in better detail later?

For now perhaps it would be better to focus on scene rather that 2D like you said for now that stuff can be done with Orb connect. Its a kludge in my opinion but it is FAR FAR better than what they have now.

A little side request tho. If possible can you draw a render from one camera onto a face viewed by the main camera? To describe this I am thinking the main screen at Houston space center where they show downlink video from the space shuttle RMS camera.

 

[Artlav]

Ok, status update:
Network OGLAClient alpha 091020:
http://orbides.1gb.ru/orbf/ogla_thinclient_091020.zip
Compatible with Orbiter beta 090729, 091015 and 091017.

Note, that the module to activate is OGLAClient, not OGLAClient_server now.

Changes:
*Server merged with rendering, you can play and transmit
*Transmission of vessel textures, if absent. A real Thin client!
*No texture turned weird bug fixed
*Internal MFD interface
*Internal Orbit MFD
*Camera render plane
*No more input

Following the discussion, a release showing the framework asked for - more data in the stream, a basic API, enough to have an Orbit MFD running, a camera to screen rendering (F7-1 to disable).

MFD target is selected with 0-9 keys.

Haven't thought up a way to describe camera positioning for the moment, coming soon.

 

[Face]

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?

It sounds great! This way you won't only have zero requirements, but you can show vessels on the server without worring about the appropriate stuff installed on clients, too. I.e. if the server does a firefly run, the client will see it, too, despite the appropriate addon not being installed locally.
So the best way to use it would be to have it installed in a clean Orbiter copy with e.g. OS, UMMU, high-res textures. This way you have low initial traffic, but great flexibility in server-side configuration.

The only downside: there could be licensing issues. I'm not sure if law is clear enough for temporary, partly distributed addons (but I more and more get the feeling, that with current laws, you can never be sure) ...

regards,
Face

 

[yagni01]

I have to wait for the weekend to try this, but I was wondering what the frame rate hit is on the game side. For RemoteMFD, we're limiting the data subscriptions to minimize the impact.

 

[Artlav]

I have to wait for the weekend to try this, but I was wondering what the frame rate hit is on the game side. For RemoteMFD, we're limiting the data subscriptions to minimize the impact.

For the moment it's quite high - 10 FPS solid, but i'm working on it. The server is in a separate thread, with proper synchronization it shouldn't take too much FPS off.

The only downside: there could be licensing issues. I'm not sure if law is clear enough for temporary, partly distributed addons (but I more and more get the feeling, that with current laws, you can never be sure) ...

Um... What? Of all places, how can the licensing issues appear here? Whatever add-ons are being run is freely downloadable, for no cost or non-disclosure, etc.

 

[Face]

Um... What? Of all places, how can the licensing issues appear here? Whatever add-ons are being run is freely downloadable, for no cost or non-disclosure, etc.

Redistribution. E.g. Dan Steph (again sorry for bringing you up as negative example, Dan) is very restrictive concerning redistribution of his addons. Don't get me wrong, I understand that it is far from being LOGICAL to see licensing issues here, but law is not always logical. And human emotion isn't either, for sure...

Having freely downloadable software doesn't mean you can distribute it whichever way you want. As I said, I'm not sure how this can affect temporarly (and only partly) done distribution. I just wanted to bring it up, as I frequently see this discussion emerging when discussing OMP (and COI, on more current occasions).

regards,
Face

 

[Artlav]

A quick fix:
Network OGLAClient alpha 091020-1:
http://orbides.1gb.ru/orbf/ogla_thinclient_091020_1.zip
Compatible with Orbiter beta 090729, 091015 and 091017.

Note, that the module to activate is OGLAClient, not OGLAClient_server now.

Changes:
*Fixed textures issue
*Improved framerate (theoretically)

but law is not always logical.

Must be tough to live out there, with laws being both mandatory and not logical.

Seriously, let's hope there will be no legal problems.

 

[TSPenguin]

Seriously, let's hope there will be no legal problems.

Wouldn't any legal issues be the one of the individual running the server?! You are simply providing technology.

 

[Zatnikitelman]

Here's my take on this: though I haven't had much time to investigate how Network OGLA works, it seems that what Artlav is working on isn't a redistribution so much as a viewer. Though transmission of semi-tangible files is different than TV, it also seems that this particular implementation is very similar. The production companies would take issue with you recording what's on your TV then selling it, but they don't take issue with you simply viewing it (personal-use recoding aside). The show is still coming into your TV, but is it actually "on" your TV. Unless someone hacks Artlav's system, I don't really see a way of grabbing the data coming over the link and having that vessel "distributed." Please, correct me if I'm wrong on the implementation of this.

 

[Artlav]

I don't really see a way of grabbing the data coming over the link and having that vessel "distributed." Please, correct me if I'm wrong on the implementation of this.

Just take it out of the cache? Well, the DLL's are not transmitted, so it will be worthless mesh&textures slag anyway.

Wouldn't any legal issues be the one of the individual running the server?! You are simply providing technology.

He said the laws were not logical, so no prediction possible.

 

[Zachstar]

Actually thinking about it Face does have a point. You are sending copyrighted work (Unless it is implicitly stated as open)

To be honest perhaps it would be best to just implement the tech in a way to load meshes clientside and just have it so if they unzip the addon into the network client folder it knows what to read.

You have a great idea going thin client like that but here in the US and in other nations copyright is king and its not worth the potential for trouble.

 

[Face]

Here's my take on this: though I haven't had much time to investigate how Network OGLA works, it seems that what Artlav is working on isn't a redistribution so much as a viewer. Though transmission of semi-tangible files is different than TV, it also seems that this particular implementation is very similar. The production companies would take issue with you recording what's on your TV then selling it, but they don't take issue with you simply viewing it (personal-use recoding aside).

Good analogy. I think you can argue this way in court. And so the "broadcasting" party would be held responsible for any legal issues, just as every pirate station illegally broadcasting copyrighted material (if ever caught )...

regards,
Face

 

[Artlav]

You are sending copyrighted work
...
in the US and in other nations copyright is king and its not worth the potential for trouble.

...So, you're serious about this legal things?

To be honest perhaps it would be best to just implement the tech in a way to load meshes clientside and just have it so if they unzip the addon into the network client folder it knows what to read.

No problem for textures, and is working now, but a problem for meshes - Orbiter core does not preserve mesh names. Making hashes for existing meshes vs what is on the server might be tricky at best.

 

[Zachstar]

Artlav I watched a topic a few years ago where a person running a server to let people upload their blender works to share with others get sued because ONE person decided to be an idiot and upload copyrighted meshes.

And the "hurt feelings" issue in the community has been known to cause massive damage as well the "Who had permission to use what?" issue has destroyed entire lineups of addons.

Not worth the potential in my view. And based on what you are writing about preserving mesh names it sounds far easier to load from the client.

Also this would allow the client to load custom meshes. Perhaps lower res ones that work better on lower end machines?

 

[Face]

Actually thinking about it Face does have a point. You are sending copyrighted work (Unless it is implicitly stated as open)

To be honest perhaps it would be best to just implement the tech in a way to load meshes clientside and just have it so if they unzip the addon into the network client folder it knows what to read.

You have a great idea going thin client like that but here in the US and in other nations copyright is king and its not worth the potential for trouble.

Err... I wouldn't go that road. Dropping good technology just because it might cause trouble is not really a wise decision.

I think the thin-client approach has great potential to really revolutionize the VSA and/or mission-control business. I wouldn't want to see it dropped just for fear of law suites.

I brought that up to perhaps get Artlav into thinking about it a bit further, nothing more.

And I honestly can't see a real danger here. A bit forward thinking could avoid bad feelings among developers, though, a simple note perhaps...

regards,
Face

 

[Zachstar]

Artlav perhaps you can have the client interface with the way Orbiter loads to "Tell" what is loaded?