So this one follows straight on from the Performance Mode article a few days ago. That was about making the budget mode look better without costing anything. This is the same question pointed the other way, because it turned out the default mode was quietly asking far more from people's computers than it had any right to, and the fix was switching off two effects I spent a lot of last December lovingly tuning.
Quick context if you are landing here fresh. EF-Map is a free interactive 3D map of EVE Frontier, and the starfield is roughly 24,000 star systems drawn in the browser with Three.js and WebGL. The stars are point sprites in a single THREE.Points object, which is about the only sensible way to draw that many, and on top of the cores sits a stack of effects that has built up over eleven months. A parallax nebula backdrop, distance fades, HDR bloom, and the two this article is mostly about, star glow and star flare.
Glow and flare are old. They arrived in December 2025, and at the time they were the whole show, because bloom did not exist on the map yet. Each one is a full copy of the starfield drawn as additive sprites, a soft halo per star and an angled lens streak per star. They are also, it turns out, the most expensive thing the map draws, and for a while now they have been contributing almost nothing you can actually see.
The slider that started it
The thread started with bloom, not glow. Bloom on EF-Map is ranked by real stellar temperature, so a red dwarf gets a 1x brightness boost and the hottest blue giants get about 6x, and a threshold slider decides how bright a pixel has to be before it glows. Some bloom work earlier in the week moved the scale that threshold sits on, and the old default of 0.7 ended up above almost every star core on the map. Hot stars up close had quietly stopped blooming. The fix was almost embarrassing, the default is 0.25 now and it applies to existing settings too. But it meant I spent a morning zoomed into dense clusters with Task Manager open, staring at stars. That turned out to be the useful part.
500 stars and a pinned 4070 Super
My test spot for anything starfield is always the same, the densest cluster I know of, which puts something like 500 stars close to the camera at once. It is the worst case on the whole map, which is the point. Moving the camera quickly through it was maxing out my RTX 4070 Super, pinned to hold about 70 frames a second. That is a card that runs the actual game comfortably, flat out on a map website. Then I dragged the star glow sliders down to nothing and watched the usage collapse. Same cluster, same camera movement, and now I struggle to push the GPU much past 15 percent.
I assumed the cost was draw calls, because glow is per star and 24,000 of anything sounds like a draw call problem. Wrong. The whole glow layer is one draw call, the flare layer is one more, three in total with the cores. What actually costs is fill rate. Every star gets drawn three times, and the glow and flare copies are additive point sprites that scale up as you get close, capped at 1024 pixels across, more on high-DPI screens. Zoom into a dense cluster and hundreds of near stars each stamp a huge translucent quad over the screen, all overlapping, and the GPU shades every covered pixel of every quad and blends them all together. Overdraw, basically. The cost scales with how many stars are near the camera, so a quiet corner of the map costs nearly nothing and the one spot everybody zooms into costs everything.
Invisible, and fully paid for
It gets worse the closer you look. Glow has a distance setting, 2000 units by default, and it reads like a performance limit. It never was one. Beyond that distance the shader faded each sprite's opacity to exactly zero and then rasterised the quad anyway, full size, full per-pixel cost, contributing nothing. Invisible glow, fully paid for. That particular sin is now fixed in the vertex shader regardless of any defaults, sprites with zero opacity collapse before they reach the rasteriser, so the distance slider is a real cost control for anyone who runs the effects.
And then there is what the visible part was actually contributing. The glow sliders get scaled down hard to survive additive blending, so the default setting worked out at an effective opacity of about 0.0007 per star. Individually invisible. The only place it ever registered was as a faint haze where hundreds of near sprites overlapped, which is exactly the situation where it was melting the GPU. The most expensive effect on the map was one you could barely see.
Bloom does the same job for a fixed millisecond
The reason glow survived this long is that it used to carry the whole look, and the reason it does not need to any more is bloom. Bloom here is Three.js's UnrealBloomPass running on an HDR render target, and being a screen-space effect it has no idea how many stars are on screen. It finds bright pixels and spreads their energy into a halo. When I measured it for the last article it cost about a millisecond a frame at 1080p, and it costs that same millisecond whether one star blooms or a thousand, parked or flying through the cluster. A fixed cost carrying the same information the sprites carried at a density-scaled cost. And because the temperature boost lives on the star cores themselves, hot stars still outshine cool ones with the sprites gone.
So the defaults changed today. Star glow and star flare now ship at zero for everyone. The reason I say that so bluntly is the thought I could not get past once I had seen the numbers. If the default settings can pin a 4070 Super, then somebody on a 3060, or on integrated graphics, is going to zoom into that same cluster, feel the map chug, and conclude EF-Map is badly optimised. They would be wrong in a way I never get a chance to explain, because the map was optimised, it was just spending the whole budget on a haze. A map is a tool first. Its defaults should not assume enthusiast hardware, and I probably should have checked what the worst-case view cost a lot sooner.
Cinematic Mode made it an easy decision
What made this an easy call rather than a sad one is that the spectacle has a proper home now. For most of EF-Map's life the real split was Performance Mode and default, and default was where the beauty lived, because Cinematic Mode was the oldest feature on the site and honestly a bit meh. Then it got rebuilt a few weeks back and kept growing, volumetric interstellar gas, supernovae, a directed auto tour. There is even a Cinematic Effects toggle in Display Settings that runs that visual stack on the normal map while you work. So the default view no longer needs to be the showcase. It can be the fast legible tool it always should have been, and the showcase is one toggle away.
I will be honest about what is lost. The additive build-up of hundreds of overlapping halos in a dense field had a depth to it that bloom does not replicate, and the flares had a per-star angle I liked. Nothing was deleted though. Every slider is still in Display Settings, so the old look is thirty seconds away if you want it for a screenshot, and if I ever find a cheaper way to draw them they can go straight back into the defaults. That is the entire argument for switching things off instead of ripping them out.
The camera that never stopped
One more thing fell out of the same day, because once you start hunting wasted GPU you keep finding it. I had noticed a faint shimmer washing across distant stars just after the camera stops. It turned out the camera never actually stopped. The orbit controls damp their momentum exponentially, which never quite reaches zero, so after every single gesture the map kept rendering at full frame rate for about another second, drawing camera motion well under a tenth of a pixel per frame, and those sub-pixel shifts were popping borderline stars in and out of bloom's bright pass. Movement nobody could see, rendered flat out, wobbling stars that looked stationary. The camera now snaps fully to rest the moment the leftover motion drops below anything perceptible. The glide you can see is untouched, the feel is identical, and every camera gesture costs about 50 fewer full-rate frames than it did last week.
So the map got visually simpler this week and I think it genuinely got better, which is not a sentence I expected to write back in December when I was tuning flare angles at midnight. If you run your own Three.js scene with a dense THREE.Points field and additive sprites layered on top, I would suggest opening Task Manager on your densest view before trusting your instincts about where the cost is. Mine were wrong twice, once about draw calls and once about what the effect was even contributing. Anyway, it is all live now. If the starfield looks flatter than you like, the old effects are waiting in Display Settings, and if the map still runs badly somewhere I would like to hear about it.