Setting hotswap to on breaks the 3d model

[Neels-v-Wyk]

Problem + steps to reproduce

I just ran into this interesting case where if you take this configuration and toggle hot swap socket to on it completely breaks the 3d model.

Screenshots

I'll attach a screenshot of what I'm seeing just in case this bug cannot be replicated with the above links on a different client

hot swap socket off:

hot swap socket on:

Environment information

OS: macOS Ventura 13.6.1
Browser: Chrome 120.0.6099.216 (Official Build) (x86_64), with hardware acceleration enabled

[rianadon]

That's really odd and slightly horrifying. I tried your link as well as going to the first link and turning hotswap on, but all models look normal to me.

I tried Safari, Firefox, and Arc (Chromium-based) on macOS Sonoma.

I wonder if it's just a case of having the tab open too long and hitting some memory limit or something? It looks like the model generated alright, but the renderer decided to put the triangles wherever it likes.

[Neels-v-Wyk]

Interesting!

This problem still happens for me. Is there anything I can provide to help diagnose the problem? If not I'll close the issue seeing as it isn't reproducable

[rianadon]

I thought about this a little more and i have an idea of what's going on. Please confirm for me that the model downloads ok, because I think this is a rendering bug:

1. WegGL has a limit on the number of vertices you can put into a mesh. The hotswap sockets are pretty complex, so multiply them by 21 and you have a lot of vertices. If my calculations were correct there are 185k.
2. Different hardware probably has different WebGL limits. I guess my laptop supports more vertices (I'm using M1 which has a different gpu)?
3. It would be difficult to fix this, since there's no obvious way to split the model into chunks for rendering.

If you'd like to do some digging into the WebGL yourself, I'm using Spector.js extension for debugging.

After clicking record then moving the keyboard around to trigger a redraw, this is what I see under the draw command:

Dividing buffer length by the stride gives 185k vertices.

Also under the information tab there's information on the maximum numbers of elements supported: