Forem: Gabriel Cerdio

👋 Looking for collaborators — PhysicClaw-VEA

Gabriel Cerdio — Sat, 07 Mar 2026 01:41:12 +0000

We're building an interactive 3D app featuring a virtual entity
that reacts in real time through shaders, emotions, and voice — powered by real AI.

🛠 Stack: React 19 · Three.js WebGPU · Supabase · TypeScript · Vite

🔨 What we're working on:
Multi-user auth + persistent 3D cloud scenes (v2.0)

🤝 We need help with:
• Backend / PostgreSQL / RLS (Supabase)
• 3D Frontend (React Three Fiber, custom shaders)
• AI / LLM integration (OpenClaw · Gemini)

📌 Repo: github.com/yomero243/PhysicClaw-VEA

Interested? Reply here or DM 🙌

Debugging IA slop is the future?

Gabriel Cerdio — Fri, 19 Dec 2025 06:01:10 +0000

It's worth investing heavily in Three.js and WebGPU now. Not only because of the imminent visual power of AR/VR, but also because of a critical reality: AI democratizes bloat code, and hardware penalizes inefficiency.

I think the next big market niche will be for engineers who understand the true cost of computing
for webgpu computational cost and can audit and debug the chaos generated by even the simplest warning.

The Inevitability of the Graphics Paradigm and the AI Entropy Crisis: Considering whether learning Three.js and WebGPU is 'worth it' is a category mistake; it's not a choice, it's a technical survival imperative. We are witnessing the obsolescence of DOM-based rendering in favor of hardware-accelerated spatial computing. However, the real investment thesis is not visual fidelity, but the entropy of AI-generated code. LLMs are probabilistic engines that generate syntactic 'slop': code that compiles but is algorithmically inefficient and structurally redundant. AI can hallucinate logic, but it cannot hallucinate physics. The GPU is a strictly deterministic environment; 'implementers' will be replaced by AI. The real value will be concentrated exclusively in Graphics Optimization Engineers: those capable of auditing AI's probabilistic garbage, refactoring it at a low level (WebGPU/WGSL), and forcing its Execution within the 16ms frame budget limits. We're not learning graphics to 'create' better, but to prevent the web from drowning in its own automatically generated inefficiency.

¿El futuro del modelado es la IA o la especialización?

Gabriel Cerdio — Tue, 30 Sep 2025 06:14:18 +0000

Hola a todos,

Últimamente he estado experimentando con las capacidades de generación de imágenes de IA y Tencent Hunyuan, específicamente con Gemini y generación de modelos con Tencent Hunyuan, y me he llevado una grata sorpresa. Le pedí a Gemini que generara diferentes vistas de un "estampador": una vista frontal, una vista trasera, una vista de perfil y una isométrica. El resultado fue bastante impresionante:

Las imágenes generadas por la IA me sirvieron como una base muy sólida para crear un modelo 3D bastante decente. Aunque la topología aún requiere trabajo manual para ser óptima, y la texturización está un paso más allá (sigue siendo un proceso bastante artesanal para lograr resultados de alta calidad), el punto de partida que ofrece la IA es innegable.

Esto me lleva a una serie de preguntas que creo que son cruciales para la comunidad de artistas 3D y desarrolladores:

¿El proceso de creación de assets 3D sigue siendo fundamentalmente "artesanal"? A pesar de los avances en la IA, ¿cuánto de la creación de un asset de calidad AAA sigue dependiendo de la habilidad y el toque humano?

¿Qué tecnologías están por liderar la industria del modelado 3D? ¿Veremos un salto masivo en herramientas asistidas por IA que automaticen gran parte del proceso, desde la creación de modelos hasta la texturización y el rigging?

¿El trabajo está "muerto" para los modeladores 3D, o qué le espera al artista 3D del futuro? Personalmente, no creo que el trabajo esté 4muerto, sino que está evolucionando.
Pero, ¿hacia dónde?

¿Se necesitará más especialización o más generalismo? En un mundo donde la IA puede generar rápidamente bases para modelos, ¿será más valioso un "prompt senior de 3D" capaz de dirigir la IA y pulir sus resultados, o un especialista en áreas muy específicas como la optimización de topología o la creación de materiales procedurales complejos?

A Broken Backend Chronicle: Lost in the Labyrinth of AWS, Docker, and a Next.js App Screaming for a Database

Gabriel Cerdio — Mon, 29 Sep 2025 02:23:55 +0000

My Next.js frontend is a 10/10. My backend is a 0/10 graveyard of failed AWS instances and broken Docker containers. I'm stuck in tutorial hell trying to connect a simple Postgres DB. Is Prisma overkill? Am I over-engineering this? Help me break the cycle! What's the 'it-just-works' stack for this?

