Hacker News Reader

Comment by ForHackernews | Hacker News Reader

I'm somewhat surprised the physical units matter in a computer simulation. As long as the simulation is internally consistent (which I would assume the original code is) it seems odd to me that the nominal units are important at all.

Is that video game character walking 100 yards? Or maybe the character is 500 feet tall and he's walking 50 leagues?

View on HN

Author is at least partially reusing Unity physics engine instead of using physics integrator from original simulation. It is not a mechanical 1:1 translation of Fortran code to C#. Once you start mixing the two sims units and other constants matter. Also the unity physics engine is finetuned for operating at certain scale with certain units. You could operate it in different units, but that will potentially require readjusting not just major physics constants but also a bunch of poorly documented magic parameters designed to prevent Unity sim from exploding or wasting resources.

That makes sense, then. If he's porting between two different physics engines, not just putting a visualization layer on top of an existing simulation translated from Fortran to C#.

Gravity doesn't scale this way. Earth's gravitational pull (~10m/s^2) is a constant that ties distance to time, so if you want to observe the same gravitational effects in the same gravitational pull on a small dimensional scale, you need to adjust the time scale to compensate.

This is why scale model sets for practical VFX in cinema were always recorded at higher frame rates and then played back slower.

That's only a problem if you're dealing with real gravity shooting real models in a real physical world. In a simulation, you can set G to whatever it needs to be.

The acceleration defined to simulate gravity in this Fortran code is presumably already proportional to everything else defined in the simulation.

Right, but that's more effort than just using real units in the first place.

Physical units help modeling and review, it's much easier to sanity check values from just reading, and comparing constants. I've heard that for rendering/raytracing, a lot of people move to model light intensities by actual physical values which makes it much easier to author and compare - such as for example "oh I want a light here that is as bright as this old lightbulb I like so much, but there's sunlight also shining through the window". That's much easier than estimating it in arbitrary units, in particular as here human perception is non-linear. I assume this would be similar for other simulations.

In mechanics simulations we often change the units to avoid adding small and large floats.

They don't matter as long as the relative values and the relationships hold. For video games where you're making something arcadey you're often implementing the physical behavior in terms of regular old physics but the values used don't have to be real as long as you get the right results. It's just when you're simulating something real it's useful to have units that make intuitive sense and that's often real world units as we've built up a lot of understanding by using them already. In particular with a flight model based on look up tables from real world data it's already in a set of units.

They don‘t, but they have to be consistent. You wouldn‘t want to apply a hundred-fold torque because you mixed up your units.

Would you want to fly in an aircraft that's been modelled with pretend computer units? Or the one that was modelled correctly in a simulator? :)

Ok but if you did a global find-replace for "meters" with "smoots" do you think that the simulated plane would crash?

Ah but smoots would still follow the same maths as a meter right?

Yes, that's how numbers work. 10 smoots + 1 smoot is 11 smoots.

That's the point of my question.

Reply on news.ycombinator.com