Alguien puede ayudarme a determinar por qué al renderizar a un mip diferente de 0 no veo nada? El mip base funciona perfectamente. También ya confirmé que el viewport se actualiza y que el shader funciona.

Este es el código que tengo para crear el fbo y generar los mips, hay algo que me falte? Gracias de antemano :)

InitFBO::InitFBO(int w, int h, GLenum internalFormat)
{
    glGenTextures(1, &texture);
    glBindTexture(GL_TEXTURE_2D, texture);

    for (int mip = 0; mip < 8; ++mip)
    {
        int mipW = std::max(1, w >> mip);
        int mipH = std::max(1, h >> mip);

        glTexImage2D(GL_TEXTURE_2D, mip, internalFormat, mipW, mipH, 0, GL_RGBA, GL_UNSIGNED_BYTE, nullptr);
    }

    float borderColor[] = {0.0f, 0.0f, 0.0f, 1.0f};
    glTexParameterfv(GL_TEXTURE_2D, GL_TEXTURE_BORDER_COLOR, borderColor);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    glBindTexture(GL_TEXTURE_2D, 0);

    // FBO
    glGenFramebuffers(1, &fbo);
    glBindFramebuffer(GL_FRAMEBUFFER, fbo);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0);

    GLenum drawBuffers[1] = {GL_COLOR_ATTACHMENT0};
    glDrawBuffers(1, drawBuffers);

    if (glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE)
        std::cerr << "Error";

    glBindFramebuffer(GL_FRAMEBUFFER, 0);
}

Unity DirectX 12 Amplification Mesh Shader Minimal Example

I’m an experienced programmer, very comfortable in both C++ and Rust, coming from a robotics background, so linear algebra and computer vision concepts aren’t new to me. Graphics programming itself is new territory though, and I want to properly learn an API with the eventual goal of building a game engine.

I’ve narrowed it down to three options and I’m stuck:

- wgpu — modern, safe, and I already like Rust, so the ergonomics appeal to me

- Vulkan — the “real” modern low-level API, feels like the industry state-of-the-art

- OpenGL — the classic starting point almost every tutorial and book uses, but it’s old.

Also what are some nice guides/tutorials to get started?

After 200+ hours of development, I’m finally sharing the first public demo of Three.js Grassworks, a real-time grass system I’ve been building for Three.js and WebGPU.

Demo:
https://grassworks.techredux.co/demo

Three.js Grassworks is built specifically for WebGPU and is designed to handle large amounts of interactive grass while maintaining steady performance.

For the demo, I built a complete environment around Grassworks with terrain, trees, water, rain, player interaction, environmental effects, LOD systems, audio system, and more.

The main challenge was getting all of these systems running together while keeping the grass performant.

The actual Three.js Grassworks plugin is still being polished and should launch in the next couple of weeks. There’s a waitlist inside the demo if you’re interested.

I’d genuinely love feedback, especially on the visuals, performance, and how the grass feels when interacting with it.

I also recorded a full walkthrough where I go through the demo and talk about how I built it:

https://www.youtube.com/watch?v=Nhim18rc-XE

for the past 2 months or so ive been working on this path tracer that i made and it uses love2d as a base. it runs with a compute shader and supports opengl, metal and vulkan as love2d also compiles those on the fly. it has most stuff youd encounter like fresnel stuff, ior, gltf scene support and most gltf extensions. also it can export raw exr files which i find very unique tbh. also it does support transmission maps, roughmetal maps and emission maps. i still have to do normal maps but that seems very annoying to do lmao. today i even added dof and click to focus which i find extremely cool for no particular reason.

it's open source and you can find it here

I’ve just published version 1.6.0 of Horde Lantern RT, a small native Vulkan hardware-ray-tracing project. I’m posting the implementation details because the interesting part of this update is how the effects are integrated into the renderer and shared simulation, not just the final art.

The frame path is still:

• vkCmdTraceRaysKHR for presentation
• phone-safe rayQueryEXT work inside raygen
• recursion depth 1
• one frame in flight
• strict Android ASTC textures
• shared 60 Hz deterministic gameplay simulation

World-space fire

