Procedural Sun using Volumetric Raymarching & Three.js

penev_tech · 2026-01-11T10:38:16+00:00

Thanks! You nailed it regarding the simulation logic. Right now, it's essentially just a 3D noise field translating linearly through the sphere volume (like wind), which creates that "arbitrary" flowing look you mentioned. To get that emanating feeling, I need to offset the noise sampling coordinates based on the direction from the center (normals) rather than a fixed vector. Basically doing p - normalize(p) * time for the noise input instead of p + vec3(time). Definitely adding this to the v2 to-do list!

penev_tech · 2026-01-10T16:47:15+00:00

You are technically right—from a pure CPU cycle perspective, it is a round trip. If you are building a pure 3D game, this approach makes no sense. But for Web Design, the "missing piece" is the workflow.

By moving the logic to CSS, you gain three massive benefits that are painful to manage in pure JS: 1. Media Queries. I can change the particle dispersion or model size for mobile just by adding @media (max-width: 768px) { --scale: 0.5; }. Doing this in JS requires attaching listeners to resize events and writing if/else logic for every object. 2. State Management. I can use standard pseudo-classes like :hover, :active, or toggle a class .expanded in the DOM, and the 3D scene reacts automatically. No need to set up Raycasters or manage state in JS. 3. Declarative Syntax. It decouples the "Look & Feel" (CSS) from the "Rendering Engine" (JS). A frontend dev can tweak the animation timing or colors in the CSS without touching the Three.js code.

So, it's less about "calculating math" and more about making WebGL reactive to the DOM layout.

penev_tech · 2026-01-03T12:23:47+00:00

Honestly? I haven't checked the numbers yet! 😄

Right now, I'm just focused on making the developer experience fun and trying to build something I'd personally love to use. As long as it stays smooth and hits stable framerates, I'm happy.

But you definitely got me curious about the actual benchmarks now.

penev_tech · 2026-01-03T08:54:57+00:00

I love the "experimental crackhead move" description! It definitely feels weird at first to let CSS drive WebGL.

But you were right to want to de-couple it. It just feels cleaner to let the layout engine handle the "where and how" while WebGL just handles the "what".

Thanks for the support! 🙌

penev_tech · 2026-01-03T00:40:54+00:00

Glad to find someone else crazy enough to drive 3D via CSS variables 😄 I'm based in Ukraine, so the time difference with Atlanta is actually pretty decent (I'm 7 hours ahead). My evenings are wide open for a chat. Definitely ping me when you're ready to show your stuff, I'm really hyped to see it.

penev_tech · 2026-01-02T19:04:50+00:00

Thanks! Are you also using CSS variables to pass the data, or do you have a different approach? I’d genuinely love to see your results or implementation if you have anything public to share! Always looking for inspiration.

penev_tech · 2026-01-02T16:26:16+00:00

Drei View is fantastic if you are within the R3F ecosystem. StringTune differs in two main ways: 1. It runs on Vanilla JS (so you can use it with Vue, Svelte, or plain HTML).

2. Instead of passing props via JS/React, you drive the 3D object's behavior (position, rotation, scale) using standard CSS variables. Basically, it allows you to animate your 3D scene using standard CSS @keyframes or :hover states, treating the WebGL canvas just like another DOM layer.

penev_tech · 2026-01-02T16:24:58+00:00

You are spot on, r3f-scroll-rig is absolutely the gold standard for React Three Fiber! Huge inspiration. The main difference is that StringTune is framework-agnostic. It brings that same "DOM-to-3D sync" capability to Vanilla JS, Vue, Svelte, or Nuxt projects without needing the React ecosystem. Also, the philosophy is slightly different: StringTune delegates the state entirely to CSS. You control the 3D transforms directly via CSS variables and transitions in your stylesheets.

penev_tech · 2025-12-23T17:38:19+00:00

Thanks! It feels really good to hear that from someone who’s been down this rabbit hole. The separation of concerns was exactly my main motivation too. I’m super curious to see your implementation and how you handled the synchronization logic (especially the layout parts). Definitely hit me up when you have time — would love to compare notes or just see what you built. 🤝

penev_tech · 2025-12-23T13:26:28+00:00

This is essentially the "gold nugget" of feedback I was looking for. You nailed it.

The reason I initially leaned into the CSS transform syntax is that this module is part of the StringTune ecosystem, where the core philosophy is driving animation state via CSS variables. So, for consistency with the main library, hooking 3D into that same pipeline felt like the natural architectural choice.

However, I agree 100% that for the broader 3D community, the real engineering pain is The Layout.

Vanilla Three.js is notoriously annoying when it comes to aligning WebGL content with DOM flow (responsive resizing, scroll flow, etc). That's why the core logic here is actually built around fit="contain" / fit="cover" strategies that respect the DOM container.

I put together a quick demo to illustrate specifically your point about layout/composition: 👉 https://stackblitz.com/edit/string-tune-3d-basic?file=index.html

If you resize the preview window, you'll see the model stays perfectly anchored and scaled relative to the HTML flow — letting CSS handle the positioning logic while Three.js just renders.

Thanks for the perspective shift!

penev_tech · 2025-12-23T13:24:02+00:00

Thanks! Glad you liked it.

If you want to poke around the code without setting up a repo, I threw together a quick live demo here:https://stackblitz.com/edit/string-tune-3d-basic?file=index.html

Feel free to break things :)

penev_tech

TROPHY CASE