looklookatme

Thanks for those insights! I think some of the things you mention (non-uniform scaling, concave meshes) are getting easier these days, thanks to tooling around things like convex decomposition and relaxed memory requirements, although, even without considering physics, it seems scaling causes huge problems for _everyone_ - feels like every Blender tutorial out there will say "remember to apply scale" to sidestep those scale issues. The other things you talk about feel very second-nature to me at this stage, so it's interesting to hear that kind of perspective. I think physics engines in general could certainly be doing a better job at documenting how the exposed physical parameters map unto use-cases.

I haven't come across Bevy before, but it certainly looks very neat from the example demos. If there's a WASM runtime for Rust, I _imagine_ it's possible to take the HavokPhysics.wasm used by Babylon.JS and calling the functions it exposes - the physics functionality exported by that WASM is pretty general and does not make any assumptions about the engine it's running in.

> Although, physics engines are inherently difficult to work with in the first place.

Do you have any insights into why this is the case? What areas of simulation or tooling are difficult to work with?

Disclaimer: I'm on the Havok team and worked on the Babylon.JS integration.

Not OP, but I've been using vim for 20+ years and I get enormous utility out of the mouse wheel for scrolling - especially with a trackpoint.

I spend an enormous amount of time _reading_ code and I want to move up and down quite a lot, but C-U/C-D move too fast (losing mental context) and C-E/C-Y are too slow and RSI-inducing; the wheel very easily allows you to encode an additional "velocity" dimension that the keyboard simply doesn't have.

When reading code, the mouse also allows you to navigate reasonably effectively using only one hand, leaving the other hand free for sipping coffee and taking notes.

I think I see what you're asking, but I'm not sure I can give a satisfactory (and correct) answer, here but I think you're on the right track:

> Why can't the W-'s kinetic energy be smaller...

That W- is a virtual particle - it can have any energy (according to some probability distribution) and you're correct that it doesn't _have_ to observe conservation of energy as long as that violation only happens for a very short period of time, which is precisely Heisenberg - there are other numbers it must conserve, such as electric charge.

> (b) quantum uncertainty (Heisenberg, tunneling, etc.) should still mean that bound neutrons should still decay once in a while

We do see this; this is what beta decay is.

> (c) a neutron next to a proton might randomly "swap" places once in a while

In general, this is correct. With limitations on what quantum numbers need to be conserved, these events are all constantly happening all the time. When writing out the equations for the system, you don't really have a term describing a proton and a term describing a neutron; you have a complicated mess of _all possible_ interactions and each elementary particle is described as a sort of "mix" of all the things it could be. So, in that sense, a bound neutron and proton is it's own thing - there's plenty of examples of these quasiparticles throughout physics and the definition of "stable" is quite application specific.

This is a massive oversimplification and anthropomorphizes elementary particles, but hopefully satisfies your curiosity. The reason for the worsening stability is because a free neutron has more potential energy than one bound to a proton. In the same way that a muon will "preferably" decay into an electron by interacting with a W-, if you were able to have a down quark floating in space by itself (you can't, for unrelated reasons,) that down quark would "want" to decay into a much lighter up quark by exchanging a W-. In both of these cases, the elementary particle loses mass through the interaction.

Inside the free neutron, that's what happens, too. A down quark interacts with a W- to transform itself into an up quark; the neutron is now a proton, with the W- carrying away some of the mass and electric charge.

However, neutrons and protons are more complex than just quarks. They're also big bundles of gluons, exchanging colour charge amongst each other. These gluons have mass and you need energy to create them. They actually account for most of the mass of a neutron/proton. A bound neutron and proton are exchanging these gluons amongst each other, too.

Suppose you had a bound neutron and proton. If the neutron were to decay into a proton, the electric charge of the particles (now both +1) would cause them to repel; you can imagine either of two things might happen: the protons will now move apart _or_ they'll stick together. In the former, you need kinetic energy and in the latter, you're going to need more gluons to hold the whole thing together. Both of those cases requires more energy (==mass) than the neutron would "lose" by converting to a proton.

So, if you can imagine the potential energy landscape, the bound neutron is at a local minimum (lower than a free neutron)

> Once you start playing around in GNU Radio and decoding more exotic stuff

Do you have any tips or resources on how to get to a competency level where you get to decode arbitrary digital signals you find from a scan?

I've read through all the GNU Radio documentation, along with the examples on their wiki and have even written my own blocks but keep finding that opening a grc file that someone else authored, there will be a critical block I've never seen before (and likely, never see again) which hampers experimentation. As soon as I attempt to decode a real-life signal, it feels like I dove in too fast -- there's too many unknowns, since the end result is [presumably] not going to be a nice, human-readable string. However, occasionally, I find challenges like [1] which are great, since you have the expectation that the signal _can_ be decoded; it's just that I've found examples like these to be quite rare.

[1] https://www.gnuradio.org/blog/2018-02-21-gnu-radio-challenge...

Would you mind elaborating on this? I'm in the same boat as return0 -- I just can't imagine what utility I'd get out of a touchscreen on my wrist.

Thanks for highlighting this; I took it out for a spin and wow it's fast. I normally find myself working on projects with tens of thousands of files and I've never really been happy with the few seconds it can take ctags to locate a definition or to tab-complete something. Though it seems like gtags is missing a couple of output-related options, the speed of lookup is a significant improvement.

Not to rain on your parade here, but eighty percent accuracy would require every sixth keypress to be backspace. Likely promoting it to the most pressed key.

Obviously, auto-correct mitigates this somewhat but for the amount of frustration and lost time, I'm betting it's probably worthwhile just purchasing a new keyboard.

I've got something similar in mine; The use-case is to allow indented comments (in languages where '#' is the comment delimiter)

Normally, when using auto-indent/smart-indent, pressing '#' on a blank line will change the column to zero, deleting any existing whitespace. By typing a character and deleting it, you override this behavior, allowing you to have comments at the same indentation level as the rest of the code.