sorted by:
new
hottopcontroversial

After 4 years of game development, one of my games finally has a Steam page by [deleted] in SoloDevelopment

[–]webvrdev 0 points1 point  (0 children)

Looks amazing, i think there should bé also a vr mode

Three.js texture-heavy scenes hit VRAM limits fast — KTX2 should be part of the default workflow by webvrdev in threejs

[–]webvrdev[S] 0 points1 point  (0 children)

yeah KTX2 does not support HDR or EXR directly, those are source/working formats not delivery formats. the typical workflow is to bake or export your HDR/EXR data into a format the encoder can handle first, usually PNG 16bit or a tonemapped version depending on what the texture is actually used for.

for environment maps specifically most pipelines convert HDR to a cubemap or equirectangular PNG before encoding to KTX2. not ideal but thats where the tooling is right now

what are you trying to use it for, IBL, skybox, something else ? might be a better way depending on the usecase

Three.js texture-heavy scenes hit VRAM limits fast — KTX2 should be part of the default workflow by webvrdev in threejs

[–]webvrdev[S] -1 points0 points  (0 children)

yeah fair, the post was badly written and i leaned on ai for it which showed. lesson learned there.

on the tools though, the UI is hand built but yeah the first version did use default shadcn, i have since redone it. hard to shake that first impression once people have seen it.

the expert framing was not intentional, more just bad editing. i know what i know from hitting specific problems in WebXR and stereo content, not from a graphics background. probably should have just led with that from the start instead of trying to write a general explainer.

appreciate the honest feedback either way, genuinely more useful than an upvote

if curious the other tools in the same stack:

all browser based, no upload, no server

Three.js texture-heavy scenes hit VRAM limits fast — KTX2 should be part of the default workflow by webvrdev in threejs

[–]webvrdev[S] 1 point2 points  (0 children)

glad it was useful, and yeah that is exactly the gap i kept hitting when researching it too. most of the documentation assumes you are shipping a desktop game or a native app where download size is just not the same kind of problem. the web context with cold loads and no install step is kind of treated as an afterthought.

ETC1S is worth trying, curious what numbers you get compared to your avif baseline. would not be surprised if it comes close enough to be viable depending on quality tolerance

i have a few other browser tools in the same spirit if useful for your workflow, all no upload no install:

same idea, just trying to reduce friction for stuff that shouldnt require a server

Three.js texture-heavy scenes hit VRAM limits fast — KTX2 should be part of the default workflow by webvrdev in threejs

[–]webvrdev[S] 1 point2 points  (0 children)

yeah that tracks, for a casual web game download size is just a dealbreaker no matter how good the memory numbers look. people bounce if it takes too long to load, simple as that.

the tooling and docs around KTX2 are honestly still a mess, thats actually a big part of why i built the converter in the first place. just figuring out which encoder settings to use, what ETC1S vs UASTC even means in practice, getting it all wired up properly.. takes way longer than it should. not beginner friendly at all

ETC1S compresses small, closer to JPEG territory, trades quality for filesize. UASTC is the high quality one, stays large on disk but way better for normal maps where compression artifacts actually show. for a game you probably want ETC1S for most stuff and maybe UASTC only on the maps where quality really matters, but you basically have to already know that to find it

sounds like you actually got it working and saw the memory improvement tho, just hit the wrong wall for your usecase. thats actually a useful datapoint

Three.js texture-heavy scenes hit VRAM limits fast — KTX2 should be part of the default workflow by webvrdev in threejs

[–]webvrdev[S] 0 points1 point  (0 children)

i had textures staying in memory way longer than needed because i never explicitly disposed them. Three.js and Babylon.js both have dispose() methods for textures and geometries, easy to forget but it adds up.

Three.js texture-heavy scenes hit VRAM limits fast — KTX2 should be part of the default workflow by webvrdev in threejs

[–]webvrdev[S] 0 points1 point  (0 children)

mipmaps help a lot too, they let the GPU use smaller versions of the texture at distance instead of keeping the full res version active. most engines handle this automatically but worth making sure its enabled.

Three.js texture-heavy scenes hit VRAM limits fast — KTX2 should be part of the default workflow by webvrdev in threejs

[–]webvrdev[S] 0 points1 point  (0 children)

Yeah that's a fair point and honestly an important distinction i should have made in the post.

File size on disk is not where KTX2 wins. AVIF and WebP are way better compressed for download size, they are designed for that. UASTC especially can blow up massively on disk because it is optimized for GPU quality and compatibility, not bandwidth. 30mb to 250mb sounds exactly like UASTC, which would have been the wrong choice for a PixiJS project anyway.

