Render cameras to LCD on clientside.
The concept is fairly simple, allow players to render a camera to a LCD.
This rendering should be done entirely through the client, the only sync with the server should be done in order to specify what camera block is being used, and what LCD it is outputted to.
Specifics (proposition):
each used camera should only be rendered and stored to the buffer once if it is within range. The quality of cameras should be configurable to the user (as so if the player has negative performance due to the feature, they can simply turn it off or lower the quality of the image.)
The quality of the camera's render should vary based off of a few factors- first, the user's set range in which cameras will be at full quality, second the user's general quality- and of course relating to the first factor, the distance to the LCD that is using a camera.
Because of this, the cameras should be rendered sequentially based on the LCD's distance to the player, the LCD should check if camera has already been rendered, if not it should render, and base the quality on the distance of the LCD to the player and the player's quality and radius settings.
The player should have the ability to also limit the number of cameras rendered per frame in their settings.
On top of this, to allow for more creative uses of programmable blocks in order to create HUD, it should be possible to draw on top of the rendered cameras using the same API we have for sprites (etc) currently.
Summary:
- player can configure number of the cameras rendered, the render quality, and the radius at which it is at maximum quality.
- server acts only to store what is to be rendered on the clientside, and has no performance drops.
- programmable blocks can draw
- cameras can draw to lcds.
The implementation of LCDs using cameras in this way would allow no performance problems for servers, and it'd allow the player to configure the cameras quality in order to prevent performance drops as they need. It will also open possibilities for creativity among engineers- allowing for players to create their own dedicated HUD and control systems for ships, and many other new designs. The possibilities are practically endless.
There is of course research to be done, however this should be a good general idea of how Camera to LCDs could be implemented.
I like this feedback
I would add that if player A sets up a camera to output to an LCD, then for each of the other players the LCD should display the name of the camera block (Add some text like "CCTV: Camera 2"). Then each player in turn has the option to turn the image on (/or off) for themselves.
Players could also have a personal setting in the main menu to activate them by default.
I would add that if player A sets up a camera to output to an LCD, then for each of the other players the LCD should display the name of the camera block (Add some text like "CCTV: Camera 2"). Then each player in turn has the option to turn the image on (/or off) for themselves.
Players could also have a personal setting in the main menu to activate them by default.
"Each used camera should only be rendered and stored to the buffer once if it is within range."
This has a stacking effect, and depending on the unclear range, it might not even have time to begin generation - which as it will be spontanous from multiple sources, a risk of a performance spike.
This distance is never mentioned again.
"The quality of cameras should be configurable to the user (as so if the player has negative performance due to the feature, they can simply turn it off or lower the quality of the image.) "
The quality of the render per this is now Dynamically changing, based on configuration and the next line, by distance, causing the camera to need to re-render the scene per quality change.
As that isn't a simple nob -- Nor is explained what is "Quality" in this context.
Each Camera is rendering the scene, based on an nearby LCD's distance to the player Connected to the Camera - so the system is raycasting to the LCDs?
Or are the LCDs raycasting to the Player after detecting what Camera is linked to them? As the LCD isn't rendering from itself, and your Quality is controlled by LCD distance.
Is it the longest or shortest LCD distance to the player? If its Shortest, every single LCD then is getting the highest quality from 1 LCD.
Which itself is an issue; They can't change the Render, they're all attached to the Same Rendering Camera, Unless you're rendering the scene with differences for every Level.
Digi mentioned the cuts you can make to what this Renderer accounts for, but you can not retroactively apply them - There is no cost benefit if you're always rendering to that level.
Player Radius Settings; Meters? From what? The Camera, the Rendering source? Or again to a displaying LCD that can kilometers from the Rendering camera?
Why is the Renderer source Quality determined by the LCD distance, when there is more LCDs than Cameras as well. The Camera is further than the LCD.
"The player should have the ability to also limit the number of cameras rendered per frame in their settings.
On top of this, to allow for more creative uses of programmable blocks in order to create HUD, it should be possible to draw on top of the rendered cameras using the same API we have for sprites (etc) currently. "
The Player limiting camera rendering per frame is sensible, however, You're missing an element here.
Number of LCDs attached to a Camera, If there are 20 LCDs flashing their new images straight from the Renderer, its a bit more expensive than if its 1 LCD.
With your System quality checks being determined by the LCD, and not the Distance from the actual render, the LCD is most commonly going to cause the highest cost Renderering.
In addition, You need the frame rate of these Rendering passes to be limited in general, in relative number to the volume of Cameras.
No mention of what happens after hitting the Frame limit -- despite being this stated as 'complete explaination' and optimization in detail.
This is misisng - what Camera has priority? Is there there an order? Is it random frame discards? Is it by distance? Distance from what?
How do you handle the Programmable Block Draw elements on top of the LCD output? Does it get applied on the render frames?
It is independent, and isn't affected by the frame rate of the renders? Is it frame locked?
These are important details missed in this "Complete detailed explaination"
"
player can configure number of the cameras rendered, the render quality, and the radius at which it is at maximum quality.
server acts only to store what is to be rendered on the clientside, and has no performance drops.
programmable blocks can draw
cameras can draw to lcds.
"
Radius from what? The LCD which isn't where the Camera is?
Render Quality translates to what? Never mentioned what is 'quality' in the short nor long form.
Is claiming has no performance drops, despite needing multiple renders - so that's a bold claim.
Programmable Blocks can draw, is vague. What level of API access or strings do you provide for this? Is it merely the ability to superimpose Text, graphics onto Images?
Is it limited to this Function, requiring a new LCD mod and Interface for acceptin PB inputs & outputs? This isn't mentioned either.
"The implementation of LCDs using cameras in this way would allow no performance problems for servers, and it'd allow the player to configure the cameras quality in order to prevent performance drops as they need. It will also open possibilities for creativity among engineers- allowing for players to create their own dedicated HUD and control systems for ships, and many other new designs. The possibilities are practically endless.
There is of course research to be done, however this should be a good general idea of how Camera to LCDs could be implemented."
The Clients have little control over the most performance intensive elements, with no clear ability to gague when the system triggers.
An LCD has no relation to any Camera Position, past hopefully being on the Same grid, as this isn't clear either - Nor an actual count of LCDs nor Cameras.
Clearly the belief is that the LCD image and not the Rendering to get the Image has been the focus in regards to "Quality"
However, rendering a Massive simulation and then downscaling said image to 48x48 pixels does not reduce the Rendering costs, so that Must be clarified.
Provide more details.
"Each used camera should only be rendered and stored to the buffer once if it is within range."
This has a stacking effect, and depending on the unclear range, it might not even have time to begin generation - which as it will be spontanous from multiple sources, a risk of a performance spike.
This distance is never mentioned again.
"The quality of cameras should be configurable to the user (as so if the player has negative performance due to the feature, they can simply turn it off or lower the quality of the image.) "
The quality of the render per this is now Dynamically changing, based on configuration and the next line, by distance, causing the camera to need to re-render the scene per quality change.
As that isn't a simple nob -- Nor is explained what is "Quality" in this context.
Each Camera is rendering the scene, based on an nearby LCD's distance to the player Connected to the Camera - so the system is raycasting to the LCDs?
Or are the LCDs raycasting to the Player after detecting what Camera is linked to them? As the LCD isn't rendering from itself, and your Quality is controlled by LCD distance.
Is it the longest or shortest LCD distance to the player? If its Shortest, every single LCD then is getting the highest quality from 1 LCD.
Which itself is an issue; They can't change the Render, they're all attached to the Same Rendering Camera, Unless you're rendering the scene with differences for every Level.
Digi mentioned the cuts you can make to what this Renderer accounts for, but you can not retroactively apply them - There is no cost benefit if you're always rendering to that level.
Player Radius Settings; Meters? From what? The Camera, the Rendering source? Or again to a displaying LCD that can kilometers from the Rendering camera?
Why is the Renderer source Quality determined by the LCD distance, when there is more LCDs than Cameras as well. The Camera is further than the LCD.
"The player should have the ability to also limit the number of cameras rendered per frame in their settings.
On top of this, to allow for more creative uses of programmable blocks in order to create HUD, it should be possible to draw on top of the rendered cameras using the same API we have for sprites (etc) currently. "
The Player limiting camera rendering per frame is sensible, however, You're missing an element here.
Number of LCDs attached to a Camera, If there are 20 LCDs flashing their new images straight from the Renderer, its a bit more expensive than if its 1 LCD.
With your System quality checks being determined by the LCD, and not the Distance from the actual render, the LCD is most commonly going to cause the highest cost Renderering.
In addition, You need the frame rate of these Rendering passes to be limited in general, in relative number to the volume of Cameras.
No mention of what happens after hitting the Frame limit -- despite being this stated as 'complete explaination' and optimization in detail.
This is misisng - what Camera has priority? Is there there an order? Is it random frame discards? Is it by distance? Distance from what?
How do you handle the Programmable Block Draw elements on top of the LCD output? Does it get applied on the render frames?
It is independent, and isn't affected by the frame rate of the renders? Is it frame locked?
These are important details missed in this "Complete detailed explaination"
"
player can configure number of the cameras rendered, the render quality, and the radius at which it is at maximum quality.
server acts only to store what is to be rendered on the clientside, and has no performance drops.
programmable blocks can draw
cameras can draw to lcds.
"
Radius from what? The LCD which isn't where the Camera is?
Render Quality translates to what? Never mentioned what is 'quality' in the short nor long form.
Is claiming has no performance drops, despite needing multiple renders - so that's a bold claim.
Programmable Blocks can draw, is vague. What level of API access or strings do you provide for this? Is it merely the ability to superimpose Text, graphics onto Images?
Is it limited to this Function, requiring a new LCD mod and Interface for acceptin PB inputs & outputs? This isn't mentioned either.
"The implementation of LCDs using cameras in this way would allow no performance problems for servers, and it'd allow the player to configure the cameras quality in order to prevent performance drops as they need. It will also open possibilities for creativity among engineers- allowing for players to create their own dedicated HUD and control systems for ships, and many other new designs. The possibilities are practically endless.
There is of course research to be done, however this should be a good general idea of how Camera to LCDs could be implemented."
The Clients have little control over the most performance intensive elements, with no clear ability to gague when the system triggers.
An LCD has no relation to any Camera Position, past hopefully being on the Same grid, as this isn't clear either - Nor an actual count of LCDs nor Cameras.
Clearly the belief is that the LCD image and not the Rendering to get the Image has been the focus in regards to "Quality"
However, rendering a Massive simulation and then downscaling said image to 48x48 pixels does not reduce the Rendering costs, so that Must be clarified.
Provide more details.
Replies have been locked on this page!