Beam Optimization is Wrongly/Poorly Implemented

Beams are optimized based on the current user’s graphics level setting. This is fine, however the optimization is wrong or incorrectly implemented. Beams with low segment sizes become ‘invisible’ at low graphics levels.

Based on my observations, I believe that the current optimization for beams does not check the Segments property value before lowering the segment count. I also believe that the segment reduction is a division by an integer set by the graphics level.
At level graphics level 1 (minimum graphics level), it seems that this divisor is 10. So a beam with 20 segments gets reduced to 2 segments, a beam with 50 segments gets reduced to 5 and so-forth.

This results in developers having to create significantly higher-poly beam effects so that they can be assured that they will render at lower graphics levels.

Here are some screenshots showing the Studio quality level and the beam’s wireframe rendering. The white beam is 20 segments. The red beam is 50 segments. The blue beam is 10 segments.

Max Quality

Min Quality

Notice how the blue beam does not render at all in minimum quality.

A beam which only necessitates 4 tris should not be forced to 40 tris.

Expected behavior

At the very least, I expect that Beams’ Segments property should be checked before the optimization is applied, and only apply the optimization if it will not completely de-render the Beam. This means not dropping the Segments count to less than 2.

Ideally I expect a much better optimization implementation than simply dividing Segments by a static divisor, but I understand this is more time consuming.

11 Likes

FWIW I have several waterfalls in my game that I remember intentionally designing so that the lowest quality level would still look acceptable, there was always at least one segment on the lowest quality level with only a few segments set in properties, so this must have changed recently, or this issue is specific to something with your setup.

Btw you don’t need to write so much implementation speculation, just the issue itself is fine.

It might have changed but I do remember this being an issue in the past. I don’t think I’m doing anything odd. I was using beams for their LightEmission property as bullet tracers. I’m not using the curve properties at all.

I gave the speculative details only to aid the engine staff. They have limited time and there’s no guarantee the person who reads it is familiar with the implementation.

I tested it at varying quality levels to come to my conclusion and decided against showing all levels to prevent the post from growing even larger.

All good, just providing for context. I set these waterfall beams up 2 or 3 years ago

1 Like

This is just an acknowledgment announcement!

We’ve filed a ticket into our internal database for this issue, and we will update you when we have further information!

Thanks for the report!

1 Like

Hi Cuyler. Thanks for the report.
Could you provide a .rbxl file that contains the beams you show in your images? This can make our debugging process much quicker

1 Like