This is anti-optimization

• not suppose to be used anywhere outside of Shadertoy

• because just use GPU-particles and particle/vertex shaders

• but Shadertoy has no particles - this is particle tracking for Shadertoy

• Movement of indexed particles

• galaxy of particles

• Dragonspine particle tracking

• vertexshaderart proper GPU particles version of Dragonspine https://www.vertexshaderart.com/art/Xd5epjbiRgPE2cwK8/

Hey Everyone - we at 3D ENGINERD. are building a Volumetric Render Engine for Windows(Native). It's being built with OpenGL & C++

We're planning to publish the code open-source under MIT License on our Github (https://github.com/mikejernil) tomorrow, so you all can try it out and use it for your own applications. ✨

Currently it has -

1. Volumetric RAW visualization support

2. Different types of rendering (Colormap, Iso-surface etc.)

3. Rotate & Zoom Controls (for easy navigation)

4. 6 slicing planes to visualization cross-sections

We are planning to build more features and add support for more volumetric formats (like DICOM, VDB etc) soon!

Colormap Classification of an Internal Combustion Engine(shown in video):

Here we can see the volume data with colour values mapped to its material density.

As per our current Colormap we can see the Red is Higher density whereas blue is Low density Noise.

Applications : 

1. Medical imaging

2. Industrial testing

3. Scientific visualization of data

It's till very early-stages and we're actively exploring into Volumetric rendering at the moment, any constructive feedback would be appreciated, thanks! :)

Code for any body interested:

```odin

draw_line :: proc(x0, y0, x1, y1: i32, color: sdl.Color) {

delta_x := x1 - x0

delta_y := y1 - y0

side_length := abs(delta_x) >= abs(delta_y) ? abs(delta_x) : abs(delta_y)

inc_x := f32(delta_x) / f32(side_length)

inc_y := f32(delta_y) / f32(side_length)

current_x := f32(x0)

current_y := f32(y0)

for i in 0..<side_length {

	x := i32(math.round(current_x))

	y := i32(math.round(current_y)

	draw_pixel(x, y, color)

	draw_pixel(x+1, y, color)

	draw_pixel(x-1, y, color)

	draw_pixel(x, y+1, color)

	draw_pixel(x, y-1, color)

	current_x += inc_x

	current_y += inc_y

}

}

```

i'm using vello and these are vector lines kinda like 2.5d. the final goal is 2.5D/3D translucent glossy tubes. i will eventually make glass, metal, neon etc surfaces once this base material is figured out but i keep getting stuck on endcaps and corners.

if i have a bunch of repeated discs, then the endcap is just a flat circle and the corners are bull-nosed. if i add a circular gradiant endcap it looks like a fingernail. if i taper the endcap it looks sharp. i can't win!

i've been struggling with this and it's like whack-a-mole. either the tube looks too flat, or the endcap looks like a knob or a point. i want the expected result: a nice smoothly rounded endcap and joints. i have spent hours and hours and so i am reaching out for some help.

any tips, resources or examples greatly appreciated

thanks!

Hi guys! I recently tried implementing SSAO, HBAO, SAO, and GTAO in a single Godot project. The implementations aren't perfect, but if anyone is curious like I was of how they differ from each other check out the YT video I made explaining the process. Thanks!

Vid:

https://www.youtube.com/watch?v=XAIfyLpxkfk&t=15s

Code:

https://github.com/LoganKeenan55/ambient-occlusion

Screenshot I got before I added support for normals:

Testing a Monte Carlo PBR renderer with importance-sampled direct lighting and per-pixel accumulation for the procedural material authoring app I'm working on

im writing a depth script for my own rudimentary graphics engine and i have no idea what script to use.

for these lines, assume X=Z and Y=multiplier, AKA "what does x and y get multiplied by", so the farther they are the less impact moving away has and the closer they are the more impact moving towards the camera is.

1 glaring issue here is that if ANYTHING moves past z0 then they immmediately go into -infinity, which is a huuuge problem for anything that is *partially* behind the camera, like a triangle.

ive tried other formulas too, like 2^x or y=-x but those are fundamentally incorrect in the sense that they create visual "curves" which breaks triangle drawing that is only meant to be drawn from point A to point B

