BDArmory
BDArmory copied to clipboard
PapaJoesSoup
RCS Analysis use camera
ISSUE TYPE
- Enhancement (Expand on existing features)
IDEA SUMMARY
- The RCS Analysis tool would use the camera in the VAB for the calculations and image when the UI is updated through an appropriately named "update" button.
Looking at line 306 onwards in RadarUtils.cs, it doesn't look too difficult (with my limited understanding) to implement, just adjust the camera rotation and position with the current camera position and rotation. But I don't know C# or this codebase that well. Let me know what you think.
It is not too difficult, yes, but relatively useless at the moment, as the RCS rendering in flight is NOT using real-time reflection angles, just the pre-computed "average number" for performance reasons.
Seeing realtime rcs from an arbitrary angle in the VAB would show you some number (e.g. 0.45 m^2) which has no effect on detectability in flight eventually.
No worries, I am planning to do a better in-flight rcs calculation one day, I just have to find a way to do it with minimal performance impact (KSP and BDAc with multiple active 100+ parts vessels already seems dog slow, so any bdac subsystem should at least not add to the burden...). I will come back to your suggestion then, so I leave this feature proposal open!
Here's a suggestion for in flight calculation:
Use the current m^2 model for calculating the cross-section like in the VAB but only calculate the area seen rather than calculating angle's and what-not. Won't be perfect but would be an improvement (hopefully) with (hopefully) minimal performance impact than the current model.
I have another suggestion that would have less negative effects on realism, but hopefully an acceptable performance impact: Keep the present method of calculation, but do not update the value for each radar in real time. Instead, redo the calculation once every few seconds. This should not be very detrimental to actual use of stealth in tactics because the stealth user is unlikely to alternate rapidly between a detectable attitude relative to the radar and an undetectable one.
If this approach results in excessively heavy bursts of computation every time the update needs to be made, the calculation method can be modified so that it can occur in a large number of individually small steps spread over the update interval, while keeping more or less the same algorithm. Would it be possible to move such calculations, which neither need to occur in real time nor in a way synchronized with the simulation, to a separate thread, perhaps even a lower-priority one?
As for deciding the length of the delay to balance between performance and update rate, it may be better to provide some reasonable default value, but let users change it through a slider in the options dialog. This will both allow users to adjust this value to fit the performance of their own computers and allow them to adjust it according to different principles than yours, for example to deliberately maximize realism at the cost of performance or to minimize performance impact when not doing anything in which exact RCS values matter.
