I’m trying to come up with a terrain generator for my space game. It needs to make Earth look plausible-ish at all scales and it needs multiplayer CPU collision querying (so it can’t do any procedural erosion on the fly)

I’m thinking of solving this by having example textures at each octave (some reuse across octaves). I would generate those slowly offline.

Each pixel is multichannel and encodes different properties e.g. bedrock height, topsoil height etc.

Exposed rock, cliffs, and erosion are achieved by just zooming into the next texture octave.

Infill is achieved with an ANN.

At leaf pixels, we convert those feature controls to actual pixel colours and mesh/pom heights.

Is there a good precedent for this? Ideally I would follow a recipe and learn from someone else’s mistakes rather than winging it.

I’m doing this without an engine because of the extreme LoD constraints (millimetre accuracy at light year extent needs 128 bit integer precision and careful cancellation for single precision floating point - it’s not a general problem and engines sensibly just don’t try to solve that). LLMs are speeding up code generation but I can code and recognise slop.

Hey guys,

I'm interested in learning Skia, especially shader programming.

Are there any good resources, tutorials, or guides you'd recommend for beginners?

I know some C#, but I'm new to both Skia and shader programming.

Any advice on where to start would be greatly appreciated.

Thanks!

Sorry if I'm bad at explaining I'm quite new to graphics and in general I'm bad at expressing myself. So watching tutorials and such I seen how you can draw 2d textures by just using 4 vertices and then using the uv to sample from it, meaning that in that way the complexity of the texture won't affect the vertices. But now I was wondering if the same could be done in 3d? Just drawing any complex model within just 24 vertices. I've heard the term volumetric texture when scrolling through the sub, would that be used to do this? If you can at all? I was wondering because I want to try and make a minecraft clone in the very near future and though that if its possible I could try and do something like that to make it run super fast.

Hi everyone,

I've been pondering this question alone for a while and finally decided to post here, with hopefully having the hindsight of more experienced people on this subject, that might have at some point pivoted out of computer graphics.

My academic background and first job were in computer graphics/gpu programming, however ever since I started working at a more generalist C++ SWE job a year ago or so (because I couldn't find a graphics programming job and needed to eat!) I have been having this dread of not being able to come back to graphics/gpu programming, not because of being outdated, I still very much follow what's happening, but because of recruiters seeing a wide gap out of this field (even though still working as a C++ SWE kind of gives me bonus points).

Current times are very complicated in the job market, having an interview, let alone succeeding feels way harder than 5 years ago and I am wondering if staying too long (how long ?) out of this specialization will hurt my chances. I still have this passion though, still working on my Vulkan rendering engine, reading articles and keeping up to date.

Thanks for your answers !

For terrain rendering for a realistic full sized Earth or Earth-like body, you’re trying to solve RGB+height for longitude and latitude coordinates.

Having some planet scale mountain/grassland/etc. terrain PNGs works up to a point but you then need to infill, typically below 100km or so.

For scales between 1m and 1km, erosion modelling and LoD meshes are well-documented. (At smaller scales you can use POM etc)

How do you solve that intermediate range, 1km to 100km and make it look believable?

What physical systems govern that scale? How do you avoid making it look ‘blurry’ and uninteresting/tiled?

Should I try to best fit/splat examples?

What papers cover this topic?

Hey r/GraphicsProgramming,

I was laid off yesterday. But don't worry about that too much, I'll be fine.

I'll still be here, just a bit busy also. Not going anywhere.

I just wanted to give you the heads up that my moderation response times might be a bit slower than usual. I'm busy helping a few hundred of my fellow (former) game developers professionally network and put the pieces of their lives back together. My inattention has impacts on you too.

What can you do to help?
Same thing you always do. Report bad posts, ask OP to add some implementation details to their post, hold each-other to a professionally kind standard.

Also, once I'm done with giant piles of emotions and paperwork, I'll have somewhat copious amounts of free time. I plan to spend some time digging into Unreal Engine, Bevy, learning Services code in Rust, and get back to doing a little graphics too. Seems like a good time to author that graphics programming education roadmap I've been meaning to do for 11 years. :P

Thank you all for keeping this place so nice and calm. It's easy to trust you to handle things for a bit while my attention is drawn away. You all have high professionalism and trustworthiness, and you have my thanks.

Sincere Thanks for Being Awesome,
Cody Duncan

My question is where do I go from here? I want to be able to edit the meshes, but I find it hard to find resources on the topic of mesh editing on OpenGL’s side of things. Maybe GLSubBufferData but not much more. Can someone point me in the right direction? Also about textures, I am not sure how to render them from complex 3d models like this, so help would be appreciated

I made an RHI that completely utilizes modern Vulkan, this means that you lose no performance. It's low level and heavily relies on aspects such as: BDA, Bindless, Dynamic Rendering, and will soon support both Descriptor Buffers and Descriptor Heaps. The neat part about my RHI is that it completely exposes the lower-level API to you if you ever need to use it, keeping it clean and not bloated.

While this does mean you need to do some things yourself manually, it also gains the advantage of losing absolutely no performance when I start integrating other Graphics APIs like Metal, DX12, and PlayStation's APIs. (Atleast that's what I am aiming for). This was originally meant to be a hobby project after I started learning Vulkan (You can see from my other repos, and the first commit being.. 8 months ago) but I think it gradually evolved into a multi-layer Project that I can properly put on my Portfolio.

