💨 STEAMFORGE v1.2
The room fog costs a tenth of what it did, and the water on the body stops stuttering the collector. Same look.



In one screen

v1.1v1.2change
EnvFog, factory settings (two-person field scene, 8K, scene lighting on, over the empty floor)+15.47 ms (24 steps)+1.50 ms (2 steps)−90%
Picture, 24 steps vs 2 steps, bath steamsame
SkinWater, allocation per frame (all three effects)28.3 KB8.7 KB−69%
SkinWater, frame time+2.00 ms+2.01 msunchanged (by design)
The whole field scene, all three Forge plugins at factory settings36.35 ms · 27.5 fps12.53 ms · 79.8 fps−65% (with LumenForge v1.4 and GlassForge v1.1)
[TD colspan=2]not tellable apart side by side; 1 step changes the texture[/TD]

Defaults changed : EnvFog Quality 24 → 2 (slider floor 4 → 1). One new control : Aux camera quality. Saved scenes are untouched.



📋 Changelog

PluginChangeWhat you see
EnvFogQuality default 24 → 2, slider floor 4 → 1 (shader clamp lowered to match, bundle rev 8)Same look at normal density. 1 step shows grain; Person interaction wants ~8 or more because body holes are sampled per step.
EnvFogNew : Aux camera quality (default 4). Cameras other than the scene view use min(Quality, this).Nothing in the main view. A GlassForge transmission render, a WindowCamera or a screenshot rig no longer re-marches the fog at full Quality.
EnvFogReport text readable by other plugins (report, not saved)Nothing. Bench tools can verify the live shader build.
SkinWater · dripsBead births ride the 200 ms skin-subscription cadence instead of each forcing an engine re-planNothing. Same rate; a birth waits at most one tick, behind the 3-frame warm-up that already hides it. ~70% less garbage per frame.
SkinWater · dripsThe staleness gauge and set-change comparison (development instruments) are gated off in the shipped buildNothing. About 0.5 MB less resident memory and a few hundred square roots per frame fewer.

Not changed, on purpose : EnvFog and Body Steam still request the camera depth texture when they load and return it only when removed. Clearing it on a toggle would silently break other plugins that share the flag (a 2026-08 ruling, unchanged).



Where it came from

A player reported a published SteamForge scene at 30 fps on a Radeon 7900XT, GPU at 100%, and that switching the steam off gave them 50% more frames. The room fog was 53% of everything the three Forge plugins cost in that scene, and almost all of it was the step count.

The raymarch does a great deal of work per step (three octaves of noise, and with scene lighting on, a four-light scatter loop), but nothing the eye sees depends on the count : the box crop, the depth clamp against people and walls, the height falloff and the total opacity are all computed exactly regardless of steps. So the number came down until the picture changed, which was at 1, and it ships at 2.



🔬 QA : the ladders

Two persons, HeroRay, GlassForge pane, water. 8K DSR, RTX 5090, six passes of ten seconds per row with a four-second settle, VAM panel closed, camera pinned by the scene's spawn point.

EnvFog alone, over the empty floormsvs v1.1 default
48 steps+24.84+9.4
24 steps, scene lighting on (v1.1 default)+15.47
24 steps, lighting off+12.75the lighting term : −2.71
8 steps+4.74−69%
4 steps+2.57−83%
2 steps, scene lighting on (v1.2 default)+1.50−90%
2 steps + Person interaction+1.63interaction : +0.13 at this count
1 step+1.01texture changes here

0.507 ms per step on this machine at 8K, linear from 48 down to 1.

Aux camera quality (fog at 24 steps, GlassForge transmission at 2048)ms
Aux quality 48 (every camera marches full Quality)21.21
Aux quality 4 (v1.2 default)20.76 · −0.45
In a scene with a 4096 transmission render the same effect measured 7–8 ms during development; at the field scene's 1024 it is small, which is why the control exists rather than a fixed rule.

