Recognized cameras and display modules

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.

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

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

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.

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.

jayman38 said:

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.

Click to expand...

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