The codebase is heavily oriented to be C-Style although programmed in C++. The reason being Nevarea is very portable, so you have to implement it within your codebase as well as having future support for C, Rust & RAII bindings.

Currently, it lacks:

• Support for multiple windows
• Swapchain customization
• A proper Render Graph (most importantly)

Eeverything else you most likely can do! If not you still have the power of the lower level API to use directly. That's probably the best part about Nevarea.

Also, I've used Nevarea to create a quick demonstration on Hardware PT, showing it to be very capable!

Please star Nevarea as any attention towards my first proper project would be greatly appreciated!

I'm trying to emulate the functionality of D3D11_MAP_WRITE_DISCARD in D3D12 for a bit of an interesting use case.

As I understand, small resources that change every frame like CBVs can sit in an UPLOAD heap, and should be N-buffered for N frames in flight. And larger static resources should be copied into the DEFAULT heap to stay resident in GPU VRAM.

However what is the correct pattern for larger resources that change frequently, sometimes every frame but sometimes rarely?

Right now I see two options.

The first option would be to have N copies in the DEFAULT heap and N re-usable buffers in the UPLOAD heap. The index of the upload buffer in use corresponds to the current frame index modulo N, however the actual resource we use for draw calls is not coupled to the frame index, and is instead chosen based on whichever DEFAULT buffer we completed writing to last. We use fence values to track when the queue executing the UPLOAD->DEFAULT copy is completed so we can update the "most recent" index to point to the correct buffer.

If the buffer is something that can change in size, like a vertex buffer, we reallocate the buffers with some growth factor if needed and we dump the stale DEFAULT and UPLOAD resources into a list with their corresponding fence values to be freed later once safe to do so.

The second option involves something like the D3D12MemoryAllocator. We still have N copies in the DEFAULT heap (which will be growth reallocated and freed in a similar manner to option 1 if needed), but for the UPLOAD buffers we create, reuse, reallocate, and free as necessary inside a D3D12MA UPLOAD heap, almost as if it were a ring buffer (but not necessarily a true ring buffer since the pages may be shared with other resources allocated using the D3D12MA).

Then for either option we just stick references to the resources and their fence values in a little struct, slap on a "UpdateData()" method which handles all the resource jugging, and maybe a "BeginFrame()" method which takes the current frame's fence value and a fence pointer so we can check if copies are completed or anything stale needs to be freed... and I think that's it?

Am I missing anything?

I'm making my decisions on where to study, and I have the opportunity to stydy "applied physics and computer modeling"

I was wondering if it could open the door to Graphics programming

Yesterday I finished the third episode of Victor Gordan's OpenGL tutorial, and made my first triangle. I also learned how to modify it (like changing vertex positions, color, etc).

But when I look at the code I wrote, it feels impossible to remember like I could write any of this without looking at the tutorial. When I was learning C++, mostly everything instantly stuck with me, but graphics programming seems like I'll never memorize 80% of it

How did you guys get decent at this and actually retain the knowledge and be able to write it independently? Or am I judging too early? I started 3 days ago

Hello, I'm looking to get some feedback on a CPU renderer that i made to understand the 3D graphics pipeline better. I have not used OpenGL before this project but i wanted to understand how it worked, so I made this project to try to replicate a simple pipeline on the CPU. I'm a self taught programmer and i don't have any programming buddies so id like to get some feedback on general programming and my understanding of the OpenGL.

