Since it allows you to run networks during shading

Would it be possible in theory to use your own network for upscaling?

I'm switching actor geometry by projected screen radius instead of world distance. Each LOD band has separate enter/exit thresholds, while far actors update animation at a lower cadence. Would you tune the hysteresis per band or scale it with camera velocity?

Developer disclosure: some source meshes are Meshy-assisted; the runtime and LOD integration are custom.

https://reddit.com/link/1v3l201/video/0lkts09v4teh1/player

I am making an animated schematic map and trying to render, dynamically add/remove and animate hundreds of rounded polylines (lines with arcs connecting them), with changes in weight, color, position of nodes, and radius of nodes.

I fist tried to make this in the browser with the canvas API, but the performance is horrible in low end devices after a couple dozen lines, as I end up needing to generate new paths in every frame.

I searched for some library but couldn't find anything, as things like ThorVG with WASM would still require me to re-generate meshes if nodes are animated on the fly.

I don't really have much knowledge about shaders and GPU compute outside of doing things with nodes in Blender. My best idea on how to do it in shaders without overcomplicating things would be to have individual arcs and line segments as mesh instances, and just squish and distort them from a vertex(?) shader (initially calculating their positions and parameters from the polylines in the CPU, and moving to the GPU once I understand enough). I could also try using SDFs, but I doubt the performance would be enough.

Does anyone know of any library that would do what I need/be a good starting point, or can judge my idea on how to implement this in a shader? I am working from C++ and need it to be multi-platform, but not necessarily work in the browser (although it would be nice). Any resources would be appreciated. Thanks!

Been diving into embedded systems for the first time lately. I have an STM32 and a little LCD, but feel free to suggest anything. Thanks

Khronos has released the Shader Ecosystem Survey Results.

The results provide a summary of insights from over 400 shader developers, graphics programmers, rendering engineers, and tools creators. Conducted between June 16 and July 10, 2026. It captures a clear picture of how the real-time shading community works today — and where standardization efforts can deliver the greatest impact.

https://www.khronos.org/blog/shader-ecosystem-survey-results-2026?utm_medium=social&utm_source=reddit&utm_campaign=Shader_Survey_Results&utm_content=blog

The engine is developed entirely in Rust and uses Vulkan, with shaders written in Slang. The goal is to link the grass (modeled as meshes) to the underlying voxel terrain, while making the wind system fully configurable and reusable by other parts of the engine (via ECS). Here is how it currently works:

• A compute shader iterates through each column of every terrain chunk from top to bottom. It generates a blade of grass only if the surface voxel uses the "grass" material and the voxel directly above it is empty (It's for world-building, the engine handles grass density and height, which will enable a natural grass growth system).
• The blades aren’t stored as voxels. They’re generated as GPU instances containing their position, type and height.
• When the terrain is destroyed or repainted, the chunk’s grass instances are rebuilt from the voxel data. This keeps the grass in sync with the actual terrain edits.
• Before rendering, the GPU culls unnecessary blades and lowers their geometric detail with distance. The remaining blades are drawn as curved ribbons in a raster pass that uses the depth from the ray-marched voxel world.
• The ambient wind has its own direction, speed and moving gust fronts. It remains anchored in world space, even when the floating origin moves.
• ECS components can add radial pushes or directional gusts. The player already uses this system to part the grass. A vehicle, a thruster, a dragon’s wings or anything else could use the same components to affect nearby vegetation.

Grass is currently the first system wired into the full wind field. A matching CPU implementation is already in place, but physics and other vegetation systems haven’t been connected to it yet.

It has been about a week where I started getting into the topic of real time terrain programming, with the goal of creating an open world engine.

Starting with "Riemer's XNA terrain tutorial" is a very simple and easy to understand foundation, then it would be feasible to explore and evolve more advanced topics on top of it.

However now I am bit troubled on the terrain size:
• heightmap is a picture of 2048x2048 pixels (has a good amount of detail, so I am going with this for now)
• terrain detail looks quite good by a 512x512 vertex count so I doubt that I will need to go any higher

Now the interesting part is that if the entire terrain size is 512 then it will be equivalent to the vertex count, this means that one world unit is a sampled by one vertex position. Then simply later on scaling to 1024 or 2048 it makes the world larger. But the detail does not change, the world feels a bit more zoomed in.

No problem with 512 but definitely it means that I will start fresh with a proper tile based system. Then this means that since now it won't be a matter of a X*Z vertex capacity anymore that I will go for a 1:unit==1:pixel and eventually getting exact ratio of the world as the heightmap.

So let's say that for the sake of consistency and accuracy should I stick to size of 512 then? Because all models and all physics calculations might be calibrated by a 1:unit=1:meter ratio and call it a day.

Honestly there's no exact explanation on this. AI says "do whatever you want" then other games like OpenMorrowind or OpenVice or even closed source Skyrim, they just use some interesting scaling techniques that would be cool in order to save resources about 15++ years ago. So I am just going at random with this, not having a clue.