a_e_k

Interesting. For contrast, switching to the one-good-pen approach was what finally did the trick for me. These days, I find I'm more likely to run out of ink than lose my pen. To each their own!

Robot animals with gun turrets make me think of Horizon: Zero Dawn.

For example, the Ravager: https://gamingbolt.com/wp-content/uploads/2022/01/horizon-ze...

Yep. That's still fine for building BVHs and shooting some rays around.

These sorts of data sets can be useful for graphics research, particular as a data set to test ray tracing algorithms on.

See for example, the Moana Island data set. [1]

I definitely foresee papers on BVH construction using this scene.

For graphics research in academia, there's a dearth of real-world data sets like this, so the ones that do get released are gold. And for graphics research in industry, one may have access to good internal data sets for development and testing, but getting permission to publish anything with them tends to be a giant hassle. It's often easier to just use publicly available data sets. Plus, that makes it easier to compare results across papers.

[1] https://www.disneyanimation.com/resources/moana-island-scene...

There's also the funding acknowledgement in the YOLO v3 tech report (https://pjreddie.com/media/files/papers/YOLOv3.pdf):

> But maybe a better question is: “What are we going to do with these detectors now that we have them?” A lot of the people doing this research are at Google and Facebook. I guess at least we know the technology is in good hands and definitely won’t be used to harvest your personal information and sell it to.... wait, you’re saying that’s exactly what it will be used for?? Oh.

> Well the other people heavily funding vision research are the military and they’ve never done anything horrible like killing lots of people with new technology oh wait....[1]

> [1] The author is funded by the Office of Naval Research and Google.

I also like that I can point to my production credits as public proof of employment history.

As a night owl myself, I've often thought I might prefer it if the Earth turned on a 25 or 26 hr cycle.

If you're interested in this, let me also plug the High Performance Graphics 2024 conference where this paper was accepted and will be presented at the end of the month. It'll be co-located with SIGGRAPH 2024 in Denver, CO. Come for HPG, stay for SIGGRAPH.

Here's the full program: https://www.highperformancegraphics.org/2024/program/

(Disclosure: I'm on the HPG conference committee.)

There's a relatively straightforward trick that you can do here. If you've got a transform that turns a circle into an ellipse with the relative radii and orientation that you want, then:

1. Apply the inverse of that transform to your path.

2. Stroke the path.

3. Apply the transform to the result.

This way, the path stays in place but the stroke is transformed to give it a calligraphic look.

With a JavaScript Canvas, you can just set the transform after defining the path, but before stroking. JSFiddle example: [0].

(This was something that I tested in my tiny, single-header <canvas>-like 2D rasterizer library for C++ and my Javascript port of its test suite [1].)

For Inkscape, I think you can convert an object to a path, apply the inverse transform, do a minimal simplification to bake the transform into the path, stroke it, and then apply the forward transform. It's a bit clumsy, but I bet someone could easily create an extension script to do it.

[0] https://jsfiddle.net/y7m16wa0/

[1] https://github.com/a-e-k/canvas_ity/blob/main/test/test.cpp#..., https://github.com/a-e-k/canvas_ity/blob/main/test/test.html...

Yes, that's a clever way of demonstrating viability (and with more than one compiler implementation).

I do like the examples that I see there.

This seems like the kind of language feature that I might not make much use of directly in general application code, but would wrap up in utility functions or use via lower-level libraries that the application code builds on. E.g., they showed command-line parsing, but I could also see this for benchmarking and testing frameworks to automatically find the workloads and tests in a non-hacky way.

I also wonder about how this feature interacts with translation units or modules and linkage, though. I'm reminded of the static initialization order fiasco; this seems like it might open up issues that make that look tame by comparison. (Not a complaint; I'm actually looking forward to this.)

[Repeating a comment from a few years ago:]

When I developed my own coding font (Luculent), the compact sample that I ultimately came up with was:

    //  The five boxing wizards jump
    #include <stdio.h> // <= quickly.
    int main(int argc, char **argv) {
      float il1[]={1-2/3.4,5+6==7/8};
      int OxFaced=0xBAD||"[{(CQUINE";
      unsigned O0,l1,Z2,S5,G6,B8__XY;
      printf("@$Hamburgefo%c`",'\n');
      return ~7&8^9?0:l1|!"j->k+=*w";
    }

It has a pangram, lots of confusable pairs of characters adjacent to each other, opening brackets next to each other and near a pipe character, quotes and commas next to each other, lining operators (i.e., ->, += and <=), and every normal punctuation character on a US keyboard. It also happens to be a valid, though useless, C or C++ program.

I've often wondered about that. I feel like it says something about the development team behind Teams if either, (a) it doesn't bother them, or (b) they don't dog-food their own product this way.

(Just give me fenced code blocks, please!)

IIRC, both the Jedi engine (1995, Dark Forces) [1] and the Build engine (1995, Duke Nukem 3D) [2] which were of the same era used "sectors" rather than BSP trees for resolving visibility. Basically, it would traverse a graph as rays exited one sector and entered a neighboring sector. The approach is very much akin to walks through tet meshes in modern science apps.