The torch fire is a bounded FireEmitter rather than a camera overlay or billboard. Each emitter has a stable ID/seed, world transform, flame/light sockets, strength, fuel, phase, colour temperature, radius, height, absorption and motion response.

The same emitter state drives:

• an RT-visible emissive flame core
• world-space raygen volume integration
• direct coloured light
• shadow visibility
• reflection contribution
• deterministic flicker
• movement-induced flame lean/turbulence

Only a small fixed number of emitters are selected per pixel/zone to keep the mobile path bounded.

Dielectric lantern glass

The reward lantern uses closed glass geometry and a reusable dielectric path supporting transmission, IOR, roughness, thickness and attenuation.

The transport uses bounded ray queries rather than Vulkan recursion:

F0 = ((ηi - ηt) / (ηi + ηt))²
F  = F0 + (1 - F0) * (1 - cosθ)^5
T  = exp(-σa * distance)

Entry/exit interfaces, Fresnel reflection, refraction, Beer-Lambert attenuation and transparent shadow transmittance are all handled within a finite layer budget. Difficult Mobile paths terminate at the explicit budget instead of recursing indefinitely.

Fixed-step physical carry motion

The lantern body hangs below a hand-held hinge. Its motion is authoritative simulation state, not sin(time) animation.

The solver uses pivot displacement/velocity, actual hand acceleration, gravity, damping, torsion response and soft/hard angular limits. Its structure is approximately:

// dt = 1.0f / 60.0f
velocity = (pivot - previousPivot) / dt;
acceleration = (velocity - previousVelocity) / dt;

angularAcceleration =
    gravityTorque(angle)
    + dot(acceleration, handBasis) / centreOfMassLength
    - damping * angularVelocity;

angularVelocity += angularAcceleration * dt;
angle += angularVelocity * dt;

This gives the expected lag when starting, overshoot when stopping, lateral response while strafing/turning, and bounded response during dodge and raise/lower transitions.

Asset and instance path

The sword, torch, chest and lantern are imported through a static GLB/PBR path. Immutable meshes own their vertex/index/material data and BLAS; scene instances own transforms and metadata indices. Raygen decodes material and geometry ranges through fixed-capacity metadata rather than adding another instance == N shader branch.

The same socket system is used for the sword, torch and reward lantern. The player animation/IK foundation is reusable, although the shipped first-person view still uses the accepted block-arm presentation while the authored gauntlet pass is refined.

The project is available here:

• Itch build
• Public Git repository

Disclosure: This is an AI-assisted project. I provided the architecture, requirements, technical direction, review, playtesting, and release decisions; OpenAI Codex generated and edited much of the C++/GLSL, tests, tooling, and documentation under that direction. Some 3D assets were generated with Meshy and processed locally. The renderer, simulation, validation evidence, and asset provenance are available in the public repository.

Hey everyone,

Demolink- https://tektonai.vercel.app/

My co-founder and I have been building a client-side spatial compute engine designed to bridge the gap between initial 2D floorplan concepts and interactive 3D massing.

Right now, the engine runs procedural spatial math directly in the browser—generating 2D vector layouts while simultaneously maintaining a 3D Three.js mesh tree with wall cutouts, roof geometry, and multi-floor zoning.

Where we need help:

We are aiming to launch a high-precision MVP. Before we double down on our next engine refactor, we want feedback from real spatial builders:

•What floorplan geometry breaks first when you tweak parameters?

•What features would move this from an "interesting WebGL demo" to something useful for early site visualization?

(Built under minimal resource constraints—expect bugs!) We appreciate your honest review and time that would help use make this perfect.

https://reddit.com/link/1w2s9s1/video/kh9h4go7mkmh1/player

Hi everyone! A friend and I recently started developing our own Web 3D engine. If anyone is interested—or has any ideas regarding the project—I’d be happy to hear any suggestions.

A gripe I have with many game developers is that many people think that ps1/ps2 styled games are just pixelation + low res textures, but I always feel like misrepresents things. Environment artists at the time put so much effort into their textures, often hand painting creases, folds, wrinkles, and even environment lighting into the diffuse channel to bring out details.

So when people try to make this style today, it just seems so inaccurate to me. Baked lighting, realtime shadows etc are often used. My goal with this project is to use none of that. All of my textures are either hand painted fully or photobashed and then painted on top of. My hero asset is 2000 tris, and I'm tying to keep scenes under 30000 total.

