egg changed the topic of #principia to: Logs: https://esper.irclog.whitequark.org/principia | <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly…
_whitelogger has joined #principia
_whitelogger has joined #principia
<queqiao->
⟨sichelgaita⟩ Not at all in the case at hand, which is a single vessel with 1167 parts. We have one thread per vessel, not one thread per part.
<queqiao->
⟨stonesmile⟩ What happens if "hack gravity" is used with the 1167 part craft loaded? That should only remove the calculations for the current craft, right? This would be a way to isolate the effect of the optimizations from the background resource usage of integrating the solar system, etc, I think
<queqiao->
⟨egg⟩ That would be a way to measure that, but
<queqiao->
1. We know the answer: given the numbers at hand here (we are talking about frames lasting 180 ms) it is completely obvious that the handling of the vessel is where we spend practically all the time, since Principia has very good performance with more reasonable vessels;
<queqiao->
2. it’s not like that would inform any course of action;
<queqiao->
3. at the end of the day, getting the 1167 test case to perform acceptably is not going to happen, because KSP itself is stupidly slow there (even getting rid of Principia entirely, 138 ms frames are still going to be silly). It a useful test case to make the low-hanging fruits stand out, but it is just a test case.
<queqiao->
⟨stonesmile⟩ Am I reading it right that w.o. Principia, that vessel still takes 138 ms/frame?
<queqiao->
⟨egg⟩ Yes
<queqiao->
⟨stonesmile⟩ Ok, then 180 with seems entirely fine. What was it before?
<queqiao->
⟨egg⟩ That would be a way to measure that, but
<queqiao->
1. We know the answer: given the numbers at hand here (we are talking about frames lasting 180 ms) it is completely obvious that the handling of the vessel is where we spend practically all the time, since Principia has very good performance with more reasonable vessels;
<queqiao->
2. it’s not like that would inform any course of action;
<queqiao->
3. at the end of the day, getting the 1167 part test case to perform acceptably is not going to happen, because KSP itself is stupidly slow there (even getting rid of Principia entirely, 138 ms frames are still going to be silly). It a useful test case to make the low-hanging fruits stand out, but it is just a test case.
<queqiao->
⟨stonesmile⟩ * Would you happen to know what it was
<queqiao->
⟨egg⟩ Probably 130 ms more or so, looking at #3803.
<queqiao->
⟨siimav⟩ How much stock code is there that runs and then the results get subsequently overwritten by Principia. Have you considered clobbering some of it off?
<queqiao->
⟨sichelgaita⟩ The way it works is that we observe how KSP moves the various parts of the vessel relative to one another between two frames. That tells us the effect of the springs that tie all the parts together (and the decouplers and what not). Then we compute the location and general orientation of the vessel and reposition all the parts so that they reflect what KSP did, but with our location and orientation. We think of it as a...
<queqiao->
... marshmallow: KSP pulls and squeezes the marshmallow, but we decide where it actually is. The bottom line is that there is nothing from KSP that we can kill.
<queqiao->
⟨egg⟩ Is it a marshmallow or a caramel?
<queqiao->
⟨test_account9540⟩ It looks like the current version of principia has some issues with Rebase. I press rebase, and the trajectory briefly gets rebased, but then returns to the one before the maneuver that is already completed.
<queqiao->
⟨test_account9540⟩ the probe has already completed the TLI burn here, but pressing rebase keeps it in LEO.
<queqiao->
⟨test_account9540⟩ or maybe it happens because the optimization in on 🤔
<queqiao->
⟨test_account9540⟩ Oh, and the optimization option seems to enable itself when a maneuver is added.
<queqiao->
⟨egg⟩ The _on_ thing does not mean optimization is on. It means the inclination constraint is taken into account.
<queqiao->
⟨test_account9540⟩ But then there is an issue with rebase.
<queqiao->
⟨egg⟩ I am not sure what happens if you rebase while you have an optimization in progress, though in your screenshot you do not seem to have one, since there is not even a manœuvre.
<queqiao->
⟨test_account9540⟩ I was fighting with the rebase button, so deleted the maneuver, but it didn't help I think. I had to delete the flight plan to actually rebase.
<queqiao->
⟨test_account9540⟩ Anyway, what is shown on the screenshot should not happen. You can see a magenta line going past the moon, no maneuvers in the flight plan, but the orbit analysis claims the vessel is in circular Earth orbit.
<queqiao->
⟨test_account9540⟩ * the
<queqiao->
⟨egg⟩ Yeah, it should not happen after pressing rebase.