Shrugger! Unity!

[Draco18s]

mathemagic

I actually didn't get that. At all 

Basically:

Math.pow(x, 4) == Math.pow(x, 2) * Math.pow(x, 2)  == Math.pow(x*x, (4/2))

And because several multiplications are faster than Math.pow (and the bitwise divide by 2 even faster) it's a shortcut to just reduce the processor load.

x^8 // == x*x*x*x*x*x*x*x
Becomes:
x *= x //x^8 == (x*x)^4
x *= x //(x*x)^4 == ((x*x)*(x*x))^2
x *= x //((x*x)*(x*x))*((x*x)*(x*x))

But in loop form

[keith.lamothe]

Velociraptor math: tear problem into pieces, consume individually (but rapidly).

[Shrugging Khan]

Are you computing the visual size of the number on the GUI, or are you checking whether it should switch to (value/1000)kilowhatevers or (value/1000000)megawhatevers, or what?  Depending on the actual use case there are often performance tricks you can do that have nothing to do with the actual work itself (and thus no make thog do math).  Not that there's really any point in optimizing this in this case, but just for kicks.

I'm actually doing both; Getting the optimal SI unit and rounding the value to as many digits as there is space left in the UI.
So please do tell Thog about ways to rig it up with rocks and tree trunks, he's not good at math.

Velociraptor math

Gah...why don't Math.Log and so on do this already? It seems like a straight-up improvement to have that as an option in there!

[Draco18s]

Velociraptor math

Gah...why don't Math.Log and so on do this already? It seems like a straight-up improvement to have that as an option in there!

Because it doesn't work for floating point exponents.  x^0.5 is square root, and so on.

A few plots.

[keith.lamothe]

Getting the optimal SI unit

That's probably simpler than all this: presumably there's a relatively small set of possible SI scales you're going for, probably 1/K/M/G for a lot of things.  Are you often wanting to display more than 3 digits "under" the decimal place, on an in-units-of-one number?

Anyway, if all you're trying to do in a particular case is testing for 1/K/M/G then just: if ( amount >= 1000000000 ) then G, else if ( amount >= 1000000 ) then M, else if ( amount >= 1000) then K.

and rounding the value to as many digits as there is space left in the UI.

From a usability standpoint, do you want it to display more than a certain number of digits? 

One of the things that really threw people about the numbers in TLF was how many of them were only significant in units of 1 (or higher) but it would show two or more places past the decimal due to generic handling of the prediction/result display logic (there is a ridiculous amount of stuff to predict and resolve in that game, so a generic framework was necessary).

One of the most popular changes I've ever made to AI War was dividing all the HP and attack (and a few other) figures by 1000.

Overall my point is that the question of "how many figures do I show?" is not "how many will fit?" but "how many does the player want?".  And once you know that then it's probably more a matter of designing your GUI to provide the necessary space on the minimum supported resolution and just go with that (plus whatever left/right/center alignment is necessary to make it look right at smaller values) rather than measuring it every frame.

So please do tell Thog about ways to rig it up with rocks and tree trunks, he's not good at math.

If problem hard, make it a different problem until rocks and tree trunks work.

Gah...why don't Math.Log and so on do this already? It seems like a straight-up improvement to have that as an option in there!

The general answer to that sort of question with generic libraries is this: because they're generic libraries, they cannot make very many assumptions about what's actually expected of them.  That limits the crazy unshielded-12-foot-diameter-buzzsaw optimizations they can pull without breaking spec on some subset of allowed inputs.

So if you call Math.Pow(double,double), expect it to treat the inputs as doubles and not to try int-specific optimizations on it.  Even with ints it has to consider overflow/underflow problems with bitshifting operations.  I'm not sure if those are problems that could actually be encountered in the case of Draco18s's approach above, but there's probably at least some edge cases that could bite it.  A few erroneous edge cases like that in your own code isn't a big deal.  A few erroneous edge cases like that in a core math function in .NET or Mono makes people flip the fleep out.

Yet another reason to write stuff yourself if you really care about how well they do their job   Though that has its own host of potential problems, of course.

[Shrugging Khan]

Getting the best SI unit is a bit more complicated than that, since there's square and cubic units as well, and the length differences between their steps are rather large.
*Sigh*...I guess I should stop trying to get the perfect result and just settle for something readable that works.

One of the most popular changes I've ever made to AI War was dividing all the HP and attack (and a few other) figures by 1000.

Yeah, I'm quite the fan of that change. There's still plenty of big numbers in the game, after all 

It's not feasible in my case though, and it's likely not a problem either. Since I'm trying to teach myself physics while I'm at it, I'm really just using somewhat realistic physical values for everything. So no damage values, hitpoints and fixed speeds - it's all mass, volume, energy density, acceleration and so on. Some of those are very small, some are very large, and I generally just want to write some code that ensure they're always displayed in reasonably readable units and roundings.

Yet another reason to write stuff yourself if you really care about how well they do their job   Though that has its own host of potential problems, of course.