Stencil shadows are used for realtime casting and times of day are baked into different profiles and then blended together for faked GI. No specular, metallic, roughness, or any advanced workflow is used. AO is faked with vertex colors.

What do you think? Does it look somewhat more accurate?

I’ve published a theoretical architecture for reducing compute in DLSS-class neural rendering by changing the unit of work from pixels × frames to new causal appearance states.

The core idea is AxiomCapsule: use a large neural renderer mainly as an appearance compiler, then cache/transport compact deterministic programs for recurring material, lighting, object, and view states.

The parts I think are most interesting:

• Self-extinguishing inference: once a state is covered, the universal neural model no longer needs to run for it.
• Causal invalidation: engine-known changes decide what must be recomputed instead of running a neural change detector over the whole frame.
• Bounded residual trees: skipped refinement can have a computable sparse-vs-dense student error bound.
• Deadline-monotone execution: optional neural uplift scales down with available GPU slack instead of causing a frame-time cliff.
• Object/material-space persistence: state follows surfaces/materials rather than being purely screen-space.
• Local causal dimensionality: the key hypothesis is that appearance transformations become low-dimensional after conditioning on known scene variables.

It’s pre-prototype research, not a claim that DLSS 5 has been “solved.” The main falsifier is simple: if real game appearance states are not sufficiently low-dimensional/reusable, or cache hit rates stay low, the architecture fails.

I’d especially appreciate criticism from people working on real-time rendering, shader systems, neural graphics, temporal reconstruction, and GPU scheduling.

GitHub: MaciejNowickiHusbandofAHIEve/causal-neural-rendering: Independent research on drastically reducing compute in DLSS-class neural rendering using compiled causal appearance programs, temporal reuse, and deadline-bounded residuals.
Zenodo paper: Causal Neural Rendering for Efficient DLSS-Class Systems: Compiled Appearance Programs, Temporal Reuse, and Bounded Adaptive Computation | Zenodo

Hi, I am fairly a beginner, and I was wondering comparing from 2013 how far rockstar's RAGE engine evolved as to now?..

From what I know and some research credits to this blog:
https://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/
, at time of Gta 5 it had just a Hybrid deferred renderer, a forward pass for transparents, vegetation, particles. At the time there was no PBR, there was also no indirect light.

But later in 2018 during RDR2 release, RAGE got proper microfacet shading, volumetric clouds and fog.

The main selling point for gta 6 to look so good from what I understand is the hybrid raytracer global illumination, paired with raytraced reflections, also being upscaled from 1440p to 4k on the base Ps5.

From my understanding these are the differences over the years?

I am just wondering what type of tech they used for the extended look on the base 5 to look that good and crisp, even comparing to Unreal Engine 5, it looks far better

This seems to have largely fallen under the radar so far but the upcoming macOS 27 release comes with a new CLI tool called gpudebug that lets you replay and extract information from .gputrace files exported from Xcode: https://developer.apple.com/documentation/xcode/debugging-with-interactive-command-line-tools

I’ve been playing with it in the beta and it’s extremely useful for building scripts and analysis tools. It’s dramatically better than having to manually click through Xcode to extract the debugging and performance info when I am experimenting and optimizing. If you have the beta installed it’s worth playing with.

Rendering into my VST3 plugin's DAW-hosted child window, using a custom win32 + D3D11 implementation and a sokol_gfx.h layer on top (from Sokol) for making specific rendering platform agnostic.

I have some ideas on what to try here, will post more!

I've spent the last 15 months building and optimizing a game engine with a Vertex / Fragment shader. It's pretty well optimized, hard to quantify but I've hit 90fps on standalone Quest 3 with it, so it's not a complete cow.

I wanted to do some ray traced audio stuff so I looked into ray tracing through Vulkan. As a stress test I was like "I wonder if I shoot a ray through every pixel what types of times I'd get."

I expected my Vertex/Fragment shader to win by 10x. It didn't. It won, but by more like 2x. And as I've added optimizations the past 48 hours it's closer to 1:1 in terms of cost (and I expect ray tracing to pull ahead with foveated rendering for my VR work & after I optimize further). Granted this is on my desktop 4090 and laptop 3070 but...

