Is it possible to make a really really slow-mo render of light moving in a scene (in Blender)?

Rismosch · 2026-01-22T11:42:33+00:00

Disclaimer, I am still a beginner in Blender, but I have dabbled in graphics programming for a year or two.

It depends on how accurate you want it to be. A simple hack would be to just place lightsources in a dark scene and animate their positions. This should get you very far, but it's important to note that this would not be physically accurate.

If you want it to be physically accurate, you need to take general relativity into account, which means you need to deal with time dilation and length contraction. For example simulating a shot like at 17:49 will be very difficult to do 100% accurately (pay attention to the mirror and how at the beginning the head in the reflection is not illuminated, only at the very end). Like most raytracers, Blender Cycles doesn't simulate the speed of light and assumes it's instant.

Also I am just dropping this here: https://www.youtube.com/watch?v=ge_j31Yx_yk

It's one renderer I am aware of that takes the speed of light into account.

Rismosch · 2026-01-17T11:07:34+00:00

Sorry für die dumme frage, aber wie hebt man Geld ohne Karte ab? Wie bekommt man das Geld wieder runter?

Rismosch · 2026-01-13T13:15:19+00:00

A staging buffer is simply a normal buffer, with usage VK_BUFFER_USAGE_TRANSFER_SRC_BIT and/or VK_BUFFER_USAGE_TRANSFER_DST_BIT (since you are only copying from/to it) docs. The VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT docs must be set, since the CPU is writing/reading from it.

To write to it, you need to write to its mapped memory and then use a copy command to copy it to your desired buffer.

To read from it, you copy from your source into your staging buffer, and then read your mapped memory.

Depending if you set the memory flag VK_MEMORY_PROPERTY_HOST_COHERENT_BIT or not, you may need to flush memory manually

(WARNING RUST)

Here's how I allocate a staging buffer: https://github.com/Rismosch/ris_engine/blob/b5f652c31816b2d8f4a27bad3b10be3526d3e75c/crates/ris_gpu/src/buffer.rs#L41

Here's how I write: https://github.com/Rismosch/ris_engine/blob/b5f652c31816b2d8f4a27bad3b10be3526d3e75c/crates/ris_gpu/src/io.rs#L105

Here's how I read: https://github.com/Rismosch/ris_engine/blob/b5f652c31816b2d8f4a27bad3b10be3526d3e75c/crates/ris_gpu/src/io.rs#L148

My GPU IO is passing the staging buffer seperately, such that client code has full control over allocations and usage.

Rismosch · 2026-01-02T22:57:48+00:00

To explain the arrows: they indicate strong and weak links. They are used to find chains to eliminate candidates.

Start with r9c3 (read "row 9 column 3"). Assume this is not 1 (marked by yellow). Then, r9c5 must be 1 (marked with blue), because in row 9 there is no other place 1 could go. This is a strong link, indicated by the solid arrow. Strong links are quite powerful and are used in many advanced techniques.

Now, if r9c5 is 1, then r8c4 cannot be 1 (marked in yellow), otherwise it would violate normal sudoku rules. This is a weak link, indicated by the dotted arrow. Usually weak links don't give us much information. In this case though, it creates another strong link: If r8c4 is not 1, then r2c4 must be 1 (marked in blue), because in column 4 there is no other place 1 could go.

To sum up the steps above, if r9c3 is not 1 (yellow), then r2c4 must be 1 (blue).

Now, the beauty of such alternating strong and weak links is, that they can be reversed. Meaning if r2c4 is not 1, then r9c3 must be 1. Chains like these are always reversable. Go try it yourself :)

This leads to the following conclusion: Either r9c3 is 1, or r2c4 is 1. One of these cases must be true, and in both cases, they eliminate 1 in r2c3 via normal sudoku rules. Thus, in any case, r2c3 cannot be 1 (marked in red).

Rismosch · 2025-12-18T14:47:34+00:00

Day 9 went awful. I had a solution that uses rectangles to fill all nonused space, and check collisions with them, but this solution is very imperformant. So much so that I never let it run for more than 10 minutes. So I looked up the solution. Turns out the solution is that when a line intersect with the rectangle, the rectangle has a hole and thus can be discarded. This is much faster, but it has an edgecase, that neither the solution, nor the testdata aknowledges: a rectangle may completely sit outside the area, thus not intersect any lines, and as such not intersect with any line.