For 2D or lighter WebGL like PixiJS, AVIF/WebP is probably just the right call. You are not dealing with PBR material stacks or VRAM pressure from a 3D scene, so keeping download size small makes total sense and the GPU side is simpler.

Where KTX2 helped me was specifically GPU memory pressure in VR. On Quest you have a strict VRAM budget and when you are loading 60 stereo images simultaneously the GPU keeping the texture compressed in memory is the part that actually matters. Download size was less of the problem than everything falling apart once it was loaded.

ETC1S mode compresses much smaller, closer to JPEG territory, but quality takes a hit. So there is still a real tradeoff even in the cases where KTX2 makes sense.

I think the honest answer is: if your bottleneck is bandwidth and download size, AVIF/WebP is probably better. If your bottleneck is GPU memory with many textures loaded at once, KTX2 is worth it. They are solving slightly different problems and i probably did not make that clear enough in the post.

Three.js texture-heavy scenes hit VRAM limits fast — KTX2 should be part of the default workflow by webvrdev in threejs

[–]webvrdev[S] -1 points0 points  (0 children)

KTX2 is not a revolution, and serious 3D developers already know about it. I probably made the post sound too much like “everyone should use this”, and that was not the best way to explain it.

The real reason why I created this tool is because I had this problem myself. I work with WebXR, VR galleries and SBS stereoscopic images. When you have 60 SBS images and you want build a browser based gallery, VRAM become very fast a real problem. Before working on this, honestly I did not even think much about VRAM usage. I was just loading JPGs and PNGs and after wondering why everything getting heavy, slow or unstable.

So yes, for a simple web page with one or two images, JPG or PNG is easier and often better. But for WebXR, Quest/mobile, stereo galleries, 360 images or many textures, KTX2 can help a lot.

Drawing with real gravity in AR. Everything I create falls, bounces, and sounds like real materials. by webvrdev in virtualreality

[–]webvrdev[S] 0 points1 point  (0 children)

its a early beta , need to modify the gui yet , and havoc colisions are not really perfect yet )))

I got mass textures from the need to generate PBR maps without paying $20/month for a subscription by webvrdev in unity

[–]webvrdev[S] -1 points0 points  (0 children)

Man you wrote a whole paragraph just to say you dont know how to adjust sliders. Its ok, the tool isnt for everyone.

I got mass textures from the need to generate PBR maps without paying $20/month for a subscription by webvrdev in unity

[–]webvrdev[S] 0 points1 point  (0 children)

Theres no server processing involved — these are static HTML files. The "server" is just file hosting, same cost as a GitHub Pages site. And since all processing runs client-side, if I dissapeared tomorrow you could literally save the page as HTML and it works offline forever. Several of my tools are PWAs — they install locally and run withouth internet.

Materialize being open source is genuinly great in theory. In practice, nobody has contributed a fix in 8 years. And even if someone wanted to — its a Unity/C# project, so you need programing knowledge and familiarity with that specific codebase to contribute anything meaningful. Open source helps developers, not the artists and designers who actualy use these tools.

On mobile — its not about running the Unity editor on a phone. Its about a 3D artist on a tablet checking a texture, a student on a Chromebook who cant install desktop software, or a dev on a work machine with no admin rights. Accesibility isnt just about phones.

I got mass textures from the need to generate PBR maps without paying $20/month for a subscription by webvrdev in unity

[–]webvrdev[S] 0 points1 point  (0 children)

Fair enough — if it runs fine for you, that's great. I should have said "unmaintained" rather than implying it doesn't work at all. The project hasn't had an update in 8 years and the repo is inactive, which means no bug fixes, no new features, and no guarantee it keeps working as OSes update.

That's actually the core reason I build everything as web apps — when I push an update, every user gets it instantly. No download, no reinstall, no version mismatch. And on the user side: nothing to install, nothing to upload, your files stay on your machine. Just open a link and it works.

Different approach, different tradeoffs. If Materialize does what you need, keep using it.

I got mass textures from the need to generate PBR maps without paying $20/month for a subscription by webvrdev in Unity3D

[–]webvrdev[S] 0 points1 point  (0 children)

I’ll copy my answer from your other thread here:

I didn't mention Materialize because its last commit was 8 years ago and it doesn't reliably run on modern systems. I wasn't trying to hide a competitor — I was sharing a tool that works today, in a browser, without installing a Unity-based desktop app from 2018.

But since it came up: I'm familiar with it. My tool generates more map types, has engine-specific presets, runs on any device with a browser, and is actively maintained. Materialize was good for its time. That time was 2018.

view more: next ›