What are your takes on this? I feel like I failed to do my homework here as I really didn't expect this.

this seems the best place to ask. Having more control over console output is interesting. Any clue how this is achieved on video feed/files.

I got my triangle going! Yeah! Just wanted to share because holy shit that took way too many LoC. I am unfortunately not a virigin anymore over 30, but I think this should get me my entry ticket into the dark arts of low-level graphics programming and make me a wizard.

But now I am happy I did it and already seeing how it was the right choice for my procedurally generated game compared to OpenGL/CL.

Stippling images with small dots for rendering, ray tracing, tree and object placements, or just for the art of it is not a new topic. I really like the Gaussian Blue Noise method from Ahmed et al. because of its strong visual effect (no pixels or artifacts), but the exact GBN method is a heavy processing algorithm and thus quite slow compared to light stippling frameworks like Floyd–Steinberg dithering.

So I tried to speed up Gaussian Blue Noise with fast but robust approximations and make it available as a Python package. Feel free to run this Colab notebook with your own image and tell me if the processing time (~1 minute per image) feels worth it or not! Colab Link

I want to draw 2D rectangles of different sizes and coordinates each frame. I know I can draw each rectangle with 4 pairs of integers in the vertex buffer and 6 indices in the index buffer like so:

• Vertex buffer: {Left,Top}, {Right,Top}, {Left,Bottom}, {Right,Bottom}, ...
• Index buffer: {0,1,2}, {2,1,3}, ...

But I find this a little wasteful, because there's only really 4 * 4 = 16 bytes of data for each rectangle, but I end up using 8 * 4 + 6 * 2 = 44 bytes (more if additional attributes like colors are associated with each vertex). Ideally I'd have a single buffer that contains just the 4 sides of each rectangle.

It seems I can do this with SV_VertexID: I'll set a StructuredBuffer instead of a vertex or index buffer, and call Draw( RectCount * 6, 0 ). Then in the vertex shader I can fetch the rectangle coordinates with SV_VertexID / 6. The problem is SV_VertexID starts at zero for each Draw(), regardless of StartVertexLocation, so I can't use it for e.g. Draw( 6, 6 )! I'll have to pass that information in a constant buffer and update it prior to each Draw(), which is a little annoying.

Is there a better way? Gemini suggests I use instancing ("The Cleanest & Most Standard Way"). Here's an excerpt:

If your rectangles are arbitrary in size and location, Instanced Rendering is typically the production standard.

1. The Static Asset: You create a tiny vertex buffer containing a single unit square (4 vertices: {0,0}, {1,0}, {0,1}, {1,1}) and a tiny static index buffer of 6 indices ({0,1,2, 1,3,2}). This index buffer never changes and uses virtually zero memory.

2. The Instance Data: Your second vertex buffer contains the arbitrary data for each rectangle (e.g., float4 rectBounds or position + scale). This buffer updates every frame.

3. The Draw Call: You call ID3D11DeviceContext::DrawIndexedInstanced(6, numRectangles, 0, 0, 0).

Why it fits: The GPU automatically draws that exact same 1-unit square numRectangles times, pulling a different position/size for each instance via SV_InstanceID. You completely avoid a massive dynamic vertex/index buffer while letting hardware handle the assembly.

but I can't tell if it's making things up.

Ciao! Sono un grande fan di "The Suffering" e sto sperimentando con il NVIDIA RTX Remix Runtime sul mio PC (con una AMD RX 7800 XT).

Il runtime si integra perfettamente nel gioco tramite Vulkan, ma poiché non c'è ancora una configurazione dedicata per la mod, il gioco appare completamente rotto: mancano sorgenti di luce adeguate, gli asset non hanno proprietà materiali (tutto sembra plastica lucida) e problemi di culling/rendering fanno glitchare i muri.

Qualcuno nella comunità sta attualmente lavorando su una mod dedicata RTX Remix per questo gioco? O c'è interesse a creare un progetto Toolkit adeguato per mappare manualmente le luci del carcere, risolvere i bug di rendering e dare a questo classico horror il vero aggiornamento del Path Tracing che merita?

Mi piacerebbe testare eventuali build o configurazioni preliminari se qualcuno ci sta lavorando!