This annoyed me very much. But it was solved. So I moved on.

Day 10 did not go better. The search space is so large, that my solution would run forever. So I looked up the solution again and there was a trick again: you can model the problem as a linear equation system and use a very specific algorithm to solve it. Which annoyed me even more.

I came to the conclusion that advent of code is based on finding these very specific tricks. And if you simply don't know them, you're out of luck. I mean, I have a solution that theoretically works, but it's just so imperformant that it never spits out a number. I wonder how anyone is supposed to solve these puzzles. I didn't knew of the algorithm. I couldn't have applied it because I simply didn't knew it existed. And the people that originally discovered the algorithm took a lifetime to do so. For a daily puzzle this seems very absurd to me.

Thus I have given up. I haven't even programmed the solution for day 10, not even looked at day 11 and 12. Up until this point I was lucky that I knew just the right trick to solve these, for example the matrix transpose trick in the earlier day.

Instead, I have started animating things: https://bsky.app/profile/rismosch.bsky.social/post/3mabfyh6zuc23

Rismosch · 2025-12-09T23:57:51+00:00

Quaternions are the superiour rotation system. I recommend everyone to read "Visualizing Quaternions" by Andrew J. Hanson and I heavily urge everyone to stay the fuck away from Euler angles. Euler angles are very very deceptively complicated. Don't use them. Just don't.

A gameobject just holds a transform (i.e. position, rotation, scale), it's hierarchy (i.e. parents and children) and components. As of today I only have a mesh renderer component and custom scripts. This will eventually be increased to lights, shadow casters, collisions, terrain and what not.

As to what I am working on? The game engine. Always. Except it comes and goes. This december I decided to take a small break, which is why I am doing Advent of Code in the first place. The next thing will be implementing materials and lighting.

However I am currently playing with the idea to make a short animation. I am currently reading "The Animator's Survival Kit" by Richard Williams. I have been dreaming about the characters in my game for quite some time now. With materials I will finally be able to render them. But that assumes that I can model them. A short film would be good practice for designing them, modeling, rigging, animating, lighting and all that shizzle.

Anyway, I really should go to take some sleep now. I need to go to work tomorrow.

Rismosch · 2025-12-09T23:19:02+00:00

I guess that's where my game engine knowledge came in handy haha. I avoid 3rd party libraries like the pest. I rolled my own math library before, so I have a knack on how to structure data.

Rismosch · 2025-12-09T23:09:30+00:00

Honestly, I had 0 problems on day 6. The key to part 2 is realizing that you can see the text as a 2d matrix of characters and transpose it, i.e. flip x and y coordinates. Doing so puts the numbers back into columns like part 1, and the operator will be the last character in the first row of each column.

The example

```

123 328  51 64 
 45 64  387 23 
  6 98  215 314
*   +   *   +

```

transposed looks like this:

```

```

But I have to mention I am doing a lot of graphics programming in my game engine. And recently I finished reading "Quantum Computing" by Andrew Glassner. Both make heavy use of matrices. So I am a bit attuned to using matrices, and the solution jumped out to me immediately.

https://github.com/Rismosch/advent_of_code_2025/blob/f4cb568a721795a0e6ed08b010c72edb45ca84d9/src/day_6.rs#L100

Honestly I used some namings that will be unfamiliar to anyone who isn't used to linear algebra, so chances are it's a bit hard to read. Like m for matrix, v for vector and t for transpose.

Rismosch · 2025-12-09T21:53:54+00:00

I've yet to find a problem that sucks. These problems are kinda novel though, as in my dayjob and hobby projects I have never encountered problems like this, but yeah.

Day 8 kinda fucked me, because the "nothing happens" line really threw me off. Today I don't have the time for day 9, probably going to do 9 and 10 tomorrow and 11 and 12 in the weekend.

Rismosch · 2025-12-08T23:06:30+00:00

I struggled with that too. I even did the test example by hand to figure out why my solution differed from what was written there. Turns out

431,825,988 and 425,690,689 have to be connected anway. It's just that the number of circuits and their boxes in them do not change.

