21:56 <queqiao--> Reply to "J​os​hu​a ​Wo​od​: unticking unpinned celestials is basically unticking a "please lag my game" button every ..."

21:56 <queqiao--> <r​ud​em​ar​io​> > unticking unpinned celestials is basically unticking a "please lag my game button" [...]

21:56 <queqiao--> <r​ud​em​ar​io​> Oh my god you Joshua you have LITERALLY just saved my life

22:01 <queqiao--> <r​ud​em​ar​io​> Obviously I'm not going to wanna run with an empty map view essentially all the time but this is unbelievable tech for buying you some frames while inputting when you're busy plotting something really costly and kinda need the spaghetti nightmare

22:09 <queqiao--> <r​ud​em​ar​io​> I also saw the general discussion going on about the rendering performance/optimization and how Egg mentioned that they were supposedly choosing to render the UI "for like, 20/8 vision". That plus the fact I also saw mention that "the [actual costs of calculations] are [relatively cheap and not that big of a perf concern]", something about them being "cheap to basically done", makes me wonder if maybe most of the

22:09 <queqiao--> Principia lag people are accustomed to is just UI related? I and I imagine most other people were under the assumption the actual calculations were the most expensive portion of Principia

22:15 <queqiao--> <r​ud​em​ar​io​> I have absolutely no idea whatsoever and dont even want to pretend I know anything or have any experience with trying to render objects inside of an existing game's engine in specific scenes and what sorts of limitations might be imposed by that, but maybe if there's room for optimization in the UI system, a solution exposing tradeoffs to the end-user (like a slider setting for what fidelity for rendering the orbital

22:15 <queqiao--> lines to adjust on the fly, with the existing setting as a default) might influence user behaviour in a more idealized way

22:18 <queqiao--> <r​ud​em​ar​io​> If users subconciously "feel" like the "culprit" for their lag problems (if they're concerned) is the orbital line fidelity setting, and they turn it down to a lower level they can tolerate (and get better FPS from it), then they might be content "targeting" that feature and be more likely to leave all the UI settings on and visible (like supposedly equipotentials having a history of people feeling compelled to turn

22:18 <queqiao--> them off then people shooting themselves in the foot)

22:25 <queqiao--> <r​ud​em​ar​io​> Idk, influencing problematic human nature behaviour trends is a topic interesting to me. Like to use that one cliche'd example, how most people aren't really interested at all in what temperature an office actually is, they're only interested in whether or not they feel they have any perceived autonomy over their feeling; almost all temperature related complaints in offices completely evaporate simply by there being

22:25 <queqiao--> "localized" adjustable thermostats on the walls with readouts, whether or not they're encouraged to use them by office admin. The cold people are still cold and complain, the hot people are still hot and complain, but the other 85% of people just suddenly don't have a problem anymore

22:28 <queqiao--> <r​ud​em​ar​io​> Maybe right now, users subconciously make an association with Principia's lag being "UI draw complexity" related, so they start only trying to optimize for "turning on as much as they need to see right now", when very clearly the intent behind Principia is to have everything be left on and only removed based on cognitive overload/focus/clarity reasons, and that the UI complexity isn't the problem in the first place

22:28 <queqiao--> (since supposedly the computations are not the perf bottleneck if I read the conversation right)

22:32 <queqiao--> <r​ud​em​ar​io​> It's possible that users wouldn't even complain if you guys started REMOVING the ability to turn stuff off if you wanted to if users were made to feel like some "other" area was the cause of their lag. Since draw lag might be just UI rendering fidelity related (other than being step related obviously) then maybe adding a slider exposed to the user to modify the fidelity drawn at will might be all the subconcious

22:32 <queqiao--> impulse/drive users need to not feel compelled to turn anything off anymore, even if nothing really changed on the backend

22:32 <queqiao--> <r​ud​em​ar​io​> Human nature is funny

22:33 <queqiao--> <r​ud​em​ar​io​> Just like the reason why I felt compelled to write a giant wall of text just now despite nobody talking and making myself look like an absolute goon

