Recognized cameras and display modules

[sgallaty]

Here are my ideas

to be able to wire a camera to a display module and have that display module display what is on the camera. The text on the camera would remain as an overlay.

Each display unit to have two different text display fields, that it alternates between when sent an activate or deactivate signal, respectively.

the ability to rotate cameras and display modules around the axis interfacing the primary surface

That's about it =)

 

[Calbiri]

Not saying it wont happen, but each time you display another perspective on your screen (addition veiwpoints from various cameras) this is your computer rendering all the objects from that viewpoint on your screen, this can quickly compound how much you have to display. There's a huge risk of graphics lag in that.

 

[sgallaty]

Yeah I would expect there would be some LOD tuning going on to make it feasible, or the updates might only happen when it was in a viewport, they wouldn't be stacked (like, a camera can't look at a monitor and see anything but a scan line), and the update rate might be 15/s rather than full on

 

[Calbiri]

Im just imagining a player with a bank of 50 displays in one area...

 

[sgallaty]

... while angrily posting how this game sucks because it won't run smoothly on his midrange gaming system

 

[Snk]

Couldn't the game just save what the camera is showing, and paste it on the monitor? With a slight delay?

 

[sgallaty]

Well that's the thing right? The camera doesn't really 'show' anything until you are using it as a viewpoint.

To get the camera's view point is rendering an entire scene. Without any tricks, if your framerate was 60fps playing the game, with one 'monitor' on the screen you would get 30fps, since you're rendering two viewpoints... unless the game has portals for rendering, which I don't know that the engine supports. And this would be dynamic portals so there's no way.

So it's basically a 'frame' from your framerate every time a screen for a monitor is regenerated. There are tricks and ways around it, but that's the challenge.

 

[jayman38]

For one frame of display, the game will have to render a complete scene from the point of view of one camera.

It needs to save that render somewhere (RAM would be best - some players already have difficulty with RAM shortages, so it may end up on a swap file, resulting in a visit from our old friend, Mr. Lag).

Then it needs to project that render as a texture onto the display surface, plus whatever needs to be in place. (E.g. any overlays that the devs see fit, such as an artificial, low-res HUD.)

https://www.opengl.org/archives/resources/code/samples/mjktips/projtex/index.html

Multiply all that by however many cameras and displays that the player wants or that the game allows. That's a pretty large amount of image processing, even if you render the camera viewpoint to a low resolution image (E.g. 256 x 256). Not to mention network load if the image needs to go to the server for any reason. (You just know players will request an image feed broadcast for the whole faction or even the whole server!)

This suggests that the game needs a hard limit on the number of per-player camera displays allowed as well as the total number of camera displays allowed in the universe. It seems so limiting that it looks like a relatively useless feature at first blush when you look at the massive work/reward ratio.

Edit: Maybe the Camera rendering could have an extra-limited view, like strictly 60 degrees with a render distance hard limit, so that distant objects like planets and space stations would not be rendered by the camera at all. And maybe a hard-limit render resolution of 64x64.

 

[sgallaty]

No it's not really that simple. It's more like -
for every monitor in view the game would have to render down to the monitor's pixel rectangle. it's stored as a surface texture, with some arbitrary resolution that you scale.

there's a lot of trickery and arcana that can be done around this, i wouldn't really bother speculating too much about it. Graphics programming is one of the few remaining brutally challenging optimization demanding disciplines. No amount of cozy IDE and abstracted abstractions is going to help you find that trick saving a cycle by doing memory moves on specific boundaries that are a multiple of the lsb of a register. .. as an example.

 

[Brokennex]

I've been obsessing about this idea for the past week or so myself. For one thing, the reward isn't as low as you might think; it can really lend to defensive systems (particularly on massive ships) and to the immersion factor (with many other options, like large-scale broadcasts of a single display -- which could be similar to the sharing of player skins that's already done). As for speed, the camera views could be done asynchronously in a background thread and the display block's texture only changed to a rendered buffer once its camera's view has been rendered (which at worst might lead to slow updates of the display blocks). The RAM issue is still a bit problematic, but that's bound to be the case with a game that has a completely unpredictable scene complexity -- and there should be a setting to turn it off entirely for lower-end machines or servers that can't spare the extra work. I figure the performance should be decent on a decent computer as long as there's frustum culling and reduced view range (which would be hard to notice since the default textures only go up to 128x128). But with a resolution that low, I'd even consider a ray-tracer to render them; often slow, but it can be fast if there's a decent scene graph in place.

And the idea of a dynamic portal-based culling implementation has me thinking. However, the fact that entities are able to have completely different orientations from each other makes such a thing more complex (and probably slower). It would also need to recheck ships, stations, planets, and asteroids for changes to the portals every time they get modified.

 

[Dire Venom]

Edit: Maybe the Camera rendering could have an extra-limited view, like strictly 60 degrees with a render distance hard limit, so that distant objects like planets and space stations would not be rendered by the camera at all. And maybe a hard-limit render resolution of 64x64.

This could work, if the camera has to only render a very short distance the load should be greatly reduced (say only 50-100m)
While this would only really them useful for viewing interiors, damage etc it should theoretically allow many more cameras to operate at once