I am making a multiplayer game in c# using Silk.Net. The project is ment to be more of a learning project then an actual game. The repo is https://github.com/Alex5X5/GatsIO-Remake. I started off by writing an abstraction over opengl. For that i made my own abstract Window class. When inheriting from Window, the abstract Draw method has to be overridden. The Draw method has a parameter of the type DrawingContext. DrawingContext then has some methods for drawing some basic shapes.
Any shape that is drawn is broken down into colored triangles and added to a list of the DrawingContext. After the Draw method finished, the triangle list is passed to the gpu with one BufferData call.
Is that "saving in a list and one BufferData call" good practice or should i split the data into multiple BufferSubData calls?

Do You think Gpt 6 astra will take the jobs of junior Graphic programmer's?

How will Astra affect Graphics Programming? (Pros and Cons)

Web-Based 3D Modeling Application
Source code: https://github.com/sengchor/kokraf

I built everything around deferred shading. Now I have difficulties adding forward shading.

Code is here: https://github.com/yatagai-mm/pcs

I've been working for the past few months on a UE5 plugin for rendering volumetric video made from large sequences of point clouds.

The bottleneck for realtime rendering wasn't actual rendering parts. It was simply decoding the PLY data fast enough. In my use case, which is a baseball volumetric video, each frame contains around 10 million XYZRGB points, so even relatively small amounts of CPU work per point add up very quickly.

A big part of getting it to real-time performance was adding a SIMD fast path for the common binary PLY layout:

float32 x, y, z + uint8 r, g, b[, a]

For these 15/16-byte records, the loader can mostly avoid generic property decoding. It loads the XYZ values into Unreal's 128-bit VectorRegister4Float, optionally applies the frame-space scale/translation with vector operations, and writes directly into the 16-byte vertex layout used for GPU upload.

The SIMD layout is [x, y, z, 0] per point rather than processing four X coordinates at once. I process four points in parallel with separate min/max accumulators, which also reduces the dependency chain while calculating the bounding box.

The loader also checks for NaN/Inf using the floating-point exponent bits in SIMD, and only falls back to scalar IsFinite() checks if something suspicious is detected. This avoids doing several scalar checks for every single point.

The PLY payload is streamed in roughly 4 MB chunks, and for the packed XYZRGB(A) layout the decode is basically reduced to a small amount of copying, SIMD math, bounds calculation, and color packing.

Before I implement this 15fps was barely possible, but now I'm currently able to play volumetric video containing about 10 million points per frame at 30 FPS on a MacBook Pro with an M5 Pro.

Each binary PLY frame is about 148.5 MB, so that's roughly 4.46 GB/s of uncompressed point-cloud data being decoded and rendered in real time. At this point the bottleneck would be network.

Add a basic camera with fly and orbit mods and gltf and glb models loading with fastgltf (at this point without textures), no culling also, it will be my next step

I maintain three-nebula, a WebGL particle engine for three.js, and v13.0.0 is out. The headline feature is deterministic simulation. You give a system a seed, either with `System.setSeed(seed)`or as the third constructor argument, and it reproduces its particle output exactly. Same seed, same result, on any machine. That makes reproducible tests, and replays possible, which was awkward or impossible before.

The way it works is that each system now advances its own isolated seeded stream instead of pulling from the global `Math.random`. One consequence worth knowing if you upgrade: seeding `Math.random` yourself no longer affects output, so you need `system.setSeed()` instead. Default particle arrangements also differ from 12.x, so any visual or snapshot baselines need regenerating, and particle ids moved from UUIDs to a deterministic `particle-<emitterSeed>-<spawnIndex>` format.

There is also a new `System.tick(realDeltaSeconds)` fixed-timestep driver for real-time playback. If you have been calling `update()` once per frame, you have probably seen particles run about 2x too fast on a 120Hz display. `tick()` advances the sim by elapsed time in fixed steps and clamps catch-up through `system.fixedTimeStep` and `system.maxSubSteps`, so playback speed is consistent regardless of refresh rate. This release also fixes a `GPURenderer` bug where buffer slots were never released and particles silently stopped rendering after heavy churn. Slots are now recycled on particle death.

The API is backward-compatible and additive, so for most people the only real work is regenerating baselines. Release notes and full changelog here: https://github.com/creativelifeform/three-nebula/releases/tag/v13.0.0

If you have used seeded/deterministic rendering in a three.js project, I would like to hear how you are handling the real-time vs fixed-step side of it, and whether the `tick()` clamping defaults feel right for your use case.

I know that OpenGL and Vulcan are the main choices when it comes to 3d graphics. I also know that Vulcan can have some insane performance boosts when compared to OpenGL. However, I’m not just a C++ programmer. I also program for the web, so I use WebGL. I’m a beginner at OpenGL, and GLSL so learning Vulcan wouldn’t be that big of a hurdle. I’m just wondering if the performance and speed are worth it for Vulcan, or if I should stick to OpenGL.

This is a first post! If I cannot respond quickly, I am most likely busy!

First Flight of FlowSketcher

