When you unwrap UVs the interpolation issue is taken care of. The UV map accounts for it.
It's only for tessellation like subdivision surfaces where something like this would be nifty That is to say, this is mainly nifty for the DCC tool renderer itself to render slightly faster.
It's not really that simple, barycentric coordinate access is relatively recent. It's asking the rasterizer for information and transforming that information into barycentric coordinates, and the correspondence of barycentric coordinates to vertices is unstable without further hardware support or further shader trickery. In the case of AMD gpus, it's only RDNA2 and later that have hardware support for stable barycentrics.
And you're right that this has been thought of. There are other approaches for bilinearly interpolating quads that have been historically used, but they require passing extra data through the vertex shader and thus often splitting vertices.
I am currently making a r7rs scheme derivative that compiles to C. The lofty goal is parallel fibers.
It's in extreme early stages, and I don't expect anyone will use it other than me, but I already like it. The compiler has been self hosted for a few months now. It has a cool FFI that you can see in use in the demos folder. Working on adding header generation to the module system.
While Chicken Scheme is cool, I don't think it'll be parallel, and not in the way I want it to be, and I am willing to make a lot of compromises Chicken isn't to get there. As mentioned, I am willing to settle with fibers for parallelism, and heavily eschewing side effects, making changes from r7rs to get there. For example, there will be no dynamic-wind provided and parameter objects will have different, thread friendlier, semantics.
----
My main reason for choosing C as a transpile is that it's easier to lean on gcc and C11 than it is to write my own codegen, and LLVM is too unstable for me to handle. I started writing this in June 2022, and since then LLVM has had 3 backwards compatibility breaking major release and millions of lines of code changed.
Well, a rotation matrix doesn't require doing 2 half rotations, and doesn't require reaching into the 4th dimension in such a way that it gets perfectly cancelled out. It doesn't require abstract analogies about cubes with strings glued to them or people holding coffee cups.
With some familiarity with linear algebra, it's easy to derive the formula for constructing a rotation matrix. You just have to think about what the operation does to the axes. The derivation for quaternion rotation is far more abstract, by virtue of the operation we actually care about involving a sandwich of multiplications with unclear 4 dimensional meaning. There's no hyperspheres with a rotation matrix.
Augmenting your space to handle not just rotations & scaling, but translations is easy for matrices, just requires a homogeneous coordinate and you get 4x4 matrices with intuitive columns.
Augmenting quaternions to handle translations requires the 8 dimensional dual-quaternions.
I definitely like geometric algebra, it's a very nice continuation of topics in linear algebra and makes it clear why things like normals behave differently from standard vectors. But I don't use it every day. I use standard linear algebra every day.
To add to your comment, quaternions predate rotational matrix operators by a considerable amount (1843 vs not exactly clear, ~1900 with Peano or ~1920 with Weyl), despite quaternions being much more challenging to manipulate. There are definitely simpler ways to view the same things.
There was a cottage industry of exotic hypercomplex numbers that disappeared when linear algebra matured to eclipse them.
In fact, Maxwell's Equations were originally derived with quaternions.
I was just talking with my wife about this. She's from southern China and went to a restaurant in north China with her northern colleagues. There they ordered cicada pupa, which were the most expensive thing on the menu.
With a lot of these expensive Chinese foods, there's an overlap with traditional Chinese medicine, as seen in bird's nest soup, black chicken meat, and such. And indeed, they convinced her to try one, saying that cicada are great for health and such. She felt guilty given that it was such an expensive dish, so she tried one. Reliving that memory made her feel nauseous.
Locusts are actually just various species of grasshopper. When there's abundance after a period of hard times, some some grasshopper species transform into locusts, turn from green into yellow, grow their wings and start swarming. The solitary and gregarious phase. When one locust becomes gregarious, he'll touch other locusts to turn them gregarious too.
> Edible insects are often talked about as a possible "food of the future" - but what does insect eating actually look like in the here and now?
There's definitely an overlap with the 'weird Japan' clickbait, but the first sentence of the article says to me that this seems to be an attempt to normalize the eating of insects to westerners who are highly culturally opposed to it.
Skimming the article, the wasp eating seems to be done for a festival in one particular village. In my experience, even people from cultures who had insect delicacies bragged to me about eating insects like some kind of rite of passage. I have yet to meet a foreigner who brings a bag of insects in their lunchbox.
I personally won't eat insects ever. The oceans can turn to acid, black clouds of smoke can envelop the earth, and I will still not eat bugs. I could imagine that most of the people in Japan feel the same way, or I could be wrong.
You're correct that British made factory goods would have been good for China, specifically the Chinese poor, as it would have enabled them to have many low quality goods rather than a few higher quality goods.
The issue is that when you present goods like mass produced clay teapots, cotton textiles, etc to the customs agents of the country which invented fine china, and silk, you're not going to impress them.
And yes, Britain coveted China. As did Japan, Russia, Germany, The United States, France, Italy, and Austria-Hungary. Even after they won the opium wars and got their favorable trades, they continued to work to overthrow or minimize the Qing dynasty and take political power. The Qing ended up sputtering out a few years before it became unfashionable to be a colonialist, so China dissolved into rule by warlords, then conquered by Japan, then the communists won and the rest is history.
The same smugness and sense of superiority that China held for England, was also held by England for China. As such, the English only primarily tried to sell knickknacks and things the Chinese could produce better. This ended up backfiring and cementing the view to the Chinese that the English were simple barbarians.
They did indeed have weapons the Chinese (and other nations) wanted, but only sold a limited amount of them, to avoid arming the other nations too well, in case they ever wanted to go conquering.
Well, England had a massive trade deficit, and failed to find anything the Chinese wanted to buy, except opium. In the end, this was approved by the queen to balance their trade deficit, as they were bleeding silver.
Well, in that historical case, the sale of Opium to China was a state sponsored project. Opium was only a minor problem in England, but it wasn't being smuggled into England by a quasi-hostile foreign country trying to re-balance its trade deficits.
I do cross platform development, I have to keep mobile/console in mind though most of my work in on PC, other people work on mobile/console and tell me when the shaders I write are too slow or break mobile :).
You work with 100,000 lux sun? Damn! We did physical values for sun/moon lighting when I did flight simulator stuff but that painfully required full float rendertargets, which is fine when you can tell Uncle Sam the minspec gpu is a 1080, but unacceptable for console and mobile.
Anyway we do full linear HDR for the 3D scene of course, as it's simulating physical light transport. Though not exact sun/moon values as we want to do half float rendertargets.
The UI does compositing in SDR sRGB.
Some of our textures are tinted with this rather cursed lab model I cooked up for speed, which is gamma encoded srgb linearly transformed so that 'l' = average of rgb and 'chroma' is rgb equally weighted but placed 120 degrees apart in the unit circle. Was designed to make HSV transforms linear operations (ie matrix multiply) and have great performance with acceptable quality with not too many imaginary colors. Nicer color spaces were too expensive, and it works good enough to make the artists like it.
Well, sRGB is sort of perceptually linear. Its roots trace back to a 50s technology compromise between perceptual linearity, color gamut, & encoding cost for CRTs that held up with only minor tweaks until CRTs stopped being widely used.
Maybe a fancier model like oklab would outperform it for this specific case, but only in quality, not performance oklab is more expensive to convert to/from compared to sRGB, which is usually free as your backbuffer and textures are usually sRGB.
I guess color theory hasn't been given much love in web development because it's hard and murky. Once you do a dive into it, you realize there's no correct answers, only tradeoffs. It's a lot harder to be zealous about some color model being the ultimate color model because you'll encounter reality soon enough.
I suppose the original author is a zealot for linear SRGB, but that might change once he encounters a black and white gradient interpolated in linear.
It's not astonishing to me, because I believe the author is not entirely correct about color being broken.
sRGB color is not the perfect color space, but in general it's better for UI than using linear color, which the author seems to be advocating for. The web is primarily UI. Not only that, but sRGB is the color space of probably 95% or more of devices, and of all low end computer monitors. sRGB is designed to balance perceptual linearity with encoding cost. It's very cheap to encode, and perceptual-enough that you can store a channel in 8 bits with high quality (linear value needs 16 bits to be comparable, and it's still worse unless you use half floats instead of unorm. It's common to go as low as 5 bit sRGB channels for albedo in computer graphcis.)
I am a graphics engineer, I've had a lot of colleagues learn the aphorism "don't do math in linear" once they get first burned.
> Unfortunately, by calling it a "color space", we've misled the vast majority of developers into believing that you can do math on sRGB colors
That belief is an over-correction in my opinion. The examples that the author shows are all about achieving physically correct lighting. The Rubik's cube image blended with 25% white doesn't look physically plausible because it's not being done in linear color.
But the goal with UI is visibility, not physical plausibility. If you want to cover something with a UI element at 50% transparency, you want 50% of the UI and 50% of the background, not a physical model of some transparent medium.
sRGB does however suck for defining gradients, but I think that's more to do with it being RGB. For this what I generally advocate is a luma/chroma model. Other posters have mentioned Oklab which is great, though even plain YCbCr will get you 80% of the way there while being cheap to convert to. You still want to do that in gamma/perceptual space though, not linear. The author didn't show gradients between white and black. Gradients between colors of 2 different luminances look awful in linear^.
However I totally agree with the author on zoom. Web browsers should be doing zoom/image resampling in linear space. Images shouldn't qualitatively change based on their zoom level.
It shines like that, with only some of the crystals being lit up at a given view and sun angle, from the surface being anisotropic. Light reflects more mirrorlike if it bounces parallel to the grooves in each of the individual crystals, and it is scattered if it bounces perpendicular to the grooves.
I think there's also an oxide layer contributing some iridescence, essentially a thin layer can cause constructive and destructive interference depending on light wavelength and thickness. If the light bounces mirrorlike, then a fraction of light bounces off the oxide surface, and a fraction transmits, then bounces off the metal. Depending on wavelength, these two light packets will interfere constructively or destructively. It depends on how many extra wavelengths the transmitted light travels (which depends on layer thickness, reflection angle, and light wavelength).
There was a flagged comment here that thought this manager's interviewing strategy was a good idea.
In this world, bosses end up holding power over their underlings. A boss who uses this power capriciously is tyrannical. A leader should use their power to achieve the shared mission of him and his followers, not arbitrarily.
There's a time and a place for ribaldry, and an interview isn't one. Generally those are optional situations that people can avoid if they don't want to hear it. This, and other sorts of 'tests' that some bosses use in interviews to test for 'thick-skinnedness' is equivalent to seeing if an underling will tolerate arbitrary abuses of power. It's equivalent to a test for absolute loyalty and servility, to see if the underling will be a yes man.
If a leader crosses a line for no good reason, perhaps by cracking a too risque joke, he or she should apologize and tone it down. It's about using your power responsibly and respecting your employees as you will have them respect you.
C++ Lambdas are capturing, so they aren't plain old functions. They evaluate to closures: function + environment. In C++ the captured environment is explicitly written in the [] section of the lambda.
The issue that I think the top comment is alluding to is that lambdas cannot capture by reference and then return, due to that stack frame becoming invalidated, which is a fairly large limitation that prevents swaths of lambda heavy code from working.
I personally think that this is a fine tradeoff for what C++ is: there's still plenty of utility in lambdas for simple higher order functions like maps and filters.
It's only for tessellation like subdivision surfaces where something like this would be nifty That is to say, this is mainly nifty for the DCC tool renderer itself to render slightly faster.