A more robust blend?

[omgitsraven]

I ran into a case recently where the default blend method was producing weird artifacts, but a different blend method didn't:

and I'm tempted to offer smin-exponential as a replacement for blend, but the fact is it runs about 50% slower, and I'm not sure if that would be worth it for something that works fine in most cases. Instead maybe I could add it as blend-precise or something, for people to manually switch to when they've found that a shape they've blended is acting glitchy?

The other thing is that smin-exponential takes a number that produces a sharp result with large numbers and a smoother result the closer it gets to 1, i.e. something that would map more closely to (/ m) compared with how blend works... and I'm getting reasonably close at getting the two functions to produce similar results for smoothing values under 1 (my best result is let ((k (/ (expt (/ k 2.4) 1.2))))), but I they're never quite going to produce the same result, and I'm wondering whether it's worth trying to map them similarly like this, or if it would be better to just inform people that they take different input values and let them find the new value they want, rather than implying that it could be similar.

(I think I've mentioned this before, but just for the record, I'm getting these algorithms from here: http://www.iquilezles.org/www/articles/smin/smin.htm )

[mkeeter]

I think that the standard library should take the slower-but-better option by default.

The commit above makes the default blend a robust one based on IQ's polynomial blending, also named blend-poly; the old function is now blend-rough. Feel free to open up a PR for blend-expt, which seems to be your favorite 😃.

(If you want to go overboard, you could also add an optional type argument to blend-difference, e.g. something that takes 'expt / 'poly / 'rough and picks the appropriate blending function).

[omgitsraven]

Did you mean to leave blend-rough still exported as blend? (I thought it might be for backwards-compatibility, but then why change the name at all...)

[omgitsraven]

Anyway, a bigger issue is -- for some reason, blend-poly seems to not work with auto-bounds at all, even though blend-rough and (my) blend-expt do?

blendpolybug.io.zip

That's the only reason I was using blend-expt; I assumed blend-poly didn't work at all for some reason, but I was misremembering our previous conversation ( #78 ), that was actually (what would be) blend-power... it turns out blend-poly works fine as long as it's within the default bounds, but auto-bounds seems to have a really hard time keeping up with it; sometimes it gives no result at all, and sometimes (in the attached example) it's just partly outside for no reason.

[mkeeter]

I'm (slightly) breaking backwards compatibility here, by making blend an alias for blend-poly rather than blend-rough. I think that the break is worth having the default blend be more robust.

Your attached example is a case where auto-bounds failed, and the bounds fall back to the default (global) bounds, which don't contain the full shape. I think everything is working as designed, except that we need better UI indications for when autobounds failed (and obviously autobounds could be more robust).

[omgitsraven]

Oh whoops, sorry, I read that too quickly, you're right (about blend being an alias for blend-poly, not blend-rough like I thought on first glance), sorry about that.

About the auto-bounds thing, though: my point is that auto-bounds is consistently failing on blend-poly for me -- it was breaking on the shape at the top of this thread, and also in that simple example with the spheres. Is that something you'd expect to be fixable, or just an inherent shortcoming like blend-power? (If so, would blend-expt be a better replacement?)

[omgitsraven]

Just checking in here to make sure you're aware that blend is now broken for anyone using auto-bounds? Should I be opening this as a separate issue or something? (Not trying to rush the fix, but I want to make sure you're aware it's happening...)

[mkeeter]

Yes, I'm aware, but haven't thought about how to fix it – I think the structure of blend-pow naturally tends to blow up interval math, so bounds-tracking doesn't work well.

What do you think – should we make blend-expt the default blending function?

[omgitsraven]

If blend-pow can't be fixed, then I think so; I've been using blend-expt with pretty good success, other than the initial annoyance of how different the smoothing term is.

I can do a pull for it -- do you think I should have the function automatically apply my conversion to make it produce roughly similar outputs for the same smoothing values, just to ease the transition (and let people more easily switch between them)? (Maybe I can add a blend-expt that doesn't do anything to its smoothing value, then also a blend-expt-unit that applies the conversion, and alias blend to the latter?)

[omgitsraven]

Also: should I just get rid of blend-pow while I'm in there, if it's going to be un-fixable? (Or should I just amend the docs to clarify not to use it if auto-bounds is in use?)

[omgitsraven]

Quick question: why is blend-poly wrapped in a lambda-shape? (It seems to work the same without it?) Is there some reason I should be including that in blend-expt, or is it there by mistake?

[omgitsraven]

Also: what makes the shape reference listing describe blend-rough as "alias for blend"? That isn't right, but I can't find where to change it...