SkinWater, before → after (same scene, old source swapped back in for the "before" run)frame ms over floorallocation per frame
All three effects+2.00 → +2.0128.3 KB → 8.7 KB −69%
Drips only+1.56 → +1.8225.4 KB → 8.4 KB
Drips, Wet trail off+0.21 → +0.1822.5 KB → 6.6 KB
Splash only · Steam only≈ 0 · ≈ 0≈ floor · ≈ floor
Frame time did not move because the drips' cost is the wet trail itself, exactly as the README already says; the change was about the collector, and the periodic stall now comes about a third as often.

Gates : the drips module is regenerated from its development source by a script and re-verified byte for byte; both plugins pass the offline compile check; the capability ledgers match (SkinWater 62 IDs, EnvFog 40).

The field scene, every sweep table and the raw rows are archived with LumenForge's dev logs. Nothing here was estimated; rows that could not be separated from the floor are not on this page.



🧰 Updating scenes you already published

Two things carry over from an old scene and are worth a minute :

  • The package reference. A scene saved against Shadow Venom.SteamForge.2 keeps loading v1.1 even after you install v1.2, because VAM pins script references to the exact version. Re-point the plugin to SteamForge.3 in the atom's Plugins tab (or re-add it), then save.
  • An explicit EnvFog Quality value. Scenes that never touched the slider get the new 2 automatically. Scenes where you set it (24, 48 …) keep that number.

Every ForgeLab package now ships ForgeLab_Updater.cslist, a temporary tool for the second point : load it on an Empty, press Scan, read what it found, press Apply, save the scene, remove it. It moves EnvFog Quality and HeroRay Beam steps from the old factory values (24 and above) onto the new ones, only on instances that are already running the updated packages, and leaves anything you had set below the old factory value alone. Undo restores the session's values, and a log is written to Saves/PluginData/ForgeLab/.



Known limits

  • Very thin fog with high Detail shows the 2-step dither as grain. Raise Quality; the cost is linear.
  • Person interaction at 2 steps samples the body hole twice per ray. Raise Quality toward 8 if you use it.
  • A step change of pose (loading a pose preset) still leaves drips on the old shape for up to 200 ms. That is the subscription cadence from v1.1 and is unchanged.
🆕 What's new

v1.1

A feature requested by @Mm3. Thanks for the feedback!

  • 🚹 Drips now work on male and futa characters, and on any character the old build silently got wrong. The symptom was unmistakable once you saw it: the water ran down an invisible figure standing in the default T pose, while your character moved somewhere else entirely. It read like a male support problem, and it was not one. There is no male or female branch anywhere in this plugin and never has been. VAM stores how a character gets skinned inside the character asset itself, there are three possible settings, and the code only handled two of them. Stock Male 3 ships with the third. Any character built that way was affected, whatever its gender; male characters are simply where you were most likely to meet one, because a Person starts out female and picking a male character is what swaps the asset.
  • 🔄 Changing the character at runtime no longer strands the water on the old body. Every character in VAM carries its own skin object, so switching character or gender hands the engine a different one. The drips held on to the previous character's skin, which stops being animated the moment it is swapped out, so the water froze onto a body that was no longer there. It now notices the swap and re-attaches, and the same fix covers a scene whose character finishes loading a moment after the plugin does.
  • 🎛️ Seven greyed out explanations on the Body Steam page are actually showing up now. Sliders that cannot do anything in your current setup are supposed to grey out and tell you which switch they are waiting on. On that one page they never appeared, so the sliders sat there looking live. Reset also moved above the Amount slider it resets, and Trail style now greys out when Wet trail is off.
  • 🔎 The Report button tells you more, and lies less. It now names the character, says whether it is still attached to the live skin, and prints the skin method it is reading. Several of its own measurements were reporting nonsense on healthy scenes, including a placement warning that fired on bodies that were positioned perfectly. If you have ever pasted a report into the discussion thread, the next one is worth more.
Back
Top Bottom