Interests : systems programming, compilers, 2D & 3D graphics, performance
--------
Hello, my name is Jesse.
I describe myself as a competent generalist, and a lifelong learner. I'm frequently working on something I've never done before. I've worked at every level of the stack, from cycle-shaving hot loops that saturate instruction pipelines to the frontend of large web applications. My most recent professional experience has been about a year at a semiconductor startup; I wrote prototypes for an ISA, compiler, a cycle simulator and visual debugger.
In terms of hard technical skills, I can quickly become productive in nearly any language, and at any level of the stack. I'm comfortable working in heavily multithreaded/async soft-realtime environments where performance is a key acceptance criteria. I have a good understanding of modern hardware architectures, including GPUs, from main memory to registers and instruction pipelines. I have working knowledge of interpreters, dynamic language runtimes and garbage collectors. I'm convinced I can learn nearly anything (albeit some things more quickly than others), given an appropriate problem domain to apply it to.
In terms of business value, I can take hand-wavy visions of new products and turn them into working prototype(s), quickly. I'm comfortable refining those raw materials and delivering real value to customers, internal or external. I have a track record of successfully identifying 80/20 solutions and love the feeling of making tools that make peoples lives better.
In my personal life, I enjoy travelling, surfing, climbing, backcountry skiing, snowmobiling, pirates, and attending raves. I like the phrase "have strong opinions, weakly held".
If I was born to do one thing in this world, it's program computers.
I have a 10-year-old side project that I've dumped tens of thousands of hours into. "Ship the game" was an explicit non-goal of the project for the vast majority of that time.
Go look at profiles for programs which have been written with performance in mind. Operating systems, databases, game engines, web servers, some compilers, video/audio/3d editing packages come to mind. I 100% guarantee these programs do not spend the majority of their runtimes in a tiny section of code. What you said is nearly-unilaterally untrue, at least for programs that care about real performance.
I do write and profile software of that kind and this experience is why I know this isn't a myth. Any mature program has a whole lot of code that actually isn't performance critical at all. For example, 3d software needs a really huge amount of GUI and other support code that isn't performance critical at all. The performance hotspots are really just individual functions doing the core of the processing work for any of the features it offers. The initiation/scaffolding code around that just doesn't matter. The same translates to all other software that that I have worked on.
Static web servers I've actually seen spend most of their time in a couple of very hot paths (mostly the kernel's TCP stack). The others I agree with 100%, and also of course if your web server is doing any dynamic page work. Web browsers, too, and probably many important categories of software.
I believe the grand vision for Tarkov was for basically the whole world to be outside/dungeon. Kinda sad they didn't have the technical skill to pull off open world. That would have been an interesting gaming experience.
Cylindrical straw not included. Limited time offer. Warranty may be void if spaceship uses any reaction wheel or propulsion system. Other exclusions and limitations apply, see ...
There are two things one might care about when computing an SDF .. the isosurface, or the SDF itself.
If you only care about the isosurface (ie. where the function is 0), you can do any ridiculous operations you can think of, and it'll work just fine. Add, sub, multiply, exp .. whatever you want. Voxel engines do this trick a lot. Then it becomes more of a density field, as apposed to a distance field.
If you care about having a correct SDF, for something like raymarching, then you have to be somewhat more careful. Adding two SDFs does not result in a valid SDF, but taking the min or max of two SDFs does. Additionally, computing an analytical derivative of an SDF breaks if you add them, but you can use the analytical derivative if you take a min or max. Same applies for smooth min/max.
To add some more detail, the max of two SDFs is a correct SDF of the intersection of the two volumes represented by the two SDFs, but only on the inside and at the boundary. On the outside it's actually a lower bound.
This is good enough for rendering via sphere tracing, where you want the sphere radius to never intersect the geometry, and converge to zero at the boundary.
A particular class of fields that have this property is fields with gradient not greater than one.
For example, linear blends of SDFs. So given SDFs f and g you can actually do (f(pos)+g(pos))/2 and get something you can render out the other side. Not sure what it will look like, or if it has some geometrical interpretation though.
Note that speed of convergence suffers if you do too many shenanigans.
I did some simple experiments and fairly swiftly discovered where I went wrong. I'm still not totally convinced that there isn't something clever that can be done for more operations.
My next thought is maybe you can do some interesting shenanigans by jumping to the nearest point on one surface then calculating a modulation that adjusts the
distance by an amount. I can certainly see how difficult it would become if you start making convex shapes like that though. There must be a way to take the min of a few candidates within the radius of a less precise envelope surface.
No I was thinking a hard min, but one that finds a greedy but inaccurate distance and then a refinement takes some samples that measure nearest within a radius. This would handle modulations of the shape where it folded back upon itself as long as they don't fold within the subsample radius.
It's multi sample but selective rather than weighted.
I owe iq so much; a living legend. Inigo, if you happen to ever read this, thanks so much for all the work you've published. Your Youtube videos (not to mention shadertoy) sparked an interest in graphics I never knew I had.
For anyone that's unfamiliar, his Youtube videos are extremely well put together, and well worth the handful of hours to watch.
I can definitely say I wouldn't know half of what I do and probably wouldn't have kept at it with writing GLSL and learning more about how GPUs really work without a lot of his freely shared knowledge over the years.
His articles on his website are very much worth a deep read too!
reply