Engine's antialias option has no effect

Questions
,
1

Hello all, I am trying to use antialiasing, but I found setting it on creating engine has no effect to framerates.

// ...
// disable antialias
var engine = new BABYLON.Engine(canvas, false, {
        antialias: false,
// ...

// ...
// enable antialias
var engine = new BABYLON.Engine(canvas, true, {
        antialias: true,
// ...

See Enable antialias PG and Disable antialias PG.

You may increase the numInstances at the beginning to slow down the rendering, so that there should a gap between enable antialias or not.

const numInstances = 10000; // increase it to slow down
const numQuadsPerInstance = 128;
// ...

Thanks!

2

Hi,
I believe the default for MSAA to be set to 4 samples, which will have little impact on performance. Correction, as per the doc the default is 1 even when not called but I believe it to be 4 when enabled. Although, may be it is still 1 unless you set the samples. Iā€™m not all too sure :face_with_hand_over_mouth: By any means, 4 samples doesnā€™t do much and I believe will have very tiny-mini incidence on performance.

I opened the scene on my legacy test rig (a 2009 mac-pro with 1GB medium range GPU).
With MSAA set to 4-samples I get about the same FPS as with 1 sample (around 25 fps). However, pushing MSAA to 64 samples, performance drops to ~15fps.

Edit: and then may be youā€™ll want to add FXAA ? MSAA is not the outmost for antialising (my opinion only, of course).
https://doc.babylonjs.com/features/featuresDeepDive/postProcesses/defaultRenderingPipeline#antialiasing

1 Like
3

Thank you @mawa. I conducted some tests, and it appears that the default sample value being 1 can explain this issue. If the sample value is not increased to a number larger than one, there is no difference compared to turning off antialiasing.

I was trying to determine the performance gap between Babylon.js Gaussian Splatting and PlayCanvas (this thread). By asking this question, I was doubting if there was some sort of antialiasing that I had not turned off, causing a drag on performance.

Problem solved now. Thank you!

1 Like
4

Yes, I saw this thread. Weird thingy. Seems to mostly affect mac. I doubt MSAA has anything to do with it (but worth exploring anyway :sweat_smile:) Anyways, I hope someone will eventually figure thisā€¦ and meanwhile, have a great day :sunglasses:

5

Thank you! BTW, do you know why in your DefaultRenderingPipeline sample, if I set HDR to false, the framerate decreases?

// hdr on
var defaultPipeline = new BABYLON.DefaultRenderingPipeline("default", true, scene, [camera]);
// hdr off
var defaultPipeline = new BABYLON.DefaultRenderingPipeline("default", false, scene, [camera]);
6

Nope, sry. I can only assume that it has been made for HDR. Else, would need to undergo some further calc/computing. Iā€™m afraid Iā€™m just not qualified for this.
Best would be to ask an expert @sebavan

Edit: Found this single line in the doc that says in substance that ā€œit should be set to trueā€ and else would be a ā€œcheap fallbackā€. Not sure how to translate this technically :grin:

1 Like
7

Haha thank you, I got this note too. Have a nice day.

1 Like
8

you render to float instead of bytes and always have a final post processing to apply gamma correction and similar so it requires more compute.

2 Likes
9

Thank you @sebavan, I created three PGs here

PG1 - Render without pipeline
PG2 - Render with a DefaultRenderingPipeline, HDR disabled
PG3 - Render with a DefaultRenderingPipeline, HDR enabled

The framerates on PC are 30, 30, 32 respectively, while on my Mac they are 20, 20, 60. I can understand that using half float framebuffer can be more performant than a unsigned_int one. But this gap is quite huge.

Do you know how can I achieve this performance without using a pipeline or RTT?

BTW, the framerates on PC are using numInstances = 250000, while the framerates on Mac are using the default numInstances = 10000. Because I cannot find a proper value to show performance issue on both platform.

I am just trying to compare inside each platform.

10

It seems that the better performance of HDR against non-HDR is not related to texture format.

I tried using half float in a non-HDR condition, and disable hdr on creating the DefaultRenderingPipeline, the framerate did not change.

// defaultRenderingPipeline.ts
// ...
        // Misc
        if (this._hdr) {
            if (caps.textureHalfFloatRender) {
                this._defaultPipelineTextureType = Constants.TEXTURETYPE_HALF_FLOAT;
            } else if (caps.textureFloatRender) {
                this._defaultPipelineTextureType = Constants.TEXTURETYPE_FLOAT;
            }
        } else {
            // change this to TEXTURETYPE_HALF_FLOAT
            this._defaultPipelineTextureType = Constants.TEXTURETYPE_UNSIGNED_INT;
        }
// ...

This makes me confused. Why does enabling HDR, which involves an additional pass, result in better performance?

11

Wow, these numbers between mac and pc are really something. Just to make this clear, when you say ā€˜MAC vs PCā€™, do you mean on the same rig (using bootcamp), same hardware, same specs?

1 Like
12

Sorry for my unclear expression. I am not using the same hardware. :rofl:

I am not trying to compare Mac with PC; I am trying to find out why enabling HDR on Mac will result in a huge framerate increase, while this increase does not occur on PC.

My PC is much powerful than my macbook, and the PC framerate is tested using much more numInstances.

// for my Mac
const numInstances = 10000;
const numQuadsPerInstance = 128;

// for my PC
const numInstances = 250000;
const numQuadsPerInstance = 128;
1 Like
13

May be worth checking it out on the same rig. If I get a minute for that later today or tomorrow, Iā€™ll do it on my rig (which is a reasonable/avg gaming rig/notebook - a macbookpro 2020 with 4GB GPU and bootcamp installed with WIN10). This isnā€™t a promess (Incidentally, Iā€™ve got plenty of things to do during these holidays :sweat_smile: :joy:)ā€¦ but it would be interesting to have this just for the sake of ā€˜consistencyā€™ā€¦ however, as you say, the gap seems like it is absolutely huge.

1 Like
14

Thank you! :heart: As you suggested, I run the three PGs above on a 1080p plugged in screen for my MacBook, and update numInstances to 30000 (because they all 60fps with 10000 instances), their framerates are now 30, 29, 60.

1 Like
15

Thanks. A step forward, I suppose. The first number is the one that worries me a little (providing it is the non-post set version, is it?). All I can think of to explain this number (that is extremely close to the non-HDR post - number 2, is it?) would be that the ā€˜non-HDR postā€™ (in other words 'default rendering pipeline with hdr set to ā€˜falseā€™) would actually be running on the engine :thinking: :dizzy_face: (despite from being unset???)

16

Your guess is correct. I captured with Spector.js, and if HDR is set to false, then the scene is rendered directly to the canvas without any post-processing.

Itā€™s just I thought post-processing should only slow down the renderingā€¦ but here, itā€™s the contrast.

1 Like
17

Hum? Well, I suppose once you know about it then you know :grin: Probably still space for improvement around there :smile: :face_with_hand_over_mouth:

1 Like
18

Playgrounds 1 and 2 will be equivalent cause in LDR mode the post processing step is useless so you end up with the exact same runtime code explaining the similar values you are seeing.

Playground 3 should be slower as it is drawing in a texture first and then bliting it.

Are you only running the playground as they are to experience the diff ?

I wonder if it could be cause you disable depth test in the canvas in your engine creation leading to loads of overdraw in this particular scene for case 1 and 2.

If rightly configured the 3rd case should be substantially slower due to the extra off screen texture being used.

1 Like
19

Yes, these playgrounds can help you experience the difference, but on Macā€™s retina screen only, If all of them are running full framerate, maybe you should increase numInstances until one of the playgrounds is running below the full framerate; that way, the difference could become visible.

I believe the depth test should have no effect since it is disabled in all three playgrounds. The performance gap only exists on high-resolution MacBook screens (not on PC 1080p or external screens connected to the Mac).

If rightly configured the 3rd case should be substantially slower due to the extra off screen texture being used.

And this is exactly what I want to find out :joy: Why in my PG adding a pass would speed up the rendering.

20

This is not the case. In the 3rd case you have a separate pass that relies on depth test. To compare apple to apple you should enable it in the canvas options for case 1 and 2 so overdraw could also happen.

1 Like