"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.