22:38 <queqiao--> <r​ud​em​ar​io​> Also I know how annoying it can be when people try to help out or suggest things to help fix or improve certain features (so I try to keep my mouth shut and just lurk around places most of the time, it's been probably like 4 years since I've done this so I promise I'm not "one of those guys") so ABSOLUTELY feel free to ignore everything I said if any of the devs bother reading this if it's even MILDLY annoying. I just

22:38 <queqiao--> wanted to mention something in case it sparks an idea or helps start a brainstorming session and is useful. Do not feel obligated to entertain even a single word of this I've said if you even bother reading it out of principle

23:15 <queqiao--> Reply to "r​ud​em​ar​io​: It's possible that users wouldn't even complain if you guys started REMOVING the ability ..."

23:15 <queqiao--> <C​om​po​su​re​ 1​> The first kind of slider this made me think of is the height difference between contour lines on a topographical map. The darker lines are every large height change and the lighter and smaller ones are every small height change. A slider to set that difference could be very useful - set it high for performance reasons, and when you need to actually adjust something, set it low.

23:15 <queqiao--> <r​ud​em​ar​io​> It's possible that users wouldn't even complain if you guys started REMOVING the ability to turn stuff off if you wanted to if users were made to feel like some "other" area was the cause of their lag. Since draw lag might be just UI rendering fidelity related (other than being step related obviously) then maybe adding a slider exposed to the user to modify the fidelity drawn at will might be all the subconcious

23:15 <queqiao--> impulse/drive users need to not feel compelled to turn anything off anymore, even if nothing really changed on the backend

23:22 <queqiao--> Reply to "C​om​po​su​re​ 1​: The first kind of slider this made me think of is the height difference between contour l..."

23:22 <queqiao--> <r​ud​em​ar​io​> I had to think about this for a second. You mean like, literally "make the lines thicker in case A/make the lines thinner in case B, which is much like how topographical maps use 2 or more thicknesses"

23:25 <queqiao--> <C​om​po​su​re​ 1​> Well that's one way I suppose, but what I meant was that the slider would have settings where the highest performance only shows every other major line (if a minor line is every 1 unit and a major line is every 10 units, then this would only show the major lines every 20 units) and the highest resolution setting shows every minor line as well as all the major lines.

23:27 <queqiao--> <C​om​po​su​re​ 1​> Highest resolution: 🟦 🟦 🟦 🟦 🟨 🟦 🟦 🟦 🟦 🟩

23:27 <queqiao--> <C​om​po​su​re​ 1​> Middle setting: 🟨 🟩

23:27 <queqiao--> <C​om​po​su​re​ 1​> Highest Performance: 🟩

23:28 <queqiao--> <C​om​po​su​re​ 1​> Does this make sense?

23:31 <queqiao--> Reply to "C​om​po​su​re​ 1​: Well that's one way I suppose, but what I meant was that the slider would have settings w..."

23:31 <queqiao--> <r​ud​em​ar​io​> I'm pretty sure the performance issue isn't from how the lines are visualized, like in a literal sense like you're describing, because the issue is with the amount of integrations being computed for a given spline; they're just drawing lines on the screen that represent a known math function. Think about it like this: If you draw a circle with only 4 points it looks like a diamond. You draw one with a million, it'll

23:31 <queqiao--> look like a circle until you zoom in far enough that you can see it's not a perfect circle anymore. To draw a line to the screen, you first have to figure out "what" you want the approximation to look like (aka how many points to draw). For you to be able to know to show "every other major line" you first need to calculate all the major lines, then choose only to draw half. The problem is that they're calculating more than needed for our eyes to

23:31 <queqiao--> visually interpret the curved lines as "curved lines", aka "too much resolution", whether or not they ever show it to us at all.

23:32 <queqiao--> <r​ud​em​ar​io​> https://media.discordapp.net/attachments/480397772248580098/1382865218266333245/images.png?ex=684cb518&is=684b6398&hm=f32f36d4db23f03c1266e8734b1ec03fd53c4042901ff9b791f0647bef019b28&

23:33 <queqiao--> <r​ud​em​ar​io​> if you look at the image on the left and look at the points, then look at the curved line, this is a really exaggerated example of the problem

23:35 <queqiao--> <r​ud​em​ar​io​> To skip units you need to know where units are to skip in the first place

23:36 <queqiao--> <r​ud​em​ar​io​> (the problem is one step backwards in time than the rendering I believe)