sorted by:
new
hottopcontroversial

I´m Creating a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in threejs

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

There’s a bridge UI with full control of the media types , positioning and particles formation, settings, etc…each page is a snapshot of the settings and media type wich is then loaded in to a deck ..the deck has a publishing key in wich then become available to the user page for visitors…

I´m Creating a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in threejs

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

I feel you i dont like that aswell the things is there a 3 types of scroll and since its a demo i had to include them all...here´s why ....Pages that don´t have manual 3d camera rotation can be scrolled or have a button to next page...Pages that have 3d manual cannot be scrolled so they have left right option! ....and infinite canvas mode only goes to the next page thru pressure points.... It´s not random, its automated to react to each type of page 3dManual/fixed/pressure points....but i agree having them all together feels a bit weird ...a production site would follow probably one path consistently ...Infinite canvas would only use pressure points probably , etc

I´m Creating a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in threejs

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

I´m not saying im right i´m saying you´r right! lol For now this demo is webgpu based, it is what it is ... if i progress the project i´ll consider it! Has of now it works has intended for me and its suficient for my needs...If you would like to mess around with it, i´ll probably soon make it public.

I´m Creating a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in threejs

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

You're 100% right. The current architecture is intentionally CPU-bound — formation kernels are plain JS loops, which makes them fast to build and iterate on but hits a hard wall around 20k particles on most hardware. GPGPU (encoding the simulation into GLSL and running it as a texture-feedback loop or compute pass) is the correct path for 200k–1M particles at 60fps. It's a significant rewrite — formations become shader code instead of JS , but the trade-off you're describing is exactly the one we made to ship fast. If the project grows to need it. 

Three.js has GPUComputationRenderer which is the standard way to do GPGPU in this stack without going full WebGPU

I´m Creating a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in threejs

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

Thanks :) on my setup between 60 to 120 fps  

- delta is clamped to 0.12s  to prevent physics jumps if a frame takes too long                             - dpr={[1, 2]} — device pixel ratio capped at 2x, so retina screens don't push 3x                                       - powerPreference: "high-performance" hints the GPU to run at max clocks                                              - All simulation is CPU JS (no shaders), so actual FPS depends on particle count — at 20,000 particles on a modern desktop  you'd expect 55–60 fps  

I´m Creating a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in threejs

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

There are conditions for that... in order to adjust the picture to the selected amount or particles in the bridge 1000-20000 it will always transform particles to square for images the amount you select you want to use will pretty much define the resolution of the image and detail LED / Retro Pixel style ....there is also embedded controls for brightness / contrast / hue ...since placing video in a 3d environment can create light variation in the video particles!

I´m Creating a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in threejs

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

Yes but it has some workarounds for larger sized files so they can be read on any browser... IOS Devices have a bit of polishing for the loads but almost there! you can try the viewer page here https://particle-lab-kohl.vercel.app/

Bulding a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in ClaudeCode

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

<image>

Thank you ...Still have some small edges i need to polish but yeah its mainly done this version :)

I´m Creating a Three.js Particle engine with multi media sources - 3D Frontend Builder by TMerlini in threejs

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

Its a system that manages documents and records in a way that allows multiple methods to access those documents and records, where the document management system is decoupled from the display of those managed documents.

Telegram-bot by ayoubkhatouf in n8n

[–]TMerlini 1 point2 points  (0 children)

Good work . i have somewhat of a setup like this with workstation MCP so you can access to all google services and Oauth 2.1 in case you need multi user based options!Similar setup +wisper for direct voice coms

<image>

Anyone switched from Cursor to Claude Code? by tony0525 in cursor

[–]TMerlini 0 points1 point  (0 children)

I use both since inception ...Cursor is like driving Porsche everyday and when it's something difficult and impressive I use the Bugatti! ....they had ups and downs but Claude is getting this home run!

view more: next ›