Nadie te dice por qué la patente del texto en 3D ya es gratis

Hay una patente que estuvo cerrada durante nueve años y que en marzo de 2026 Eric Lengyel decidió dejar en dominio público. No es una patente de hardware, no es un codec de video, no es un algoritmo de IA. Es el algoritmo que dibuja las letras que estás leyendo ahora mismo en una pantalla 3D.

Suena absurdo. ¿Cómo una patente sobre texto va a ser noticia? Porque en realidad te dice mucho sobre cómo funciona la industria gráfica, quién controla qué y por qué cada vez que pones un HUD en un videojuego, una etiqueta en un mapa 3D o un panel en un visor de realidad virtual, hay un compilador que decidió por ti.

El problema: una letra no es una imagen

Todo el mundo asume que el texto en pantalla es "una imagen de una letra". No lo es. Una letra es un contorno: bucles cerrados de líneas rectas y curvas Bézier. En una CPU rasterizas ese contorno una vez al tamaño que quieres y listo. En una GPU no puedes hacer eso miles de veces por frame, y ahí empieza el truco.

El truco de décadas fue el atlas de textura: horneas cada glifo como un bitmap en una textura compartida y luego cada letra en pantalla es un quad texturizado. Es rápido, funciona en cualquier hardware con texture unit, y por eso está en todas partes. Hasta que lo amplías.

Amplías y se vuelve borroso. Encoges y parpadea. Cada tamaño que quieres limpio es otro atlas. Y si necesitas chino, japonós o coreano, tens de miles de glifos por varios tamaños: la memoria se dispara.

Las tres respuestas clásicas (y por qué ninguna es perfecta)

Valve encontró el parche que sostuvo la industria una década: SDF (signed distance field, 2007). En vez de guardar píxeles, guardas la distancia al borde más cercano: positiva dentro, negativa fuera. El shader umbraliza en cero y listo. Es absurdamente barato.

El problema es que un SDF miente. Una esquina aguda es una discontinuidad en el campo de distancia, y la interpolación bilineal la redondea. La punta de la "A", la muesca de la "K". Se ven suaves, como si el texto estuviera un poco borracho.

MSDF (Viktor Chlumsky, 2015-2018) lo arregla guardando tres canales en vez de uno y tomando la mediana en el shader. Los corners vuelven a ser nitidos. Es el estándar de facto actual y su msdfgen es MIT. Pero sigue siendo un atlas horneado: peso, tiempo de generación, y el problema persiste con sets de glifos enormes.

Una tercera familia (Loop-Blinn, NV_path_rendering, Pathfinder, Rive) convierte el contorno en geometría y lo rasteriza. Es independiente de resolución de verdad, pero paga el costo de la teselación y el antialiasing limpio sigue siendo difícil.

Slug: dibujar la letra desde el contorno, no desde la textura

En 2017 Eric Lengyel publicó GPU-Centered Font Rendering Directly from Glyph Outlines. La idea es radical en su simplicidad: el glifo se queda como lo que es, una lista de curvas Bézier cuadráticas, en un buffer chico de GPU. No hay atlas. No hay teselación por frame.

En el fragment shader, cada píxel lanza un rayo, encuentra dónde cruza las curvas cercanas, cuenta los cruces y calcula el número de bobinado. Eso es la cobertura exacta del píxel. El detalle fino es un test que Lengyel llama root eligibility: una regla precisa para decidir qué intersecciones curva-rayo cuentan, para que las cuentas sean exactas justo en los puntos donde las curvas se tocan y donde los métodos ingenuos abren grietas o cuentan dos veces.

El resultado práctico: la misma letra sale filosa a 6 píxeles o a 6.000, y sigue filosa en perspectiva porque la cobertura se calcula por píxel después de la transformación. Cien mil glifos CJK cuestan lo que una fuente en curvas, no un atlas del tamaño de un vídeo. Y todo ocurre en un solo draw con un fragment shader normal.

Por qué importa que sea gratis

Porque durante nueve años la respuesta a "quiero texto perfecto en 3D" era "paga una regalía o renegociamos". El 17 de marzo de 2026 Lengyel dedicó la patente al dominio público, y en meses aparecieron implementaciones como Slughorn, una en C++20 con licencia MIT que apunta a OpenGL, Vulkan, WebGPU y DirectX.

La consecuencia práctica para ti como dev: los motores que elegías por licencia de la tecnología de texto ya no son la única opción. Y en un ecosistema donde VR, AR, gemelos digitales y CAD dependen de que una etiqueta siga siendo legible cuando el usuario se acerca a un ángulo de 3 grados, eso deja de ser un detalle gráfico.

Y HarfBuzz ya lo está haciendo

La otra señal de que esto no es un capricho de un solo programador: HarfBuzz, el motor de composición de texto más usado del mundo (Chrome, Firefox, Android, iOS), lanzó su propia librería de renderizado de texto acelerado por GPU en la versión 14.0. El texto ya se procesa en la GPU hasta en el navegador que estás usando para leer esta nota.

¿Qué tienes que hacer con esto?

Si haces interfaces 3D, VR o mapearías: mira Slughorn antes de construir tu propio atlas. Si solo haces UI 2D, un MSDF bien generado sigue siendo la respuesta pragmática y nadie te va a publicar un issue por eso.

Lo que me gusta de esta historia es lo que revela sobre el open source en general: la innovación muchas veces no nace en un repositorio público, sino en una patentación que alguien decide soltar. No siempre es heroico. A veces es solo una persona cansada de cobrar.

Comparte esto con alguien que todavía paga regalías por dibujar letras en 3D, o dime qué motor gráfico te parece que va a adoptar esto primero.