I'm not here with a 5-step tutorial for success. I'm here with a war story, a call for help, and hopefully, a future redemption arc.

I have this project, Manhattan v1.0, a frontend I've been building with Next.js and React. I love how it looks, how it feels, and the potential it has. You can check it out for yourself right here:

➡️ GitHub Repo: https://github.com/3lneer/Manhattanv1.0

The problem is, right now, it's just a pretty face. A shiny, soulless shell. It needs a backend—a PostgreSQL database to be exact—and this is where my journey went off a cliff.

The Mission: A Free Backend in the Cloud
My goal seemed simple: connect my app to a PostgreSQL database that wouldn't cost me an arm and a leg (ideally, free) while I'm developing.

Attempt #1: The Big Cloud Dream (AWS RDS) 🌩️
Like many, I thought, "Let's do this the 'professional' way." I dove headfirst into AWS RDS. I configured my instance on the free tier, felt the power of the cloud... and was quickly overwhelmed. The security configurations (VPCs, Security Groups), the IAM credentials, and that constant paranoia that one wrong click would land me a bill the size of a new car.

Result: After hours of frustration and feeling like I was building a rocket ship just to go to the corner store, I gave up. AWS is incredibly powerful, but for my current stage, it was like using a sledgehammer to kill a fly. Failure.

Attempt #2: The Local Fortress (Docker) 🐳
"I know!" I thought. "I'll do it locally. Total control, zero cost." I submerged myself in the world of Docker. I wrote my docker-compose.yml with my Postgres service, ready to connect with DBeaver and my app.

It sounded perfect in theory. In practice, I found myself fighting with volumes, container networks that wouldn't talk to each other, and cryptic errors that my Stack Overflow searches only made more confusing.

Result: I have a Docker image that is probably offended at me and refuses to cooperate. I feel more lost than before. Failure, again.

The Current State: Analysis Paralysis 😵
And here I am. My frontend is ready, DBeaver is open waiting for a connection that never comes, and a terminal that stares back at me with disdain. I'm so stuck that, just to feel productive and cool, I started downloading Omarchy. At least that way I feel like I'm on the cutting edge of something.

The Additional Dilemma: Is Prisma My Friend or My Foe?
My project uses Prisma as an ORM. I love the idea of type safety and automatic migrations. But now, in the midst of this chaos, I'm wondering:

Am I just adding an unnecessary layer of complexity? Should I ditch Prisma and go back to raw SQL queries to simplify things, or is it precisely the tool that, if used correctly, could save me?

Implementing a Realistic 3D Air Hockey Table with Three.js and React

Gabriel Cerdio — Wed, 14 May 2025 05:09:15 +0000

feel. free to commitme a any suggest

https://airhokey-3d.netlify.app
Building a Real-Time Collaborative 3D Air Hockey Game with React, Three.js, and Yjs
description: A deep dive into the architecture, technology stack, and design trade-offs behind a browser-based multiplayer 3D Air Hockey experience.

https://deepwiki.com/yomero243/collaborative-3d-app/1-overview
The Collaborative 3D Air Hockey Game is a browser-based, real-time multiplayer application that enables users to play air hockey together in a rich 3D environment. Players move their paddles with mouse input, interact with a physics-driven puck, and observe other participants’ actions with sub-100 ms latency—all without a native client :contentReference[oaicite:0]{index=0}.

This article dissects the system’s purpose, architecture, technology stack, and the inherent trade-offs encountered during development.

1. Purpose and Goals

Interactive Multiplayer: Allow concurrent play in a single game session, accessible from any modern browser.
3D Visualization: Leverage WebGL via Three.js and React Three Fiber for immersive rendering.
Physics-Driven Gameplay: Simulate realistic collisions, friction, and impulse calculations for the puck.
Real-Time Synchronization: Use Yjs and a lightweight WebSocket server to synchronize user positions and puck state across clients :contentReference[oaicite:1]{index=1}.

From 3D Artist to Full-Stack Dev: My Self-Taught Journey Through JS, Neovim & Beyond

Gabriel Cerdio — Mon, 14 Apr 2025 05:51:39 +0000

I’m Gabriel — a self-taught developer with a background in 3D modeling and rendering. A year ago, I was building photorealistic architecture renders. Today, I’m deep into JavaScript, Three.js, AWS, Flutter, and NeoVim.

This is my first post here on dev.to, and I want to document my journey, share some hard-earned lessons, and maybe help others who are switching fields or leveling up on their own terms.

If you’re stuck, overwhelmed, or wondering if you’re “too late” to start, this one’s for you.