419 karma · joined January 5, 2016
As to your second point, MacBooks have been available for how long now? And yet thinkpads still exist.
From the readme it sounds like this has actually started to be upstreamed now?
> Microaggression is a term used for brief and commonplace daily verbal or behavioural indignities, whether intentional or unintentional
It’s the unintentional part that I take issue with, which means that it’s not on you to understand the context of my statement, it’s on me to imagine the infinite variety of ways you might interpret my statement and vet them for possible insensitivity before making it, which is obviously impossible.
I agree that your definition makes perfect sense but I don’t think the sort of people who spend a lot of time worrying about micro-aggressions agree that the intention of the “aggressor” matters, as is perfectly evinced by this situation:
> “We would rather not take his course than to endure the emotional exhaustion of carrying on with an instructor that disregards cultural diversity and sensitivities and by extension creates an unwelcome environment for us Black students.”
Lots of different materials are difficult for GPUs because of divergence - if every ray spawned from a surface scattering event hits a different material you’ve lost all parallelism.
Lots of lights: Evaluating them all for a given surface scattering event is obviously an O(N) problem (for 10 lights no big deal, but what about thousands?), so you want to choose some small subset of “important” lights to consider. Making that choice is a hard problem because the correct choice depends on the product of the incident radiance from the light, the BSDF at the surface as well as the visibility function. There’s a lot of interesting research being done on this (Path guiding by learning the incident light field or its product with the bsdf, new sampling techniques, spatio-directional acceleration structures) at the moment.
The poly count is much less impressive than the number of different materials and number of light sources.
You were talking about games here, no? That's ultimate hard time constraint.
1000 loc gets you a very basic path tracer which isn't really going to be good for very much.
Your dispersion example is interesting - you can't really do it correctly with rasterization, no, although you can do a distorted background texture lookup with individually offset/blurred RGB channels. If you want to do rough glass you can just increase the blur amount. Not correct but looks 'good enough' in a lot of cases.
With ray tracing you can just trace 3 rays (one for one for each of red, green and blue). Simple! Except can you really afford 3 rays? Also how much do offset them by? You could use Cauchy's formula and use real refraction indices, but then you're going to get ugly separation between the channels. You could sample the whole visible spectrum and use temporal accumulation to build up the correct color, but now you've got color noise. What happens if you want to simulate rough glass? That's going to be very noisy indeed.
What about shadows from the glass? You can't afford to render caustics to do it correctly after all. Do you just ignore them? That'll look weird. Use a fresnel-weighted transparent shadow? Probably but now you have to handle that correctly everywhere and running a shader for shadow rays is expensive too so maybe you have to special-case that situation so most of your scene lands on the happy path.
My point is that anyone can write a basic path tracer in a weekend that will correctly simulate light transport given an infinite amount of time. Writing a renderer that will produce an image of a given quality in a given amount of time, incorporating a list of effects that an art director has decided are essential to the look of you product, is a very hard task still. It's simpler in a lot of ways, but also has to handle a lot of other complexities for the things that aren't possible in a rasterizer but are still very expensive to compute in a ray tracer.
For the work I do GC is also a non-starter. I know it’s got some level of no-gc now but the last time I looked it wasn’t well-supported.
In short it seemed interesting but on-boarding felt hard. And with that the value proposition wasn’t there or well-advertised: It’s supposedly “better” in some ways such as faster compile times and better meta-programming and frankly that didn’t seem worth the effort.
Rust by contrast does an excellent job of onboarding and making it easy to learn the language (at least at an introductory level). It also comes with a very straightforward value proposition: just as fast as c++ but whole classes of bugs simply aren’t possible. Add in a little bit of ergonomics and functional flavour and I was hooked.
At the end of it you might even develop Stockholm syndrome and be one of those posting “if you just restrict yourself to these parts of the standard and run this 6 static analysers on your code then c++ is perfectly safe if you’re not an idiot”.
If you don’t want to learn c++ for its own sake, that’s time you could better spend learning a language that’s not actively trying to harm you.
Source: coded c++ for 20 years, now writing rust as much as possible.
On the flip side I am very happy to trade that papercut for the simplicity offered by Rust’s move semantics compared to the minefield of c++.
source: i use linux
It’s fine. The UX is varying degrees of shitty as always but I can do what I need without too much hassle (mostly vscode/vim and the terminal).
The only thing I really miss from macOS is how nice editing PDFs was in Preview (filling out and signing forms). That and Photoshop.