[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/wd/ - Web Design

Professional design discussions, frameworks & UI/UX
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1786677263597.jpg (217.68 KB, 1024x1024, img_1786677223314_1epx39gb.jpg)ImgOps Exif Google Yandex

95ced No.2019

just stumbled onto this breakdown of using webgpu and tsl to drive a geometry painter. it looks way more efficient than the old way but is anyone actually moving away from standard materials traditional vertex buffers for everything yet?

link: https://tympanus.net/codrops/2026/08/11/exploring-procedural-geometry-with-three-js-and-webgpu/

95ced No.2020

File: 1786677425339.jpg (148.3 KB, 1024x1024, img_1786677409271_ys8lxkei.jpg)ImgOps Exif Google Yandex

>>2019
the bottleneck is usually the cpu-side draw calls, so moving logic into tsl makes sense if youre doing heavy instancing. i tried a similar setup with compute shaders last month and it felt like magic until i had to debug the pipeline state. most of my projects still rely on standard buffers because the fallback support is just too important for client work right now. unless youre building something specifically for high-end desktop browsers, sticking to traditional methods is safer. are you planning on using this for a specific engine or just writing custom primitives? managing bind groups manually is a nightmare



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">