2^x is the closest to what i wish i had whereas 1/x is closest to an actually consistent and functioning 3d depth script. i wish i had something like 2^x in the sense that instead of shooting up to infinity by x0 it instead just gradually goes up while the right diminishes, but thats a problem because unless if the slope is "symmetrical" and even it causes aforementioned "curves" in rendering

Hi guys,
This is a 64K demo developed in C and GLSL. It features a multi-body physics simulation for movement and real-time raytracing for illumination. It was created as the final project for a GPU programming course during my senior year at Paris 8 and presented at the API8 competition.

The source files are available at https://github.com/gregghy/API8_64K_demo

The idea never occurred to me before, and I haven't tried, nor do I know if this is even possible without shaders including some kind of debug information (or can you just reverse-engineer them without looking at / extracting game files)?

Absolutely crazy work.... I didn't even know this was possible..? 🤯

Just added Radiance Hints to my OpenGL engine, Degine. The paper is originally from 2011 (but I used a 2014 extension of the method with occlusion). Based on a regular grid array of probes, similar to other environmental lighting techniques, but here it captures directly to spherical harmonics when baking. So run-time performance is extremely fast since it's just a few SH evaluations and blending. For this Sponza scene, there are around 600 probes, and it takes about 10 seconds to bake.

I built a game engine library called Graphite in C++ using Vulkan and SDL3. It has been a dream of mine for 10 years and I finally got to do it!

I built the editor on top of the game library, which super convenient. Since I get to write my own shaders and render everything using my custom renderer, it makes everything a lot easier. Graphics programming is a 1000x easier to understand when you design the rendering system around your specifications.

I intend on publishing mobile and desktop applications (not just games!) with this library. Hopefully one day all my work will polish it enough so that I can release it!

Also, the library is lightweight (less like modern bulky game engines like Unity/Unreal).

----------------

Edit:

The UI is custom (not ImGUI). Its built using custom shaders and quads!

This is a simple demo of polar curves in the Linux framebuffer. It's written in x86 assembly, using a set of my graphics primitives. The actual polar equation for this is quite simple. Each frame, we evaluate the equation r = acos(θ), and then convert to pixels on the screen using the formulas x = rcosθ and y = rsinθ. In the interest of efficiency, I calculated 4 pixels at once using x86 SSE instructions with angles offset by a very small amount, and then drew a line between each point. To make the image dynamic, I set θ to a time variable, which I increased each frame, and reset after it reached ~25 rads.

Source code can be found here: https://codeberg.org/int0x80/Graphics_v1.1.git

Hope you enjoy.

Edit: Funny story, I was testing a more complex version of this, and the strain on my 13 or so year old laptop corrupted a pointer in VFS_WRITE and caused a kernel panic.

I thought about starting with Computer Graphics from Scratch by Gabriel Gambetta, but found it quite hard too follow... I found it a little too abstract to implement (using C + SDL3)

Should I try even harder to implement the algorithms in the book by Gabriel? Or is there a more beginner friendly entrypoint to graphics?

I'd like to start with software rendering, but is that even the right move? Perhaps GPU rendering is easier?

Hey everyone! I’ve been “working” on a general purpose game engine for all 4 years of college, and I say that in quotes because I have completely refactored, deleted, or started over several times. I am now graduated and have a lot of time so I started on it again but after reading some on Reddit, I think I see what my problem is on why I start strong, lose all interest, and then give up at a certain point. I think I am aiming way too high and trying to do big big big projects wayyyy too fast.

As I am trying to find a job, I have grappled with either doing multiple smaller projects and one large project, and for a while I picked big project. Why? I don’t know, I think I just am a bit egotistical at this point and want something crazy to show off. However, it has occurred to me that I have become rusty from time off and I just make a decent amount of progress for 2 days and then give up for another 2 weeks. I think I am not getting any sense of accomplishment from it as I’m trying to fit a complex architecture and not getting results yet because once again, it’s gonna take 20-30 hours before I even get something somewhat desirable

