Hi everyone, I’ve been programming a game for the past 3 years using THREE.js. As I’ve improved my coding skills I happened to write an algorithm that is faster than the existing one and is also capable of generating an Icosahedron of detail level 8 in a chrome browser without crashing it. I’ve never contributed code before, but how could I go about seeing if the code I have is worth incorporating?
Do I just post my code here? and if so how do I do that?
You can fork three.js, make your changes and then try to do a pull request. It will be reviewed and accepted or rejected.
This guide is pretty good imo.
I figure I should mention a quick blurb about this post years ago. It was on my mind.
I did in fact try to write a newer function that adhered to better coding standards and also used typed arrays and generate buffer-geometry upon load instead of generating regular geometry and converting to buffer-geometry later.
Initially the function I wrote could generate a world of over a million faces in ~5 seconds, and the function that comes with three.js was ~16 seconds on my computer.
What I learned were two things:
first with my function I never calculated face uv’s. So right there that would have eaten some time, but still there was a large enough gap in milliseconds I thought it worth trying anyways and incorporating uv calculations.
I started to rebuild the function using typed arrays and that is when the time started to mount. By the time I had the function working it pretty much matched what comes with Three.js. The only advantage to the function I wrote was that there were no seems or duplicate vertices. But not like it matters its buffergeometry. And that was as of what ever build was kicking around in 2017.
What I learned is that once typed arrays become large enough, at least with my system, things slow down a lot.
So there you have it, not much ‘faster’ than I had hoped, haha.
Cheers.
Typed arrays weren’t faster? That challenges a similar assumption I’ve had for a while, then.
From what I’ve seen, typed arrays are often faster because you are forced to declare the length, and then a direct assignment to each index: array[i] = x. Regular arrays can be slower when you choose to declare length of 0, and then use array.push(x) because the system has to re-allocate more memory on each push. I can see results in this JSPerf test that reinforce that assumption; array.push() is 93% slower than array[i]=.
What I can do is tell you is what I managed to recognise and witness. Whether my insights hold weight will be to your discretion.
The geometry class has two arrays which have significant sizes, the vertices and faces array. Buffer geometry has 3 to 4 typed arrays for each of the vertices, indices, colors, and uv’s properties. If you don’t use indices( indices limit your material options ) then the vertices array is 9x larger than a regular geometry class. Faces, colors and uv’s are each 3x, 3x and 6x times larger. If you use indices than each typed array is 3x except uv’s which is 6x larger. I think the slowdown was due to the extremely large sizes of each of these arrays.
I’m also talking about very big geometries as well, the noticeable performance improvements were pretty much the same ratio down to smaller sized geometries. Thus the benefits of the function was less significant.
Whether my insights hold weight will be to your discretion.
On a coding forum, your insights will only hold weight if they are backed up by code that other people can run.
Good call.
Your comment got me thinking again, more so. I was wondering just how well I understood what I was looking at. This is where I say I don’t really know what I’m talking about… ever. At least when it comes to programming. Yish, that’s why I have stayed clear of making claims ( this is the first and only time I’ve done so ). I was just super stoked is all.
K, now I know I’m completely wrong about my claims. Buffergeometry is indeed much faster than what I wrote, and can support a higher level of detail in chrome.
Here is my code looeee if you’re at all interested in taking a look.
It’s a scene with Three.IcosahedronGeometry, THREE.IcosahedronBufferGeometry, and my own Geometry class variant.
I comment out each one at a time to compare performance.
Seems what I wrote is only faster than geometry, but about 50% slower than buffer.
sphere.0119.zip (142.3 KB)
Cheers