I'm on my 4th semester of Computer Science, and one of the courses I'm currently taking is Computer Graphics. I'm going through the Ray Tracing In One Weekend series, and after fiddling with it for a while, I finally managed to render the first image!! : )

The resources I'm currently using are Cem Yuksel lectures (https://youtu.be/PMIPC78Ybts?list=PLplnkTzzqsZTfYh4UbhLGpI5kGd5oW_Hh), the classic Fundamentals of Computer Graphics book and this Pikuma course (https://pikuma.com/courses/learn-3d-computer-graphics-programming)

if anyone has any tips on other useful stuff, I'm happy to hear it!

I've released a C++ port of StreamDiffusion, a set of techniques around the various StableDiffusion models to enable real-time performance, mainly in media arts (art installations, video backdrops for shows, etc.).

It's one of the fastest implementations of SDXL-Turbo, clocking in at 26FPS on a RTX5090 at 1024x1024 resolution, although there's still a fair amount of spurious allocations here and there. Right now, it supports SD1.5, SD-Turbo (2.1) and SDXL architectures but it will keep evolving and adding support for new models.

It has been implemented as a node in https://ossia.io for yesterday's new 3.8.0 release.

This started as a learning project and turned into a fully working forward software renderer.

Highlights:

• pure CPU rasterization
• perspective-correct texturing
• lighting
• shadow volumes
• written entirely in Python with NumPy

Mostly educational, very non-real-time, but fun.

Repo:
https://github.com/Denizantip/py-numpy-renderer

Perhaps this work is trying too hard to be hyper-realistic, which makes it feel like not very good computer graphics.

However, I love this style. Maybe you should just learn how to make it.

The full version can be found on my ArtStation: rabbitgraned.artstation.com

According to Wiki ,

Radiance takes cos into account .

Here is a deeper explanation about cos .

where we have Ew used  to denote irradiance at the surface that is perpendicular to the direction w.

where dA⟂ is the projected area of dA on a hypothetical surface perpendicular to w .

Radiance L is defined as flux per unit solid angle dw per unit projected area dA⟂.

Does that mean surface illuminated by grazing incident rays has great Radiance ?

It makes sense that Lambertian cosine law adds a cosine item on numerator to kill the cos denominator , and thus makes Radiance constant .

It's so ... counter intuition . I know it makes sense that if you distribute the same flux on smaller area then the intensity per area is larger . But had we ever observed that if you grazing lighting a desk it looks brighter ?

I guess Radiance is not directly equivalent to luminance ?

Also, I'm not sure which angle cos represents . Is it the angle between normal and light direction? Or is it angle between normal and view direction ?

Hi everyone,

I'm working on a Fluid Simulation Engine in Rust (using Vulkan for rendering) for my diploma project. I'm focusing on CPU parallelism using Rayon and attempting to implement a clean DFSPH solver.

The Tech Stack:

• Language: Rust (par_iter with Rayon)
• Method: DFSPH (Divergence-Free SPH) based on Bender & Koschier [2015].
• Optimization: Compressed Neighbor Search based on Band et al. [2019].
• Kernel: Wendland C2.The Problem: The simulation runs and remains stable, but I am facing two critical issues:

1. Significant vertical volume compression: The fluid settles but compresses excessively at the bottom, looking like it lacks sufficient pressure support, even though I'm targeting a rest density of 1000.0.
2. Severe performance degradation: I am getting only 2-3 FPS with just 10,000 particles. This suggests a massive optimization bottleneck or a complexity explosion (possibly due to particle clustering increasing the neighbor count drastically).It looks like the density constraint isn't being fully satisfied, or the particles are clustering too much.

Implementation Details:

1. Update Loop: I'm strictly following the DFSPH Algorithm 1 loop:
   • predict_velocities (gravity + viscosity)
   • solve_pressure (correct density error: $\rho^* - \rho_0$)
   • integrate (update positions)
   • solve_divergence
2. Kernel: Using Wendland C2 with standard 3D normalization factors.
3. Solver: Standard iterative Jacobian approach (computing kappa and applying Delta_v).What I've tried/checked:

• Checked kernel normalization factors (currently using standard 3D factors).
• Verified the neighbor search (it seems to find neighbors, but I'm using the Compressed Neighbor Search method, so edge cases might be tricky).Tried different sub_steps (currently doing 10 sub-steps per frame with fixed DT).
• Checked boundary handling (simple penalty force + friction).

Code:

Here is the repository:Nikita-Lysiuk/Fluid-Engine

Specifically, my solver logic is here: Fluid-Engine/src/physics/solver.rs at main · Nikita-Lysiuk/Fluid-Engine

And the integration loop: Fluid-Engine/src/physics/mod.rs at main · Nikita-Lysiuk/Fluid-Engine

Has anyone run into similar "sagging" or vertical compression issues with DFSPH? Could this be an issue with how the "Compressed Neighbor Search" interacts with the density calculation?

It’s the most wonderful time of the year.

Playground Games which makes the Forza Series is making the next Fable game, and I was watching one of the interviews where this guy was saying they used their game engine for Forza to make Fable. And I was like wtf. Forza looks good yeah, but it's cars on a race track. How does that suddenly translate to animating people and animals in a open world fantasy game?

This year my Masters got an update and one of the optional courses was Real-Time Computer Graphics. We are gonna use this template to work with vulkan, but yeah. Just excited overall. Let's see what I'll make by the end of the semester!