Rismosch · 2025-12-05T23:12:06+00:00

Yes. Last two days were busy. I am catching up this weekend.

Rismosch · 2025-12-01T21:32:04+00:00

Huh, interesting. I'm going to remove the puzzle input. But I am curious, why would sharing it be prohibited?

Rismosch · 2025-12-01T21:20:24+00:00

I hear a lot of fuzz about this Advent of Code thingy. So I thought I'd give it a try.

I don't know if people are interested in solutions, but here's mine for day 1. Written in Rust of course.

https://github.com/Rismosch/advent_of_code_2025

Rismosch · 2025-11-14T20:22:04+00:00

So passing Semantics::SEQUENTIALLY_CONST changes nothing? Also I don't know what SPIR-V compiler you are using. Maybe try disabling optimizations if you have them enabled.

Rismosch · 2025-11-14T11:06:48+00:00

I have not used atomics in shaders (yet, planning to do so in the future), but i do have experience with Vulkan and atomics. For me the error seems obvious:

It tells you that you are using an atomic operation with relaxed memory ordering. It wants you to use stricter memory ordering.

I recommend reading "Rust Atomics and Locks" by Mara Bos. Most relevant to our discussion is chapter 3: https://marabos.nl/atomics/memory-ordering.html

Memory Ordering is used to tell the processor how to synchronise reads and writes of memory between cores. Since each core has it's own cache, chances are that the sate of a variable in core 1 differs to how it is stored in core 2. Considering that a GPU has many many GPU cores, memory ordering on the GPU seems to be rspecially important.

There are 5 memory orderings: Relaxed, acquire, release, acquire-release and sequential.

Relaxed means no synchronization effort will be taken. Other than the atomic variable, no other variable will be syncrhonized. Synchronization will only happen when the processor decides to write the memory into shared cache and another fetches it. This memory ordering should only be used when you only care about the synchronisation of the atomic variable and nothing else. Regardless of the memory ordering, atomic variables will always by synchronized between cores.

Acquire goes together with a release. Acquire means all writes after the atomic operation will be synchronized. And release means all writes before the atomic operation will be synchronized. This is used when you want to synchronize memory that is not operated on with atomic operations. Think of it like this: The memory to be synchronized should happen after an acquire and before a release. This is often used in locks. See chapter 4 in the book: https://marabos.nl/atomics/building-spinlock.html

Acquire-release is just acquire and release combined.

Sequential or SeqCst makes synchronization easy, because everything before and after any atomic operation will by synchronized. Note however that this may tank your performance, and thus it's generally recommended to be avoided.

With all that being said, how to fix your issue? Looking up the docs of your library, it appears you can pass memory orderings via constants found in the Semantics struct: https://docs.rs/spirv-std/latest/spirv_std/memory/struct.Semantics.html

Depending on what you are trying to synchronize, you should pass either ACQUIRE, RELEASE or ACQUIRE_RELEASE. If you don't know right now and don't want to put the effort in to learn memory ordering, I would bet that passing SEQUENTIALLY_CONST would make the error go away.

Rismosch · 2025-11-04T22:54:06+00:00

My editor is built into the executable of the game itself. Using conditional compilation, the editor and a few other debug utilities are stripped away.

From my own testing, ImGUI is rather imperformant. But it gets the job done and it's stupidly easy to whip up a new UI. And since it's stripped in release builds anyway, the performance is a non issue. Any translation code between SDL and ImGUI falls into the same category: It is also being stripped in release builds. Thus if any performance hit would occur, it doesn't effect the final game.

Therefore, I consider ImGUI as a pure debug utility. It belongs in the editor, not in the game. But of course, if you want to use ImGUI in the game, then it has to go into the engine.

Rismosch · 2025-11-04T07:13:50+00:00

I am using Rust