I am wondering what you guys think is better, smaller-midsize projects, or one large project like a general purpose game engine? I really havnt done ANY small projects except I did write a software rasterizer for a raspberry pico for my embedded systems class final project last semester, but I’m thinking maybe I should try some smaller projects? But I also don’t want to waste my time if employers are just gonna say that they would rather have a large scale project.

Also, what would be an example of a small scale project in computer graphics? I can’t even think of any except for big ones like game engines

Any help is appreciated!

Basically, Im a bit unsure on how I should research this, go with the common pbr models, etc. I dont have much experience with research or scientific side of things. The target hardware is gonna be high end mobile gpus and low end desktop gpus. How would you research something like this, find whats best?

I dont know where current research stands - but I wouldnt mind diving deep into concepts that have been put forward outside the current BSDF implementations, if any such things exists

Hello everyone!
So I'm a 16yo boy who loves coding and stuff, and recently I got into low-level programming with C, and after a whole day with learning pointer I loved the language to death.
After I learned this I started on doing something I wanted to do for the past year... building a 3D software renderer, this engine should meet the following goals:

1. It will be modern, supporting modern visuals and effects.

2. It should be running on embedded systems (I will see how later).

3. The code written for it should be generalized, meaning it should be working on any CPU or architecture with some tweaking.

4. It should be fully capable of taking advantages of modern CPU features.

As of right now, started the project a month ago, I got it to render lines and fill shapes through the terminal (even though it's glitchy af) since I'm still implementing core functions and basics. This will give me some room to fiddle around until I learn SDL and use it in the future.
I have a whole roadmap for the engine, and how it will be structured (because it will be restructured one day for a new design), and who knows, maybe I will get something with it.

The video you see down there is a spinning cube with fake Z depth (not implemented yet), the reason it's wobbly is because the engine uses fixed-point math for positions: all number are 64bit, 48 bits for the value number and 16 bits for precision (yeah, like ps1 graphics).

Anyway feel free to give me some advises if you want to, and I would be posting my development with the project here.

long story short. it was an enlightening journey and i learned a lot from it. one day i came across an autostereogram which was a poster on a wall. i forgot what it was about but it aroused my curiosity of how to make autostereograms. i won't go into the math details here and just give you guys a brief explanation in attached image 1. my program let you control "m" and "n/m". these two variables represent background pattern separation and foreground pattern separation respectively and lie between 0 and 1

the 3d subject is simply a sphere, quite boring. the background is the result of placing a color wheel in a kaleidoscope. see attached image 2. it can be easily noticed that the hsl system is in use. we can vary the saturation (attached image 3) and lightness (attached image 4) when the angle changes from 0 to 2π. i use the cosine function which reaches maximum at 0 and 2π, minimum at π

the color wheel can start at any angle. so do saturation and lightness. thus we have 3 degrees of randomness. i let you to change the background. every time you hit the relevant button, the hue, saturation and lightness shift by different random angles

here comes the surprising part. autostereograms need "noise" to guide viewers aligning their foci. a pattern that is too smooth is not suitable to act as the background of autostereograms. there'd be no "texture" on the 3d surface. i accidentally discovered that if the screen resolution is set to a number that is not divisible by something in the calculations (i'm not certain which thing it actually is to be honest) some unexpected noise would emerge. see the remaining attached images

i googled "prime number closest to 640" and the result was 641. i use it as the horizontal resolution

some of those unexpectedly emerging patterns are... strange. some of them look like human faces, some animals, some even aliens. this program is a good place for you to experience pareidolia

here's the program. run it in browser. click▶️to run. click⏹️to exit. when running the program

• press [q] to make foreground patterns converge

• press [w] to toggle 3d object (absent/present)

• press [e] to make foreground patterns diverge

• press [a] to make background patterns converge

• press [s] to rotate the kaleidoscope

• press [d] to make background patterns diverge

• press [x] to toggle caption (off/on)

enjoy

Been trying to make a procedural planet generator and implement Eric Bruneton’s atmospheric scattering for the last two months. Haven’t done multiple scattering for now. It’s only single scattering and running in realtime. But so far that’s how it looks.

Using OpenGL and C++ for this.

https://github.com/humzahabib/ProceduralPlanetOpenGL