Well… In my opinion, it is fine to use. Sometimes you can find such expressions in real-life code. I cannot see relation between the values that you use to multiply i_offset. Thus, if you do not have any serious reason to shorten it, you should leave it as it is.
Theoretically, you are able to shorten it in different ways. For example,
a switch statement is a good idea. Slightly better performance than a series of if checks i believe, and would be just as readible.
Unless its something that gets called thousands of times and performance is critical i wouldn’t worry about shortening that. it’s fairly short as it is and you’re going be making a sacrifice in terms of how readable/editable it is. Premature optimization is a curse
actually it’s not mordus. I’ve looked into this heavily on stack exchange. If’s are king and i don’t know why switch even exists lol. I guess a enum would be more convenient.
Its actually pretty simple to build an empirical formula from any set of data points, especially over such a limited range. I didn’t even need to go to a polynomial. So here it is.
Of course this is actually less readable then the original. And harder to modify. Personally I would use an animation curve to do this job. Animation curves beat formulas for this system every day of the week.
very interesting…animation curves and draw a graph to create the formula? wow that is some awesome stuff right there man! however i would not want to round…
out of curiosity how did you calculate the 0.26666f + 1.1873f
Ok, so here is the results. It looks like it has issues and i guess this isn’t possible because the formula changes at certain points. the only way i can think this can be more accurate with a formula is for me to show you my entire method for this. At this point i think i will just mention what everyone else said and probably just stick with the if/else if’s i think it will process faster anyway then doing more math calculations.
I know one of my flaws to this entire method is i haven’t calculated the size of the units. This whole thing will need to be different based on what unit it is somehow too…
maybe this may help for you math guru’s. 3/2 = 1.5 6/3 = 2 10/4 = 2.5 it goes up by 0.5 every else if that is why i thought a formula would be possible. Oh and int i_offset = 12;
looking at it this way:
//12 / 1 = 12
if (i < i_offset)
radius = 1;
//36 / 2 = 18
else if (i < i_offset * 3)
radius = 2;
//72 / 3 = 24
else if (i < i_offset * 6)
radius = 3;
//120 / 4 = 30
else if (i < i_offset * 10)
radius = 4;
//180 / 5 = 36
else if (i < i_offset * 15)
radius = 5;
//should be 252 / 6 = 42 but the circle doesn't really need to be any bigger
else
radius = 6;
Threw the numbers for i, i_offset and radius into excel. Once in excel I graphed radius against i / i_offset. This gave me an almost straight line. I used excels trend line function to draw the line with an equation.
Under the hood excel uses a least squares regression to figure out the equation. If the equation was more complex, I would have done it by hand.
Its a pretty neat trick. You can expose an animation curve. Plug in whatever values you want as key frames. And then just read off the curve whenever you need it. I highly recommend it for this type of work. An animation curve is easy for designers to understand and tweak. Where as a formula requires a mathematician to adjust.
As to rounding, with a simple animation curve you can just cast to an int. Its a pretty cheap operation.
My formula lines up with yours at the cut points. But it might not line up in between. Nor does it line up properly at the low end. If you want a formula I would strongly suggest getting into excel and plotting out some data.
Why not just add the size of the Unit to the radius at each step?
I’m not entirely sure how you have this working. Some code may help.