Mostly just that it takes me months to get anything done 

Because it doesn't work for floating point exponents.  x^0.5 is square root, and so on.

Guess we can't have everything 

[keith.lamothe]

It's not feasible in my case though, and it's likely not a problem either. Since I'm trying to teach myself physics while I'm at it, I'm really just using somewhat realistic physical values for everything. So no damage values, hitpoints and fixed speeds - it's all mass, volume, energy density, acceleration and so on. Some of those are very small, some are very large, and I generally just want to write some code that ensure they're always displayed in reasonably readable units and roundings.

Ah, ok, I get it.  Basically this is developer information.  Unless the target audience is people who enjoy playing games that present them with numbers on the *10^11 scale and numbers on the *10^-11 scale at the same time

In that case, yea: don't try to make it nice, make it work.  Then when you're sure what you want to show, make it nice.

[Shrugging Khan]

Once more unto the breach, dear friends, once more!

I'm completely re-doing my procedural terrain generator. Yay for wanton destruction and reconstruction!

Right now I'm considering two options, both on a Model-View basis. For now, assume that I'm doing nothing but a heightmap.

1) A set of many data points describing elevation as model, with the view picking a subset of those and building a mesh around those picks by treating them as vertices. The problem here is that I haven't been able to cook up an algorithm that produces a usable, gap-less mesh of triangles. So far I have gaps, overlaps, crossing edges and similar troubles...

2) A set of few data points describing landscape features (hill here, lake there), with the view picking random coordinates and guessing the elevation by interpolating between the nearest data points. This has the advantage that the view can just slap down triangles in any way it likes, and get the relevant elevation data for the vertices wherever they may fall. Downside: I haven't figured out how I'm going to do this one, at all.

Any advice on how to do either or which to pick, or recommendations in general, are appreciated as always 

[Shrugging Khan]

Doing further work on procedural terrain; I was wondering how I could calculate how much lower terrain that's further out would have to be in order to account for the planet's curvature. As always, I cannot work out the math. Any help? 

[keith.lamothe]

Spherical terrain... ouch.

I'm not sure what the "right" answer is, but have you gotten to the point where you can generate a perfectly spherical (or near enough) ball of rock?  That seems like a good first step.  Then if you wanted you could deform it from there, and as long as each step was valid the result would be valid.

[Shrugging Khan]

I've cobbled (i.e.: googled) together a temporary solution based on Pythagoras' funky right angles. It won't work for the whole planet, but it's fine for anything from the POV to the horizon and a little way further around the globe. So it won't result in a complete sphere, but it will curve things nicely for that visual effect. It essentially just drops the vertical level of the terrain based on the planet's radius and the distance to the POV.

For viewing the planet from space, I think I will indeed take a sphere and just deform it a bit to suit the terrain data.

Sooner or later, probably once I include planet-to-space transitions, I'll have to actually generate proper terrain spheres. My model-side terrain data is based on longitude and latitude rather than actual 3D positions - I thought it would be easier to work with that way - so maybe I can just generate proper 3D positions based on that. Half the necessary logic for procedural mesh generation is already in place, but the actual math for calculating positions (something I did some months ago in a physics course and already forgot about...damn my memory) and the logic for sewing together the last unconnected triangles still needs figuring out.

And yes, I have once again completely forgotten why I am doing all this. But I know I must do it.

[keith.lamothe]

Yea, I think you're out of my depth on the math if you're converting 3D coordinates to/from lat-long.

To generate a basic spherical mesh my first try would be to generate a series of circles with their origin moving along one of the axes of the planet, sample N points per circle and make those vertices for the planet's surface and connect them to the previous and next circle's points.

For the "mostly flat plane" approximation of a relatively small area, if it's earthlike you could try a drop of 8 inches per mile.

[Shrugging Khan]

Yet another geometry/physics question!

When I have an object comprising multiple parts, and it moves and spins, and one of them separates - how do I calculate the velocity and angular velocity of the now separate object?

Thanks for any hints

[keith.lamothe]

When I have an object comprising multiple parts, and it moves and spins, and one of them separates - how do I calculate the velocity and angular velocity of the now separate object?

Oof. No idea in terms of the actual formulae. But here's what I'd do for a first try:

1) set velocity.magnitude and velocity.direction to the same values as the former parent object. They'll probably diverge quickly, with the former parent continuing to spin.

2) set spin.magnitude and spin.direction to... to... how do we figure out if it's perpendicular or parallel to the former parent spin and what do we do if it's somewhere inbetween... oh just forget about it and set them to zero Or to low random values to simulate them "tumbling" away.

[Shrugging Khan]

Oh just forget about it and set them to zero. Or to low random values.

That's the best advice I've ever recieved 
It's also how I'm placeholdering it until I figure it out. I know I've learned this stuff in my physics course last semester, but I don't remember how it's done and my notes are in another town.

Well, it's not all that important, I guess...until I have to build a catapult, at least.