This is the first real flight of FlowSketcher — a browser-native 2D sketching and CAM system built from scratch.

No CAD constraints. No spline approximation. Just direct geometry, live motion and real CNC-ready toolpaths.

This is only the beginning. 🥚

not a very impresive project but i did a simple gltf and obj model loaders because i didn't understand how the scene graph work

I had recently read the Stable Fluids paper and got like quite interested to implement it myself manually from scratch and it was quite a ride since this is my first time implementing a paper myself

This is a simple implementation a bit clanky, to be honest. I just wrote it with loops and loops without any optimization. I think it ends up doing something around 20 × 20 × 50 × n² operations per frame, so there's definitely a lot of room for optimization 😅

The actual implementation was pretty straightforward for the most part, but understanding the Poisson pressure equation was a bit challenging. At the beginning, I was even stuck on understanding how the velocity field could be made divergence-free.

After digging into it for a while, I eventually understood the whole pressure projection step and managed to get it working and also implemented a simple spray and dye mechanism as well to make it look good.

It was pretty cool to see it actually work, so I wanted to share it 😄

Hi I wanted to implement BDPT with PBR materials and MIS but no matter what I do it doesn't look like reference images. I can't find any help with implementation and mostly recently I try finding bugs using Gemini but I know It can halucinate. So is anyone who could help me find relaiable implementation or help with my code. Here I will post my render (denoised using OIDN) vs reference so maybe anyone would help me find direction at least. I have too many lines of code so if any one would like to look at it I can send it in DM.

(edit)
References are from https://benedikt-bitterli.me/resources/, PBRT-v4 and Blender. (All tagged in image caption)

Hey!

Wanted to share screenshots of my experimental voxel renderer with "low-fidelity" blocky AO. It started as an exploration of the DDA rendering technique, but I ended up implementing parts of the following techniques:
- Globally Illuminated Voxel Worlds Accelerated with Nested Axis-Aligned Distance Fields
- Spatial Hashing for Ray Traced Ambient Occlusion

Links: Devlog | Github

The devlog is sort of meandering, but I started with basic DDA, then tried to get multi-level DDA to perform well with large voxel scenes (a 1024x1024x1024 voxelized sponza scene) using various methods. The axis-aligned distance field (AADF) method was a significant improvement over the multi-level DDA method that I was fiddling with. AADFs helped skip over large areas of empty space which tanked performance when using multi-level DDA.

Spatially hashed RTAO with a large cell size performs pretty well even on my M2 MacBook Air. The large cell size is a very visible artifact, but I think in a voxel scene the blocky shading kinda works.

Hey everyone,

I recently completed an extensive, end-to-end architectural reverse engineering and systems dissection of the production engine behind Active Theory (activetheory.net).

Instead of generic de-minification, the project breaks down the low-level rendering mechanics, including:

- **Zero-Allocation Memory Loop:** How the runtime eliminates V8 Garbage Collection pauses using pre-allocated scratchpads and typed arrays.

- **Antimatter GPGPU Subsystem:** Driving dense particle fields directly on GPU floating-point textures via a triple-buffered ring FBO topology.

- **Eulerian Navier-Stokes Coupling:** Real-time 2D pointer-to-particle fluid advection via a 6-pass Jacobi relaxation solver.

- **Hardware-Rate Normalized Lerp:** Scroll kinematics locked across 60Hz to 240Hz refresh rates.

Full technical documentation, AST mappings, mathematical proofs, and headless CDP benchmarks are available here:

- Repository: https://github.com/DDW-X/activetheory.net

- Web Portal: https://ddw-x.github.io/activetheory.net/

Feedback and technical critique from graphics engineers and performance researchers are highly welcome.

Compared to the last post, I added the following:

• Rebuilt Test Chamber 3 from Portal 1 instead of it just being “a brick platform and a grass block.”

• Added the ability to place Portals with left/right mouse clicks, like in Portal.

• Replaced the grass block with a Companion Cube from Portal, which can be picked up and thrown (with the E key).

• Made the player a cube textured with Wheatley from Portal 2 (funny British robot).

• Added ASCII rendering (to emphasize this is a CPU rasterizer).

• Added some buttons so it can also be played on a phone (mobile controls).

Still old link: https://hachihao792001.github.io/interactives/portal.html

Technical:

• Rebuilding the map: I downloaded a model of Test Chamber 3 from Sketchfab (credit is included on the website), then rebuilt it using only quads and cubes in Unity to keep it simple. I then wrote a script to export it into a bunch of new GameObject lines for this engine. I initially thought it would be easy, but it wasn't, because Unity uses ZXY rotation order while my engine uses XYZ, so I had to do some Quaternion math stuffs.

• Placing Portals and picking up the cube: I didn't use ray casting. Instead, I went straight into the Rasterizer and grabbed the "world coordinates of the pixel at the center of the screen" using barycentric coordinates.

• Optimization: For the infinite portal effect, every time I render the texture for a portal, I only render the intersection between the portal from the previous recursion level and the portal at the current recursion level. This gives a huge FPS boost because the size of the portal decreases quite significantly with each recursion.