Material Draw calls reducer

That statement couldn’t be any further than truth. What is important that CPU can accomplish all the given tasks in a time period that your monitor refreshes itself. In my test page, using a 6 year old desktop with average specs, Chrome can handle 20000 draw calls per frame requesting material index while maintaining 60 FPS.

The point is, when it comes to draw calls, the time to fulfill these calls is important NOT the number of calls.

I hope I made it easy for you to understand what I’m trying to say.

1 Like

Yes, agreed. It will help, specially mobile devices.
Definitely a useful asset.
Just wanted to let you know these calls on material index are very short, ( about few micro seconds )

I don’t know why 60 fps and 20.000 draw calls in three.js. Maybe good computer or not render loop.
Here 12 fps then set method naive and 10.000

Do you have a demo of chrome running 20k draw calls?

I get around 73 fps

1 Like

Super computer. Unlimited “requestAnimationFrame” to 60 fps.

what language is this?

Screen Shot 2021-08-29 at 12.17.09

1 Like

Russian, apparently.


Ha, the answer is actually quite banal, the requestAnimationFrame is limited to the refresh rate of your screen, which in my case is 144Hz, or 144fps.

There are a number of caveats to that, but this is generally true. Part of the reason why I got a “high refresh rate” screen is to be able to test my work at higher than 60 FPS.

but why? for VR content?

File mat_draw_calls.js translated to english now.

1 Like

not necessarily, I believe higher refresh rate will become the norm slowly. As someone who makes games/apps I want to make sure that the content I create looks/works well on a range of hardware. For example, some animation bug might not be noticeable at 60FPS, but be very obvious at 100+FPS, it’s not common, but I did encounter a few bugs like that in the past.

There are also cases where higher FPS puts more strain on the engine to the point where the device gets quite toasty, being able to see that strain for yourself makes you aware of it and lets you plan for how to deal with it.

1 Like

My client recently: “the app is looking great, it’s running at 240FPS on my machine.”
Me: :exploding_head: :exploding_head: :exploding_head:

Sitting here on my laptop from 2016 like


source: line: 226 GPU draw calls: ’ + api.count

The author doesn’t realize by moving the camera, the number of objects in frustum can change thus the number of draw calls.
For this kind of test, it’s best not to have camera control.

This mesh has 1074 faces and 2 materials. How the material index is applied, can change the number of calls. The "0 1 0 1 " button produces the most calls which is the total number of faces.

To get 20k calls click on "Add Mesh " button (duplicates mesh 19 times) and then the "0 1 0 1 " button.
You want more calls, edit the file and change for( var i = 1, mesh; i < 20; i++ ).
Warning: too high of draw calls and browser crash.


Model MI.html (93.5 KB)

1 Like

so 20K calls and still 60 fps. looks like gpu does not care that much :sweat_smile:

1 Like

The amount of draw calls doesnt matter that much. If I only use a basic shader that fills every pixel with a solid color, my old crappy laptop can run 150k draw calls per frame without a sweat. If I write a gigantic complex shader, I can let my RTX 2080 Ti choke on a single draw call. It all depends what kind of shaders you’re using on your meshes.

Top row at 2 draw calls
Bottom row at 21k draw calls

FireFox 91 not doing as well as Chrome 92. Almost 1/3.