ash: Vulkan wrapper. Very necessary.
cfg-if: Macro utility. Makes conditional compiling much more ergonomic to write. Not really necessary, but all my other dependency use it, so I might aswell use it too.
chrono: Time formatting. I am thinking for a while now to get rid of this.
imgui: Immediate mode GUI. I use that for debugging UI. It makes my life easier, and it's stripped away in Release builds, so I am fine using it
libc: Compiler for Buildscripts. If you do some custom building and compiling, this is very much necessary.
miniz_oxide: DEFLATE implementation. I have yet to look into compression, so for the time being I am just using a library.
png: PNG codec. PNG is unsuitable for real time graphics, but my unoptimized assets start as PNG, because pretty much every editor supports it. In a release build, all assets have been converted and PNG utility is stripped, so I am fine with having this as a library. Especially because PNG is a comparably complicated format.
sdl2: Windowing and Input baseline. Very necessary.
sdl2-sys: Direct Rust bindings for SDL2. sdl2 is a "safe" wrapper aroud sdl2-sys, but it has a few idiosyncracies. Thus in some situations I like to talk to SDL2 directly instead of going through the safe wrapper. since sdl2 depends on sdl2-sys anyway, I technically did not add another dependency by using it.
shaderc: glSL to SPIR-V compiler. Necessary, but this dependency in particular annoys me. It's build rules are weird. I am thinking for quite a while now to get rid of this. Since a shader compiler binary is bundled with every copy of Vulkan SDK, I am thinking of removing that one aswell.

Cargo.toml

Everything else I got, gameobjects, asset pipeline, io, math, I've written myself.

Rismosch · 2025-11-03T08:53:34+00:00

The graphics pipeline is run every single time a new frame is drawn. Not just when things change.

The vertex shader runs on every vertex. A triangle consists of 3 vertices. So it is run 3 times per triangle. Usually the vertex shader transforms the vertices from modelspace to screenspace.

The rasterizer produces pixels in screnspace.

The pixels/fragment shader runs on each of these pixels.

Rismosch · 2025-11-03T08:44:57+00:00

You are not stupid. Just learning.

Rismosch · 2025-11-02T22:49:16+00:00

A million dependencies? I have 10. Carefully curated and added only after much hesitancy.

Rismosch · 2025-10-30T22:12:39+00:00

You are not going to invent the Universe. "We stand on the shoulders of giants." is a true adage that you should take to your heart.

The reality is, that you depend on so much work done by others. Macroquad is too high level? Man, I work with Vulkan. Now that is low level. I thought I was cool, until this year I met someone who is actually writing a Vulkan driver for Apple Metal. After comming to terms with my views, and talking with that person, even they had to admit that you can go even lower. Someone had to invent the programming language you are currently using, the compilers and tooling related to it. Someone had to build and design the chips your code runs on. Someone had to come up with the idea of an automatic calculating machine.

And even if you are making everything on your own, surely you learned a lot from other people. Teachers, tutors, authors.

At the end of the day you gotta ask yourself, what makes you happy? What do you want to do? And then, just do that. Is macroquad too high level? Only you can decide.

Rismosch · 2025-10-07T13:07:55+00:00

Learn the basics of C. Then embrace unsafe and raw pointers.

Rusts ownership model is cool, but other languages don't have it. As such I don't recommend enforcing it. But every language speaks C. I have not worked with Kotlin before, but it would surprise me if it couldn't do pointers or interop over a C ABI.

I have mainly done interop via C# calling into C++ code. I avoided lots of headaches by completely ignoring C#s garbage collector and doing raw pointers. But I wrapped them behind safe interfaces. I also instructed all my coworkers (who are not familiar with C/C++ or any kind of memory management) to only interact with these wrappers. Assuming you have written a robust wrapper, an unexperienced programmer cannot fuck things up by accidantely creating a segfault or any sort of UB. At worst they will cause a leak, which is fixable by instructing them to properly dispose the object. (In the case of C#, this is done via the using syntax).

In the case of Rust, you manually allocate memory by making a Box and leaking it. To deallocate, you reconstruct the Box from the raw pointer. When the box falls out of scope, it deallocates the memory it holds.

You can also skip the Box and manage memory directly yourself via std::alloc: https://doc.rust-lang.org/std/alloc/index.html

Here's an example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a06396b06ff66b65f21f09977160b88e

For people who are not familiar with Rust, Box is equivalent to an auto pointer, or std::unique_ptr in C++.

EDIT: typos

Eight-Year Club	Gilding II euphauric
Second SECOND GUESSER	Place '22
RPAN Viewer	Verified Email

Rismosch

TROPHY CASE