In case you weren’t aware of this bug, AA renders weirdly against a neon background.
1 Like
Is this new since this release or not? Can you post a model with a repro?
I am fairly certain that it’s happened since AA was released. But it’s more apparent on smaller parts/meshes, though not specific to. I’d like to note I am also using a few of the new pixel shaders as shown in the file below.
Here’s the model:
AABugRepro.rbxl (212.0 KB)
Would appreciate people not taking credit for it by making it a model under their name.
Can confirm with latest version of studio.
Ok, gotcha - thanks! Looks like the ambient occlusion bug (we apply AO to neon parts which should not happen, and you have a variant of the same issue for AO but exaggerated due to glow).
1 Like
List of currently known issues:
- Bloom affects UI which results in issues with chat bubbles
- In some cases you can see single-pixel white halo around objects on quality 10
- Handles, SelectionBox and other semi-transparent adornables have a slight glow when Neon parts are visible
- In some cases you can see single-pixel halo on neon objects on quality 10
I have fixes for the last two issues; we’ll ship them soon-ish (in ~2 weeks).
2 Likes
Not going to lie, I am a fan of the Adornables having glows. Any possibility this could become a feature?
2 Likes
Yeah. @zeuxcg it seems very fitting having the ArcHandles glow a bit. I really like it, especially against dark background or in a distance or amongst similar-colored bricks or any handful of scenarios.
1 Like
But they don’t really glow all the time. And when they do it’s entirely by accident 
We currently don’t have a good mechanism to actually make it work properly - I’ll just fix it for now.
2 Likes
How much performance does the blur effect even take? I don’t see how it could be that much of a performance killer but correct me if I’m wrong… I wish it was something that you could see on all levels of graphics so that it could actually be of some use in transitions, etc. in which seeing the blur is crucial. Or at least have some other method of blurring the screen (other than using a neon part) or even a frame like mentioned earlier that blurs a specific part of the screen while not affecting performance.
A blur basically means that, for every pixel, you take the average of the values in itself and the neighbouring pixels. This is a costly operation to be performing. If you blur with a 3x3 sampling or pixel neighbourhood, you have to take maximally 9 values into account for every pixel in every frame, instead of just 1. This doesn’t scale well for bigger blurs either. (9x9 = maximally 81 values, 15x15 = maximally 225 values, etc, it scales super-linearly)
Nothing in the previous statement is true, unfortunately 
.
It’s not really averaging, it’s not costly, because it’s not on every pixel, and 3x3, 9x9 or 15x15 blurs don’t really convolve against 9, 81 or 225 pixels respectively.
1 Like
I understood it wouldn’t be implemented exactly as I said, it was more as a simple example as to why the compute load may be higher than other effects (since most other effects (seem to) only need the data of a single pixel to render said pixel, while a blur effect would require more information than that (either multiple pixels or multiple samples of the same scene)).
Can you elaborate on how it’s done, if it’s not some kind of convolution/correlation or combination of multiple samples? I’m pretty interested in this kind of stuff.
The blur is performed on a render target that’s 16x (4x in each dimension) smaller than the main framebuffer. It’s also separable, meaning that in two passes combined, a 56-pixel blur has to only make 14 (highly texture cache coherent) lookups per texel, 7 per pass.
1 Like
Okay, that makes a lot of sense to me, two passes with 1D filtering instead is of course faster, should have thought about that.
Is this 14 and 7, or 28 and 14? If you have a filter of 56-pixel blur that would be 14-pixel in the smaller render target in both dimensions, so 14 lookups per pass per pixel and 28 in total right? I see your main point either way, that it’s much less lookups than I mentioned, thanks for elaborating.
Yes, it’s actually 14 per pass, 28 total, my mistake.
Not sure if this is the place to toss up suggestions for new PostEffects, but I’ll throw some things that I’d really like to see in the future:
- FilmGrainEffect
- Applies configurable noise/grain to the screen
- ChromaticAbberationEffect
- Pretty self explanatory, adds configurable chromatic aberration
- ImageDistortionEffect
- Includes several parameters to distort the rendered image, such as a Twirl effect, a Vortex effect, or a Fisheye lens effect?
Thats just my personal wish list.
30 Likes
Forgot to update this thread last week. These two issues have been fixed:
- Handles, SelectionBox and other semi-transparent adornables have a slight glow when Neon parts are visible
- In some cases you can see single-pixel halo on neon objects on quality 10
Additionally, there were some optimizations (gaining ~30% performance) and quality improvements (mostly for terrain) for SSAO that also went live last week. I’m still not quite happy with our SSAO but that’ll have to do for now.
3 Likes
SSAO = the shadows that appear when parts get close to each other to exaggerate the edge and give it a sense of depth
(at least, that’s what I found in another topic, but it’s probably the same thing that’s being talked about)