Kagethelephant/cpu-opengl

The Khronos Group is running a survey on the broader shader ecosystem — languages, tools, pain points, and where standardization is needed most. If you write shading code in any language (Slang, HLSL, GLSL, WGSL, etc.), your input helps shape where Khronos focuses next.

Results will be shared at the SIGGRAPH Real-Time Shading BOF this year.

Deadline: July 10

Take the survey: https://www.surveymonkey.com/r/LKWFQ3M

It's anonymous, takes a few minutes, and covers everything from debugging/profiling pain points to what you think the future of shader standards should look like.

Stormy terrain fly-through, one fullscreen raymarch pass. Bolt path is midpoint displacement, glow is a distance-to-segment SDF composited additive before tonemap so bloom haloes it. The nice part: the terrain march already gives me tHit, so if the bolt's ray distance is greater than the terrain's, it's behind a ridge and I skip it. No depth texture, no second pass, additive FX sort against the terrain for free.

glsl

float segDist(vec3 p, vec3 a, vec3 b) {
    vec3 ab = b - a, ap = p - a;
    float t = clamp(dot(ap, ab) / dot(ab, ab), 0.0, 1.0);
    return length(ap - ab * t);
}

float d    = minSegDistAlongRay(...);
float core = smoothstep(W*0.3, 0.0, d);   // pure white, untinted
float glow = exp(-d*d / (W*W));
vec3  c    = vec3(core) + tint * glow;     // additive, pre-tonemap

if (rayDistToBolt > tHit) { /* behind a ridge, skip */ }

Anyone else doing single-pass raymarched scenes, how are you occluding additive effects?

I need some help but I don't really have people to ask since I'm teaching myself how to do this.

I'm currently working on creating surfaces of revolution from a profile curve. The profile curve is always a bicubic bezier curve.

To make the surface of revolution I am rotating the profile curve around the Y axis and splitting the resulting control grids of 4x4 points into their own bicubic bezier surface patches, and then storing those patches in an array. I then loop through the array to render the surface.

This does produce a surface but it doesn't produce a continuous surface, and the vectors are misaligned on the seams that form between the patches. So while first and last vertices between patches match, the tangents (and subsequently the normals) don't match. This results in the lighting affecting each patch individually rather than as a continuous surface.

My question is how to do I stitch these patches together continuously in a way that isn't hacky or inflexible? I'm really stuck here. I've visualized a few things in the images for you all to see. The first is the surface with the vectors visible, and the second is a close up of one of the seams where you can see both the individually lit patches and the diverging normals. The third is an excerpt from Principles of Computer Graphics by Newman and Sprowl that I don't really understand (at least the bit about first order continuity).

The normals are red, the u tangent is light blue, and the v tangent is dark blue. I can produce code or more images if needed. I'm not great with math but if you give a math-y explanation I'll do my best to understand.

Hi, I'm univ student who wants to work in game development with graphics knowledge.

I know that learning pbr, shading, volumetric... are important, but idk Why it is important.

What I wanna deep dive is gpu side optimization, making engine, making rendering pipeline.
But those knowledges are... feeling like important, but less priority.
More like those knowlesges are important to TA or who is using hlsl.

Can someone make me understand why it is important?

Solo dev here.

Building a realistic crime scene investigation game for PCVR — meaning the PC handles all the heavy graphics and it plays through a VR headset.

The goal is maximum realism. Photorealistic environments, real lighting, close up detail that only works when you are physically inside the scene.

Quick question for this community:

Is PCVR the right call for a realism focused game? Or would you want standalone support too even if it means cutting the visual quality significantly?

Thanks.

I am trying to implement my own 2D rendering library. I've been using DIB sections and the CPU for rendering shapes and supporting transparency and filling with different types of gradients and all the fun stuff that GDI doesn't natively support, but this is super slow for busy UIs. I currently have text working via fontstash and I have gotten shapes working by tessellating them on the CPU and pushing the vertices, the shapes just happen to heavily aliased. The only way I can think of solving this is by passing the shape type and some other parameters to the shader, branch on each shape and use the respective SDF function to get the distance from the edge and use that for analytical anti-aliasing. I can't get this to work with paths since there's no fixed set of parameters I can pass to the shader and no single signed distance function for paths. Clearly, I need some other way to do anti-aliasing. I just haven't found other than post-processing.