Antonio Caggiano

Computer Graphics expert, musician, deeply in love with science, arts and literature. Opinions are mine.

[Antonio Caggiano @Fahien]

Naive pathtracing needs a high number of samples per pixels to get an acceptable result, and shooting too many rays drastically affects FPS. But then look at the result once it starts importance sampling the light! 💡

#vulkan #raytracing #rust #rustgpu

[Sebastian Aaltonen @SebAaltonen]

Fixed all our Vulkan bugs:
- ARM: BGR swapchain handled incorrectly (our bug)
- Qualcomm: SSAO quad flicker (driver bug)
- PowerVR: material index rounding issue (our bug)
- Intel (iGPU): subpass barriers don't work (driver bug)

Now we are ready to ship Vulkan for end users.

[Eric Lengyel @EricLengyel]

This video shows the velocity buffer used to render motion blur during post-processing in the C4 Engine. The screen-space velocity accounts for the motion of the camera, objects, and even vertices for cloth and skinned meshes. This technique is described in FGED2, Section 10.7.

[Alexander Zapryagaev @frustum]

Discover the power of bindless rendering with Tellusim’s Hello Bindless tutorial. Learn how to optimize texture and buffer management for modern 3D graphics projects: https://t.co/AovbpiMnSn

[inigo quilez @iquilezles]

I designed some cute quartic surfaces #Math #Mathematics

[Dennis Gustafsson @voxagonlabs]

The new voxel format is finally starting to come together. It uses a brickmap that enables large, sparse objects, unique properties for each voxel (no palette) and really fast scene updates.

[Martin-K. Lefrançois @doragonhanta]

Just released: A modern #Vulkan (1.3, maintenance 6) sample app showcasing current best practices—all in a single, easy-to-read file. Great for learning, modernizing, or enhancing your Vulkan projects!
https://t.co/mIvUBGRmSW

[Sebastian Aaltonen @SebAaltonen]

I am impressed about our new WebGPU WASM page load time. Whole engine loads in just a few hundreds of milliseconds. And games load pretty much instantly too.

[Hat @hector_arellano]

Raytracing working, now it's time to include caustics and interactivity, need to optimise performance though #webgpu

[Sebastian Aaltonen @SebAaltonen]

WebGPU performance:

WebGPU (Dawn native): 0.7 ms
MoltenVK: 0.7 ms
Metal: 0.6 ms

791 draw calls in 10 render passes. Our Metal 2.0 backend uses manual resource tracking, unmanaged command buffers, placement heaps and argument buffers.

This is a very good result for WebGPU!

[Michael Hartl @mhartl]

I feel like this may prove to be the most prescient cartoon of the 21st century.

[Mike Turitzin @miketuritzin]

Got the BVH (AABB tree) working with a nice visualization. (The circles and arrows show the hierarchy of the tree.)

This is all CPU-side for now, so next is to ship the BVH to the GPU for accelerating SDF brick baking. It's already in a flat buffer so that is straightforward.

[Acerola @Acerola_t]

Hello everyone, I'm still hard at work on my next video but in the meantime NVIDIA has released a set of new free introductory courses called Learn #OpenUSD !

If you saw my last video and were interested in adopting it for your workflow, you should totally check it out!

[Martin Griffiths @Griff_]

I’m going to hijack Ray’s awesome post here and use it to talk about a particularly challenging engineering problem that we solve in No Man’s Sky, which arises as a direct consequence of our game universe being so astronomically large:

You all probably know about shaders, which are the primary basis for rendering rasterised graphics in games and also might know that large titles can have thousands of shaders, so that they can render a rich set of materials/meshes, particles, shadows, post fx .. and everything you see, in game.

We face a hard and complex task in #NoMansSky when it comes to these sort of shader combinatorics - not only as biome diversity and richness has grown over the years, but also because the exact set of shaders needed to render a planet or anything else that is procedurally generated is not known until it is calculated - nothing in NMS exists until the seeded generation produces the system, planet, ship, station (etc) or anything else that you then see on your screen! This aspect makes “shader loading” in our game more challenging than a lot of titles, where a traditionally designed/static world might allow you to have information about which shaders are going to needed, ahead of time.

One up front thing that we do know is the whole set of shaders that could possibly be needed to render anything in the game .. and right now that number is around 60 thousand. The 60 there is not a typo, but at least we can initially reduce this starting count by 2.5x with some hash reduction - it still leaves us with tens of thousands of shaders, though!

For console versions of NMS this huge shader set can be completely precompiled offline and then streamed in as needed - but on PC shaders have to be compiled and cached by the driver. To deal with such a large set requires quite a lot of extra work, in order to minimise hitching that would happen if a driver has to compile shaders (pipeline states) that it has not encountered before - Nobody on PC likes hitching, and pretty much every gamer has encountered FPS drops that are caused by this problem, across a large number of titles over the last decade, as game rendering complexity has grown.

When running from Steam, there is an embedded shader caching system, (introduced some years back) and this is very helpful for reducing initial load times or long compiles/loads when you update a driver.. but even with this system in place, every time we do a large update (or patch) that has changed a lot of our shaders, we gather data from QA - dozens of hours of real play or smoke-test shader usage, visiting hundreds of planets, dozens of stations, freighters and bases, so that we accurately know and can precompile 99.5% of the most common shaders in use, to minimise this kind of hitching - quite a mad amount of effort to solve something that is never mentioned in patch notes and all just happens behind the scenes!

[Zolden @ZoldenGames]

Playing with my physics engine.

[Antonio Caggiano @Fahien]

I published "Computer Graphics: Follow the light". My talk at Paestum Tech Days, 1st of September 2024. Italian with english subtitles.
https://t.co/lYTThNoPiK

[Keenan Crane @keenanisalive]

Signed distance functions (SDFs) are an important surface representation, which can be directly visualized via the “sphere tracing” algorithm.

At #SIGGRAPH2024 we showed how to sphere trace a whole new class of surfaces, based on *harmonic functions* rather than SDFs. [1/n]

[Sebastian Aaltonen @SebAaltonen]

HypeHype on a 3 year old 99€ Android phone (Mali G57 MP2). Game made by a colleague as a hobby project during the summer.

Frame rate hovers at around 50 fps. Everything I mentioned in my SIGGRAPH talk is enabled: PBR, GTAO, cascaded shadows, post processing...

[A Flock of Meese @meesedev]

Crammed 25 million blocks into 24 MB of RAM and boosted render distance to 12 chunks on the #Gamecube, now surpassing the render distance of Minecraft on Xbox 360, PS3, Wii U, and matches the Switch (docked). Achieved through a month of extensive optimization.
#retrogaming #retrocomputing #indiegamedev #gamedev #Dreamcast

[Angelo Theodorou @encelo]

After thirteen years of development and five years on GitHub, the @nCine2D has reached one thousand stars on GitHub! ⭐
https://t.co/JozAEzmECf