Couple of comments:
- Regarding orientations for emission points, there's not really a reason for that unless we're planning on having shots automatically do some amount of "firing forward out of the gun before bending to the target." Right now they come out of a point and then head toward their target in the fashion that is literally mimicking that of the underlying shot in sim code.
- THAT said, if you're talking about orientations because you'd want it to check and fire from specific guns depending on where the target is... that's actually pretty cool of an idea, really. Basically if there are guns on the front and guns on the sides and back, then it choose between them, sure. The orientation would still be really tough to do, though, because that's a lot more math and I'm worried about the CPU expense there.
-- Instead I'd rather go with which emission point is closest to the target, since assumedly that would be the one that is facing the target. For some of the big forward-facing guns in particular that would be wrong, though, so if there was a secondary offset I'd say it would be "for choosing-a-specific-firing-source" purposes, pretend I'm actually in this offset location from where I am now. That ought to handle all of the cases in the lowest-possible CPU usage way.
Fighter dogfight tangles (as I posted a few months back where I think you guys were talking about possible solutions) -- basically, allowing fighters and other small ships to visually "look" like they are not just sitting in front of eachother blasting away as if they were capital ships. (evasion-based ships should evade, no?)
This one is completely out of scope at this point, and I don't have any ideas on how to implement this in a way that won't grind the CPU to a halt. There's simply too many transforms that would have to change. I've thought about some ways to implement the movement on the GPU, but while doing the calculations as just vector math on a secondary thread on the CPU, but I can't think of a good way to handle the rotation transforms of vertices in HLSL shader code. There are some ways to do it, but I'm trying to stay away from compute shaders (which require newer hardware), and I'm not sure how efficient such code is in general.
I could see this being possible in a year or two, as hardware marches forward and the underlying unity engine adds further performance improvements in transform updates. As they continue to roll out their newer custom render pipeline scripting stuff, that will be one big help, too, because at some point I may rewrite the entire transform stack for ships to instead be all virtual and then just using arrays of offsets to their GPU instancing code, which is vastly simplified if the render pipeline scripting is under my control.
However, they haven't opened up the occlusion culling -- specific frustum culling -- fully yet in that part of their code, and the whole custom scriptable render pipeline stuff is still in an alpha state at the moment as a general concept, so I definitely wouldn't be building a real game on that just yet. But my understanding is that that's supposed to hit release-readiness sometime in 2018, and I'd guess further maturity in 2019, so a lot of new things would become possible once that's done. For my purposes, it should allow for vastly more throughput of ship movement calculations in the vis layer without any extra hardware requirements.
But until then, the tangling of dogfights is definitely Right Out at this point. I thought I'd be able to handle it, but the performance and flexibility just isn't there yet in the underlying engine stack. There's too much bloat unrelated to what I am doing, basically.