In ray tracing, there are three commonly used spatial acceleration structures these days: grids, binary space partitions, and bounding volume hierarchies. Any one of those might have worked for Doom.

Though this post mentions marching through grids (as in Wolfenstein 3D) as not working for the arbitrarily positioned and angled walls, the usual way of using grids for ray tracing is to have each grid cell hold a list of the primitives that overlap it (many-to-many). Then you march the ray through the grid and test the ray against the list of primitives for each cell. You'd often use "mailboxing" (i.e., tiny LRU) to prevent retesting the same primitives over and over, since adjacent grid cells would often share primitives.

So basically extending the Wolfenstein 3D grid approach to Doom would have mean voxelizing the map to get lists of candidate walls for each cell, but testing the rays against the walls themselves (rather than say, the voxels themselves like in Minecraft).

I'm not sure what the tradeoffs for memory or performance on the 386s of the time would have been, however. But I think it's clear that while BSPs were a clever solution, they weren't the only possible choice.

[1] https://en.wikipedia.org/wiki/Jedi_(game_engine)

[2] https://en.wikipedia.org/wiki/Build_(game_engine)

Just call the upper levels the Star League. ("You have been recruited by the Star League...")

As someone who's used TikZ for paper figures recently, this is brilliant! I could see this saving a lot of time spent both on studying the documentation and on trial-and-error to coax TikZ to render the figures the way I want. I would absolutely use this.

Yes, if it had just mentioned that it meant a great circle, I would have felt like it wasn't such a gotcha question.

> in a straight line along the Earth’s surface.

This already seems suspect, given that the earth's surface is curved. A true straight line from the starting point would take us off into space.

So this feels like it's all just quibbling about different curved lines and which is closest to some definition of straight.

I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well.

One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise".

As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in the single precision while keeping an eye out for precision loss. Then I can either rewrite my math to try to avoid the precision loss, or selectively use double precision just in the parts where its needed. I think that using double precision from the start is a big hammer that's often unneeded. And using single precision buys you double the number of floats moving through your cache and memory bandwidth compared to using double precision.

Apple's reference: https://developer.apple.com/fonts/TrueType-Reference-Manual/...

(I spent a lot of time with both of these when hand-hinting my programming font.)

> Smith said that she’s also curious how this research would translate to non-domesticated cats like big, wild cats. “We don’t know whether wild cats are susceptible to that illusion, because they may not encounter corners and walls the same way,” Smith said.

Given that big cats behave with (proportionally larger) boxes much the same way as domestic cats:

https://youtube.com/watch?v=J11uu8L8FTY

I am going to hypothesize that it would translate quite well.

Another for the pro side: inlining can allow for better branch prediction if the different call sites would tend to drive different code paths in the function.

The zstd API does allow you to supply your own initial dictionary, so there's no need to fork it to allow a browser implementation to use the brotli dictionary.

Personally, as someone who doesn't work in web, I'm just as happy that zstd is flexible this way. For my applications, the brotli dictionary is pure overhead that bloats the library.

Fun! After a few game, my best was 100% on the 4th guess.

It looks like it's using Euclidean RGB difference, so one potential approach if you don't want to eyeball it is to just try to try to find the match for each channel one by one.

Edit: Okay, my new best score was 100% on the 1st guess, thanks to the browser inspector. :-)

Yes, I'll never understand the "fix typo" commits when `git commit --amend` is so straightforward.

And for those using Magit in Emacs, you can do this by selecting a region of lines and hitting `C-c M-g l`.

https://magit.vc/manual/magit/Commands-for-Buffers-Visiting-...

True! It would definitely be a chance to improve.

Oh, that one's interesting. I hadn't seen that alternative before.

Yes, I was thinking of consent as part of the "appropriate licensing".

Yes, putting aside the controversy, I agree that its sorely out of date and not very representative of modern images. I remember being amused when first seeing the paper with Fabio, but sadly it too is greyscale and of poor resolution.

Regarding many images being trained, I have mixed feelings. I think that the modern approach of having a solid corpus of images is important for quantitative analysis, but it's also nice to have a well-known common image to eyeball for a quick qualitative check.

Makes sense to me, though I've noticed that it's surprisingly hard to find a good alternative test image. This one has:

- Fine directional texture (the weave of the hat, hair)

- Fine non-directed texture (the feathers)

- Fine detail (eye glint, lashes)

- Medium texture (reflected hair)

- Sharp edges

- Curved edges (mirror frame, shoulder)

- Smooth gradients (skin, blurred beams on left)

- A closeup face

- Color

- Strong contrasts

I'd love to see a consensus around a good alternative high-resolution test image that has a bit of all of that (and maybe with a Macbeth chart thrown in somewhere too) with appropriate licensing, but none of the suggested alternatives (e.g., cameraman, mandrill) that I've seen quite have everything or are of any better resolution.

One source that I have recently been using for test images for my experiments, though, is the Wikimedia Commons Picture of the Year finalists collection: https://commons.wikimedia.org/wiki/Commons:Picture_of_the_Ye...