There something in threejs ocean technique that is slower than zen-3d inspired code

Describe the bug

ThreeJS slower than GitHub - shawn0326/zen-3d: JavaScript 3D library.
when animating sky/water shader, i would love if threejs was the same performance

To Reproduce

run sky/water on threejs and compare with zen3d… move the sun for example, inclination… see the difference in FPS


compare both lib shaders is nearly identical as zen was inspired (not totally forked as others) in three

Expected behavior

Same performance, if it´s the same “thing” and shader

i did the fiddle tooo fast… okay change the fiddles, and try to be faster than zen3d… i tried that in many ways in last years


ok here we go

threejs one:

zen3d one:

sorry base64 on zen one, i cant managed to put image link didn´t worked

on my computer three gives oscillations down in fps… but zen3d 60 61 fps stable

on my mobile, threejs capped to 29 30, while zen-3d 30 ~46 fps… but i remember 3 years ago testing, that it´s more on the stable side of 46 when interacting, maybe i forced too hard the auto senoid demo… also jsfiddle i dunno if it make slower on mobile…

veredict: there´s some performance culprit occult inside threejs (i mean even if it´s not a ‘slowering feature’ we are using)


while reflecting about what i just said… i would like to add that… if you test it non in jsfiddle, but fullscreen in mobile… the impact difference i think will be bigger… because 3 yrs ago when i found this, i tested in 100% scale

1 Like

It’s not… the performance comparison you are doing isn’t fair, because as Mugen said, you are performing tone mapping AND pmrem generation in the threejs example. Trying commenting out the line scene.environment = pmremGenerator.fromScene( sky ).texture; in your updateSun function - PMREM generation is expensive and can take many milliseconds on a low-end device. Getting rid of that line should make the threejs scene perform as well, if not better, than the “zen3d” scene.


you two, said that… but im saying that in the past i tested in many ways… when i have some time i will change the fiddle to prove it, Thanks

1 Like

I tested the fiddle on my machine - without the PM-REM generator, the THREE.JS example ran at around 1000 FPS compared to the 260-300FPS of the zen3d example.


can u post the fiddle fixed? so i can ran the same test on my desktop and mobile?

1 Like

Just delete the line I told you to.

1 Like

yeah i deleted pmrem on update, i know that i dont have tested with that on update loop in the past…

the fps increased, but on mobile i only tested in a tiny window, in this way jsfiddle harms a bit the test vs a 100% screen one… when i got time i will remake the tests outside jsfiddle

1 Like

Alright - tell me how it goes!

1 Like

Okay, i´ve found a super fast and easy way to prove my point…

just open the ocean example from threejs site, on a mobile and look to the fps

i can achieve many more fps with same stuff in zen3d

my mobile is not from NASA, neither JURASSIC… i have a snapdragon 660 mobile cpu
the question is… why i can achieve so much more in zen?

i can screen record for you to see if u want

1 Like

I’d love to see! For me on desktop (with an M1 Mac) threejs outperforms zen3d… maybe something is going on with modern versions of three that isn’t mobile-friendly?

1 Like

i´ve found this 3 years ago, when i got haunted by threejs BLACK textures in some mobiles…
i looked desesperately to a framework, zen3d saved me… but later i decided to move on with old mobiles…

they can do pbr without artifacts on old mobiles i dunno how… it´s one of the reasons that i ask the folks take a deeper look on zen… he got mobile in mind

but as added bonus i´ve also found this problematic behaviour with sky/ocean SUPER LOW performance also (low without interaction, and VERY low with interaction of uniforms)

1 Like

TBH you’d have to take these issues up with someone more versed in the internals of threejs and zen3d. I hope you discover the thing slowing the water example down.


Interesting how no one cares… :slight_smile:

1 Like

I’d think many people care, but certainly not nearly everyone knows enough to add anything useful.


Honestly it takes a lot of work to correctly make a good benchmark between two different engines. Otherwise the differences usually come down to discovering that you’re really doing different things in each. If someone wants to spend that time and identify a performance bottleneck in three.js, please do, but starting with a provocative title like “three.js is slower than zen3d” suggests you are not really digging into technical details here. Because I don’t know much about zen3d, I have no particular reason to spend a lot of time on this. The two engines might — for example — use very different shading models. The code in examples/js/objects/Water.js is an example, not a one-size solution for rendering water, and modifying it to fit your needs is strongly encouraged. :slight_smile:


Isn´t much about fps little fine tuning… but a visible difference in a very easy test just opening both examples, and updating uniforms with the slider…

but without adding heat to this, i must say that a lot of 3d/mobile devs, are tightly focused in extremely fast mobiles where this kind of difference can pass blind through.

I think that this can hide something curiously important for the engine we love so much! As the code/shaders are very close, the shaders are the same…
I asked the zen3d maintainer to do the ocean, and it did in few days… i hit zen3d because threejs in many mobiles got black texture while zen not… (that also is a mistery, im saying that if it does mediump behind scenes there´s no artifact, or it does highp in a compatible way, who knows, but this is another topic ( big one topics from the past ) )

1 Like

Isn´t much about fps little fine tuning… I think that this can hide something curiously important for the engine we love so much!

Perhaps it may! At a glance I can’t tell, though, and I’m guessing this would take quite a while to find a difference that may just be a specific optimization in Water.js… and that’s just not a huge priority for me in my free time. The more users rely on a feature the more likely it is that someone will want to spend time on it. If you’re relying on it, please feel free to experiment with optimizations— that’s why it’s open source after all.

If you can share details about which specific mobile devices the water demo does not work on, that’s definitely fair game for a bug report. :+1:


The demo works… but the difference in FPS when you for example change azimuth, is BIG… i would not say in super m2 cpu max power hi tech… but the other 90% of mobiles of entire world

Also, i don´t believe the chinese guy optimized water specifically, as i said it just did it naturally, im not library developer it´s too complex for me also understand underneath

1 Like

Interesting how no one cares… :slight_smile:

You have not heeded the advice of anyone who’s tried to help and you have not provided anything you suggested you would - no updated fiddles, no full screen comparisons, and no screen recording. Providing notional evidence of “I remember this from three years ago” motivates no one and doesn’t give anyone anything concrete to work with.

As has been mentioned in this thread and on Github commenting out line 151 with the pmrem update improves the three.js performance substantially. Running the updated three.js fiddle in full screen mode on my Pixel 3 I get 60 fps compared to 45 fps in the zen3d demo. The zen demo is actually significantly slower unless there are some other improvements to be made to the zen3d fiddle.

If you still believe there is a meaningful performance difference then you should provide a minimal, easy to understand example that demonstrates it.


don´t run fiddles, just run the example of each website, directly on mobile,
thanks for tests

1 Like