foof
New Member
Posts: 31
|
Post by foof on Oct 14, 2016 22:44:37 GMT
Not that I'm trying to beat anyone over the head with my credentials or anything. :3 Never would have taken your passion for science as showing-off. By the way I already read your post(s) and it send me down the rabbit hole of multi-agents systems
|
|
|
Post by nivik on Oct 18, 2016 15:46:45 GMT
Not that I'm trying to beat anyone over the head with my credentials or anything. :3 Never would have taken your passion for science as showing-off. By the way I already read your post(s) and it send me down the rabbit hole of multi-agents systems Hell of a rabbit hole! Glad to inspire an interest!
|
|
|
Post by geraldmonroe on Oct 24, 2016 4:54:52 GMT
In order to accurately calculate their time-to-impact, missiles need to consider their position, their current velocity, how their velocity is changing due to their acceleration, and how their acceleration is changing due to the missile becoming lighter as it burns propellant. So any accurate guidance algorithm is a third-order polynomial equation; anything else will drastically overestimate their time-to-impact, which will result in the missile overshooting the target for most of its flight, then making a hard turn at the end to try to correct its error. Finding the roots to a cubic equation is a pain in the butt: you can see the cubic formula here. Similarly, this paper shows that the EPN algorithm involves cubic equations, and the optimal guidance law uses at least one exponential function. Solving these is computationally expensive, unfortunately, which is the root cause of the slowdown problem qswitched mentioned. One possible solution is very similar to yours, though, except that a "leader missile" solves the equation once, and the other missiles mirror what it does, because the flight profiles of the missiles are very similar to one another, so the errors introduced by copycatting are much lower. Nivik, I'm not seeing the problem. Do you know of a good digital whiteboard where we can draw this out? You can easily see what's happening in 2d, and since the 3rd dimension is an independent axis from the other 2, the same solution does work. TLDR, imagine an arrow that is headed towards an apple. It is already going to hit the apple - the curvature due to gravity has already been accounted for. The arrow is not accelerating under any forces but gravity, and the archer already solved the equations for the arrow perfectly. When we solved the equation we already generated a time to intercept. Now add a new variable. The apple is on a spring loaded device that instantly accelerates the apple upwards at 10 m/s. Yes, the apple is also now decelerating downward but that doesn't matter either. It was headed right for the target, now we need to add a correction. We instantly fire rocket motors on the arrow and it is now headed upwards at 10 m/s. (and decelerating just like it was before) Arrow will bullseye the apple, which you can see if you graph this out. Now, what if we can't accelerate upwards instantly? What if we need to move a gimbal first and then begin to accelerate over time at a constant rate of acceleration? Well, in that case, all we need to do is add some extra velocity to "catch up" to where the apple was vertically. If the apple has moved 1 extra meter in 1 second it takes to do all this, and we have 10 seconds remaining in our flight, then we need to add 10 cm/second more to the 10m/s we add to the arrow. Technically if the apple reaches the top of it's arc there's another wrinkle added, and technically there may be 2 intercepts to this problem as a result. However, in open space in a space battle, or in a high orbit, this basic algorithm will work fine. Also, note that if during that 1 second where our arrow needs to reposition it's gimbal to match what the apple did, the arrow flies by the apple, then the arrow will miss. So last second "dodges" are still possible. Also note that if you fire a missile at a ship that is under thrust and you assume the acceleration is constant for your intercept solution, all the ship has to do is turn off it's engine to successfully evade your missile. Since torch drives are not possible in CoDE, that's why it's a safer bet to assume no engine acceleration for calculating an intercept. Here's empirical proof that I am correct : www.youtube.com/watch?v=RXQd0GgURN4You mentioned more wrinkles like constantly accelerating missiles - I don't think that makes doctrinal sense. What makes sense is for the missile to leave the launching ship and then burn until it's on an intercept course. It may then be programmed to random walk evade to dodge kinetic anti-missile fire, but each random walk is always paired with another thruster burn that will put the missile back on the original course it was following, eventually. It makes sense for the missile to hold on to any remaining propellant other than that used for evasion, since it increases the kinetic energy of the missile at impact and also gives the missile the capability to match last minute evasive maneuvers by it's target.
|
|
|
Post by nivik on Oct 24, 2016 18:29:08 GMT
Nivik, I'm not seeing the problem. Do you know of a good digital whiteboard where we can draw this out? You can easily see what's happening in 2d, and since the 3rd dimension is an independent axis from the other 2, the same solution does work. I agree. A 2D case is a good case study for understanding what will happen in 3D space. I don't know of such a whiteboard off the top of my head.TLDR, imagine an arrow that is headed towards an apple. It is already going to hit the apple - the curvature due to gravity has already been accounted for. The arrow is not accelerating under any forces but gravity, and the archer already solved the equations for the arrow perfectly. When we solved the equation we already generated a time to intercept. This is a case of constant acceleration, understood. In this case, the time to intercept would be found via the quadratic equation.Now add a new variable. The apple is on a spring loaded device that instantly accelerates the apple upwards at 10 m/s. Yes, the apple is also now decelerating downward but that doesn't matter either. It was headed right for the target, now we need to add a correction. We instantly fire rocket motors on the arrow and it is now headed upwards at 10 m/s. (and decelerating just like it was before) Arrow will bullseye the apple, which you can see if you graph this out. The apple's momentary change in acceleration is a jerk. Notice how we needed to recalculate and correct: the original solution was invalidated. If we had known ahead of time that the jerk was going to occur, no recalculation would have been necessary: we could have solved for it in our initial calculation and the additional rocket boost to adjust the arrow's course would not have been necessary. Our flight path and fuel consumption would have been more optimal.Now, what if we can't accelerate upwards instantly? What if we need to move a gimbal first and then begin to accelerate over time at a constant rate of acceleration? Well, in that case, all we need to do is add some extra velocity to "catch up" to where the apple was vertically. If the apple has moved 1 extra meter in 1 second it takes to do all this, and we have 10 seconds remaining in our flight, then we need to add 10 cm/second more to the 10m/s we add to the arrow. Technically if the apple reaches the top of it's arc there's another wrinkle added, and technically there may be 2 intercepts to this problem as a result. However, in open space in a space battle, or in a high orbit, this basic algorithm will work fine. This is control theory and engineering. The way I usually handle this is by finding the desired acceleration vector, normalizing it, and adjusting the missile's course to begin reducing the calculated miss/error. A PID controller is useful in this application: you make an adjustment proportional to the error, taking into account the sum of the error over time and the change in error between iterations through the sense/act loop. KSP uses a PID controller in its SAS, for example, and it results in smooth control deflections which bring the system back to the desired state with a minimum of oscillation (if tuned correctly.)Also, note that if during that 1 second where our arrow needs to reposition it's gimbal to match what the apple did, the arrow flies by the apple, then the arrow will miss. So last second "dodges" are still possible. Also note that if you fire a missile at a ship that is under thrust and you assume the acceleration is constant for your intercept solution, all the ship has to do is turn off it's engine to successfully evade your missile. Since torch drives are not possible in CoDE, that's why it's a safer bet to assume no engine acceleration for calculating an intercept. I'm afraid I don't understand your point here. Changes in target behavior will always require an update to the targeting solution or model. However, ignoring known information about the problem space doesn't improve the odds of a hit. Your targeting solution at time tto_impact (tti) predicts that the target will be at a specific location (pintercept) when tti = 0, and aims the missile towards that location. As the missile gets closer and the predicted pintercept gets more accurate, the missile will have to adjust its trajectory to ensure it reaches pintercept at tti = 0. Since the missile has already committed delta-v to its original estimate, it has to spend additional delta-v to correct for that error.Here's empirical proof that I am correct : www.youtube.com/watch?v=RXQd0GgURN4This is proof that you can hit a target by aiming directly at it provided that the projectile and target have a relative acceleration of zero, and the target has an has zero velocity relative to the projectile's start point. I don't think it's applicable to situations where target and launcher have non-zero relative velocity, and where target and projectile have non-zero relative acceleration.You mentioned more wrinkles like constantly accelerating missiles - I don't think that makes doctrinal sense. What makes sense is for the missile to leave the launching ship and then burn until it's on an intercept course. It may then be programmed to random walk evade to dodge kinetic anti-missile fire, but each random walk is always paired with another thruster burn that will put the missile back on the original course it was following, eventually. It makes sense for the missile to hold on to any remaining propellant other than that used for evasion, since it increases the kinetic energy of the missile at impact and also gives the missile the capability to match last minute evasive maneuvers by it's target. One of the main advantages of missiles is that they can maneuver to refine their targeting solution over time, in response to changes in the target's behavior. Ignoring this advantage makes their behavior no different from that of a ballistic weapon, except that acceleration is gradual and occurs after the weapon's been fired instead of occurring in the barrel of the weapon.
Matching maneuvers by the target and projecting how those maneuvers will alter the intercept point is what guidance algorithms are all about. That's the problem we're discussing, one that's been well-researched. That research indicates that the better your initial and incremental predictions, the better the performance of your missile. In particular, here is a comparison between algorithms that assume constant velocity (PN), constant acceleration (APN) and constant jerk (EPN):
Note that both delta-v and missile acceleration levels required to produce a successful intercept are drastically reduced by consideration of acceleration, and see a marginal improvement with consideration of jerk (change in acceleration). The source paper is Modern Homing Missile Guidance Theory and Techniques (Palumbo, Blauwkamp, Lloyd 2010).
Maximizing impact energy is a complex relationship, as kinetic energy is directly proportional to the mass of the objectand directly proportional to the square of the velocity of the object. Final velocity is proportional to the ratio between the initial and final mass of the weapon. So the impact force of the weapon can be expressed as:
KE = 0.5 * mf * (ve*ln(m0/mf))2
So, assuming we have a 50kg missile that's 100% propellant, we can graph the kinetic energy of the projectile given that x kg of propellant has been burned using the following equation:
...where the final impact mass is expressed as (50-x)kg. That equation gives the following curve:
...which indicates that, in this particular case, 86.5% of the missile's mass should have been burned-off propellant in order to maximize the resulting impact energy, with only 13.5% of the original mass remaining as the kinetic impactor. This is a mass fraction of about 7.38, This implies to me that KKVs should be designed with the optimal fuel mass fraction, and that doctrine should emphasize maximizing fuel burnoff before impact.I -- respectfully -- disagree with your assertions. Reasoning can be found point-by-point above.
|
|
|
Post by captinjoehenry on Oct 24, 2016 18:50:39 GMT
That said, my primary observation is that missiles currently appear to either use naive pursuit or simple proportional navigation, which are not the most robust algorithms out there. There are better alternatives. This video shows great examples of a variety of navigation algorithms and how incredibly important a good algorithm is. More information for the technically minded can be gleaned from this (math-heavy) paper. And here's an example of a higher-order algorithm being used in From the Depths against a very (notoriously) erratic target, with the source code included in the video description. I have actually implemented several better missile guidance algorithms than the one you see in game. None of them are enabled in game for one reason, and that is performance. 100+ missiles running a root finding algorithm for an intercept course will bring the game to a crawl. The current algorithm is naive, does not use numerical integration at all, and it still is somewhat of a performance problem (on my machine) with 100+ missiles. I'm still looking into better algorithms that don't kill performance (such as possibly trying to treat a fleet of missiles as "one big missile" to save on calculation time), and I hope to have something better by the next major patch. Just a thought. As a short term solution that can be implemented right now can we have the missiles just negate lateral velocity before they begin guidance. Now this isn't a perfect solution by any stretch of the imagination but as a short term fix till better algorithms can be implemented it would help quite a lot.
|
|
|
Post by ross128 on Oct 24, 2016 19:17:02 GMT
One thing that I think would help is to take advantage of some of the properties of our targets to constrain the possibility space.
A few things are generally true of most capital ships:
1: They tend to have less than 1g of acceleration.
2: They tend to be fairly long relative to their ability to accelerate.
3: They tend to only be capable of accelerating in one direction (and if they do have RCS, it's usually weak compared to the main engines).
4: They generally accelerate along their long axis.
Now, granted, baking these assumptions into our guidance to save performance would mean that someone could deliberately build a ship to break them (saucers break #2 by being circular, sidewall ships break #4 by accelerating along their short axis). But generally speaking, most warships have properties that make them fairly predictable targets. If you can determine where the engine is and aim ahead of it, you can then tolerate quite a bit of error in your guidance simply because the target is constrained to mostly moving forward at a low acceleration.
|
|
|
Post by geraldmonroe on Oct 24, 2016 21:29:18 GMT
This is proof that you can hit a target by aiming directly at it provided that the projectile and target have a relative acceleration of zero, and the target has an has zero velocity relative to the projectile's start point. I don't think it's applicable to situations where target and launcher have non-zero relative velocity, and where target and projectile have non-zero relative acceleration. That's the fundamental assumption I'm making. I'm assuming that the target is a spaceship, and it's in high orbit or in open space. I'm assuming that the missile, at launch, used some type of minimization algorithm to find an acceptable course. I'm assuming the flight time is a matter of hours, and since no space drive in existence can burn at a reasonable rate of acceleration for hours, it's safer to assume no acceleration or to anticipate the cessation of the enemy's burn. So the missile launches. It uses the minimization algorithm's solution. Now it needs to chase the enemy through whatever evasive maneuvers the enemy takes. This is a case where the target now has a 0 relative velocity on any axis but a line between the missile and the target. Since it's high orbit or open space, the forces from gravity are very small and are very similar between the missile and target, so the relative acceleration is also close to zero. In THIS CASE, you just have the missile mirror the target. If the missile can't mirror the target, the missile can use a make up algorithm to trade thrust for distance compensation. No fancy equations needed, it can be done using very simple math.
|
|
|
Post by nivik on Oct 24, 2016 21:53:57 GMT
That's the fundamental assumption I'm making. I'm assuming that the target is a spaceship, and it's in high orbit or in open space. I'm assuming that the missile, at launch, used some type of minimization algorithm to find an acceptable course. I'm assuming the flight time is a matter of hours, and since no space drive in existence can burn at a reasonable rate of acceleration for hours, it's safer to assume no acceleration or to anticipate the cessation of the enemy's burn. So the missile launches. It uses the minimization algorithm's solution. Now it needs to chase the enemy through whatever evasive maneuvers the enemy takes. This is a case where the target now has a 0 relative velocity on any axis but a line between the missile and the target. Since it's high orbit or open space, the forces from gravity are very small and are very similar between the missile and target, so the relative acceleration is also close to zero. In THIS CASE, you just have the missile mirror the target. If the missile can't mirror the target, the missile can use a make up algorithm to trade thrust for distance compensation. No fancy equations needed, it can be done using very simple math. Ah, that explains the disconnect. I'm talking about guidance during the tactical, terminal phase, where we're trying to trim the <100km long-range intercept solution down to a zero-distance impact event, compensating for target evasive maneuvers, intercept velocity, missile acceleration profile, etc. Total time in this phase is typically under 45 seconds, as the missile burns the rest of its propellant to limit the time-window for effective countermeasures (point defense, evasive maneuvering, flare deployment), increase its kinetic energy in the case of KKVs/EFPs, and adjust the intercept to either achieve impact or warhead fuzing range. Long range strategic guidance is an entirely different problem which I haven't put a lot of thought into, yet, as I tend to focus more on the use of missiles as "long range" (60-100km) tactical artillery rather than concentrated strategic-range salvos. The terminal/tactical phase is a lot more interesting to me due to the challenges posed by those last few seconds of chaos. :3
|
|
|
Post by nivik on Oct 24, 2016 22:02:53 GMT
One thing that I think would help is to take advantage of some of the properties of our targets to constrain the possibility space. A few things are generally true of most capital ships: 1: They tend to have less than 1g of acceleration. 2: They tend to be fairly long relative to their ability to accelerate. 3: They tend to only be capable of accelerating in one direction (and if they do have RCS, it's usually weak compared to the main engines). 4: They generally accelerate along their long axis. Now, granted, baking these assumptions into our guidance to save performance would mean that someone could deliberately build a ship to break them (saucers break #2 by being circular, sidewall ships break #4 by accelerating along their short axis). But generally speaking, most warships have properties that make them fairly predictable targets. If you can determine where the engine is and aim ahead of it, you can then tolerate quite a bit of error in your guidance simply because the target is constrained to mostly moving forward at a low acceleration. One of the main challenges of missile guidance right now, in my view, is the fact that the missile's acceleration is so extreme, and that its acceleration changes drastically over time. For example, a 50kg missile with a mass ratio of 7.5 and an initial acceleration of 8.0g will have a final acceleration of 60.0g. This means the missile -- if it doesn't consider change in acceleration -- will drastically overshoot the target due to an extreme overestimation in the amount of time it will take to achieve an intercept, as it will start off by estimating the time to intercept a target at its most extreme range based on a static acceleration of 8.0g when its average acceleration will be 34.0g; almost three times its initial assumption. The issue is less extreme at lower mass fractions, but on the flip side, the missile is that much less capable overall.
|
|
|
Post by cuddlefish on Oct 24, 2016 22:20:38 GMT
And the thrust has to be that extreme, because you need the missile to be able to perform if it has to engage a target early in its burn. My current standard missile platform is 40 kilos of bi-propellant with 5 km/s of dV, on account of the former being a number that makes the ratio math easy, and the latter being nice and round. With my engine, that comes to a 10.8 mass ratio, so if it's going to have enough muscle to be able to hit a target while having most of its reserves as it enters the final approach (which is next to inevitable when orbiting small bodies), it has to have horsepower - I went for a hair over 5G. As currently configured, that means it's north of 500 newtons to the kilo when it's reaching burnout.
That's a frankly absurd amount of power, but if I want the thing to be able to close distance well with the really quite short approach distances[1], I'm not sure how to avoid it.
[1] Given the length of your final run is determined by the enemy weapon range... I wish you could plug in a minimum trigger distance for your missile, to ensure you have time for things like KKV to get up to speed.
|
|
|
Post by geraldmonroe on Oct 25, 2016 18:26:37 GMT
Ok, let's look at my algorithm again. Let's say that at T-45 seconds, the missile is on track to hit the system it's aimed at. Doing a bit of axis remapping, we make a line between the missile and the target be the Z axis, and the other 2 axes perpendicular to the missile (and inside a plane that is perpendicular to that line) be X/Y. At T-45 seconds, X and Y have 0 magnitude. Only the Z vector is nonzero. It's space, and at this range, even in low orbit both the target and the missile are subject to almost the same total gravity vector, so 0 relative acceleration. So my algorithm is this : 1. if the target makes a burn, measure the components of the target's burn on the X and Y axes and have the missile mirror those acceleration components. (you don't care about Z unless the target makes a burn so extreme that the sign of Z changes, aka the target is outrunning the missile) That's it. If the missile perfectly and instantaneously mirrors the target's moves (it has 4 rocket thrusters along the sides that start within milliseconds, similar to an ABM's final stage) the missile will remain at 0 relative acceleration with respect to the target and thus, per the shooting monkey experiment, will hit. What happens if the target makes a move the missile can't match until it moves a rocket nozzle? That's a more complex case and we can discuss that once we agree/disagree if the basic algorithm will work.
|
|
|
Post by nivik on Oct 25, 2016 19:09:51 GMT
Ok, let's look at my algorithm again. Let's say that at T-45 seconds, the missile is on track to hit the system it's aimed at. Doing a bit of axis remapping, we make a line between the missile and the target be the Z axis, and the other 2 axes perpendicular to the missile (and inside a plane that is perpendicular to that line) be X/Y. At T-45 seconds, X and Y have 0 magnitude. Only the Z vector is nonzero. It's space, and at this range, even in low orbit both the target and the missile are subject to almost the same total gravity vector, so 0 relative acceleration. So my algorithm is this : 1. if the target makes a burn, measure the components of the target's burn on the X and Y axes and have the missile mirror those acceleration components. (you don't care about Z unless the target makes a burn so extreme that the sign of Z changes, aka the target is outrunning the missile) That's it. If the missile perfectly and instantaneously mirrors the target's moves (it has 4 rocket thrusters along the sides that start within milliseconds, similar to an ABM's final stage) the missile will remain at 0 relative acceleration with respect to the target and thus, per the shooting monkey experiment, will hit. What happens if the target makes a move the missile can't match until it moves a rocket nozzle? That's a more complex case and we can discuss that once we agree/disagree if the basic algorithm will work. Ah, the missile is already in an intercept state and has translation thrusters. In that case, sure, it should work.
|
|
|
Post by geraldmonroe on Oct 25, 2016 19:51:18 GMT
Ah, the missile is already in an intercept state and has translation thrusters. In that case, sure, it should work. Ok, so let's extend it a couple of ways so it works for nearly every missile fired. First, obviously, since the missile can be retained in an intercept state from T-45, you can use the same algorithm to keep it in that state for the entire flight. The same logic can be expanded. Once the missile finishes it's primary burn to put itself into an intercept state, you can use it the rest of the flight. Now, what do we do if the missile doesn't have translational thrusters but is able to get the same effect by first rotating on axis and then firing a single engine? That means there's a delay between when the missile can mimic the target's acceleration and when it actually does it. The target now has a velocity and a position difference. So the missile has to make up for both of those by adding additional burns to it's burn queue. It has to first match position, so it has to change the magnitude of the X/Y vectors to "make up" for the missing position from it's previous intercept plan, then it has to decelerate on the X/Y axis to match the X/Y velocity difference, once again making that relative difference 0. It has to accomplish this before impact, so you do need an approximate time to impact. Anyways, the TLDR, is that in the actual C++ this game was (probably) written in, all these algorithms for missile behavior are very easy and very cheap. You do the big, expensive minimization algorithm (I'm talking about an algorithm that uses numerical integration and solves for the intercept by essentially a search of the solution space) just once for a fleet of missiles and use the above for the rest. What do they do in the real world in space? This. Note that every space portion uses translation thrusters. youtu.be/ae5VmVwfWmk?t=125ALSO, notice how fast those rocket thrusters are pulsing. That's realistic, hypergolic thrusters are very very very quick and the high ends ones used in something like this are going to be near instant. It's my opinion that a properly built missile, using today's technology, and thrusters like this, will NEVER miss - it'll slam into the target with a CEP of just a few meters - at 10+ km/sec intercept speeds - unless the target successfully decoys the missile or shoots it down. And the decoys shouldn't work at all if there's a data link between the missiles and the launching ship. If CoaDE wanted to be really realistic, if the launching ship is still alive with intact sensors, the launching ship would be able to send updates to the missiles to tell them which of the contacts visible on their IR sensor are the target. CoaDE could simulate speed of light lag for this data link, ofc. Even if the missiles can't carry a sensor sophisticated enough to tell the difference, there's dozens of heuristics you can use to reliably tell the difference between flares and the real thing.
|
|
|
Post by nivik on Oct 25, 2016 20:47:37 GMT
Ah, the missile is already in an intercept state and has translation thrusters. In that case, sure, it should work. Ok, so let's extend it a couple of ways so it works for nearly every missile fired. First, obviously, since the missile can be retained in an intercept state from T-45, you can use the same algorithm to keep it in that state for the entire flight. The same logic can be expanded. Once the missile finishes it's primary burn to put itself into an intercept state, you can use it the rest of the flight. Now, what do we do if the missile doesn't have translational thrusters but is able to get the same effect by first rotating on axis and then firing a single engine? That means there's a delay between when the missile can mimic the target's acceleration and when it actually does it. The target now has a velocity and a position difference. So the missile has to make up for both of those by adding additional burns to it's burn queue. It has to first match position, so it has to change the magnitude of the X/Y vectors to "make up" for the missing position from it's previous intercept plan, then it has to decelerate on the X/Y axis to match the X/Y velocity difference, once again making that relative difference 0. It has to accomplish this before impact, so you do need an approximate time to impact. Anyways, the TLDR, is that in the actual C++ this game was (probably) written in, all these algorithms for missile behavior are very easy and very cheap. You do the big, expensive minimization algorithm (I'm talking about an algorithm that uses numerical integration and solves for the intercept by essentially a search of the solution space) just once for a fleet of missiles and use the above for the rest. What do they do in the real world in space? This. Note that every space portion uses translation thrusters. youtu.be/ae5VmVwfWmk?t=125ALSO, notice how fast those rocket thrusters are pulsing. That's realistic, hypergolic thrusters are very very very quick and the high ends ones used in something like this are going to be near instant. It's my opinion that a properly built missile, using today's technology, and thrusters like this, will NEVER miss - it'll slam into the target with a CEP of just a few meters - at 10+ km/sec intercept speeds - unless the target successfully decoys the missile or shoots it down. And the decoys shouldn't work at all if there's a data link between the missiles and the launching ship. If CoaDE wanted to be really realistic, if the launching ship is still alive with intact sensors, the launching ship would be able to send updates to the missiles to tell them which of the contacts visible on their IR sensor are the target. CoaDE could simulate speed of light lag for this data link, ofc. Even if the missiles can't carry a sensor sophisticated enough to tell the difference, there's dozens of heuristics you can use to reliably tell the difference between flares and the real thing. I'd need to implement both control algorithms and compare them in simulation and/or do more study of existing literature to make a well-informed judgement regarding your assertions. I suspect the problem is not as trivial as you describe -- if it were, I think qswitched would have found such an algorithm in his literature search -- but I can't prove it at this time. I'm going to bow out of this thread until I've done more research into the problem and have a simulation set up to perform testing.
|
|
|
Post by geraldmonroe on Oct 25, 2016 21:03:27 GMT
I'm going to bow out of this thread until I've done more research into the problem and have a simulation set up to perform testing. If you're in a hurry, you can do it in 2d. Just drawpixel(x,y,color) is all you actually need. Not that rendering some spheres in Unity is hard (I suggest spheres because commercial physics engine collision detection can be very poor for high speeds, so you'd have to use your own, and it's much easier to detect sphere collisions if you're in a hurry). You do a high speed collision detection by pausing time and subdividing intervals.
|
|