Typed Arrays usage and conversion

[hrgdavor]

initial idea (likely not viable)

While exploring the web workers, I have stumbled upon one concept that is supported for long time now (since 2011) https://developer.mozilla.org/en-US/docs/Web/API/Transferable

https://developers.google.com/web/updates/2011/12/Transferable-Objects-Lightning-Fast

Typed arrays are one of the objects that are like that, and if modelling would be based on them, I am sure it would open-up some more avenues for performance improvements.

This is just speculation for now, and a vague idea but I want to put it out there for consideration.

Update 1 (more practical direction with less drastic changes)

---

I took a sphere with 2014 segments to check the numbers for creating it, and converting to array for webGL.

• 6.285.312 vertices array length
• 3.139.584 indices array length

The concrete run-time numbers are not a important, as is relative performance weight of each step.

• step1 ~ 300 ms to create sphere
• step2 ~ 300 ms to convert to native array in format used in webGL im my threejs viewer
  code for regl renderer is 2x slower in step2
• step3 ~ 12 ms Float32Array.from(nativeArrayWithWebGlData)

I was able to change converter to calculate size of vertices array and size of index array for webgl data so I could create TypedArray for each in advance and fill them. This allowed me to

• skip step3
• reduce step2 from ~ 300 ms to ~80ms

The gain is obviously from the fact that we create array in advance. If we start with empty array and push stuff in it, it will be resized many times during the conversion (new mem alloc, and data copy)

The conclusion is that I should be able to reduce regl-render conversion time from 600ms to 80ms (somwhere in that range) for this particular case.

Bonus exploration: colorCube from examples takes on regl-renderer 1300 ms to upload to gpu as cube data is not reused.I think I will be able to reduce that t some point below 20ms... but for that I need to finish those multiple PR's regarding geometry immutability and regl renderer shader and also webworker reuse on param change (that one I already hace proof of concept working in that new param syntax demo)

[z3dev]

I understand the appeal but there are lots of issues, especially if trying to use 32 bit numbers.

Here’s a list of some of the issues encountered when modeling was based on 32 bit typed arrays.

• V2 : odd result of measureArea() #570
• V2 : fast datatypes #624
• V2 : Issues with using JSON for serialization #502

[z3dev]

There are two major issues to overcome.

1. performance of creating arrays; typed arrays are really really slow
2. precision of normals; 64 bit numbers are required to perform comparisons, which the booleans use heavily

NOTE: planes are basically a normal, plus a distance from 0,0,0. planes are used heavily in big operations

[hrgdavor]

Thanks for the clarifications. This is just something that came into mind, and If I write it down like this I can more easily move on. I get easily distracted with new shiny things, but making new web viewer is effort better spent right now.

This came about when looking into web workers and an idea to possibly offload some computation to additional workers.

Another distraction that came about while working on the new viewer is an option for a nice outline rendering that could be used to create even better looking presentations of projects done using openjcad.

https://github.com/gkjohnson/threejs-sandbox/tree/master/conditional-lines

from what I have seen in the code, it creates additional geometry for outline and I was looking into way to display model immediately and let another worker do the outline. model would show ion screen sooner, and outline would appear afterwards.

I am fixated with performance. It is ok to think about it, but it is also better to not waste time on it before there is actual need to improve performance.

That is why wrote it down as discussion here, and later we can see if the time is right to actually consider implementing.

Thanks for pointing out the issues with the approach, it helps of course with evaluating if it is a worthwhile effort at some point.

[z3dev]

OpenSCAD has two display modes as well. Not sure why but it's probably for the same reasons. Drawing a sphere outline is far easier then drawing a mesh with 200K polygons.

[hrgdavor]

Although I mentioned the outline render here, it is not performance related. The render mode shown here is actually less performant:

• it calculates outline once after model changes
• renders the original model
• renders also the calculated outline.

But it can give a very nice alternative view:

• if I want to present the model as drawing-like.
• It is very nice for printing on black and white paper (assembly instructions).

how can I activate the built-in alternative display mode ? I would like to see what it looks like :)

[hrgdavor]

Update 1 (more practical direction with less drastic changes)

---

I took a sphere with 2014 segments to check the numbers for creating it, and converting to array for webGL.

• 6.285.312 vertices array length
• 3.139.584 indices array length

The concrete run-time numbers are not a important, as is relative performance weight of each step.

• step1 ~ 300 ms to create sphere
• step2 ~ 300 ms to convert to native array in format used in webGL im my threejs viewer
  code for regl renderer is 2x slower in step2
• step3 ~ 12 ms Float32Array.from(nativeArrayWithWebGlData)

I was able to change converter to calculate size of vertices array and size of index array for webgl data so I could create TypedArray for each in advance and fill them. This allowed me to

• skip step3
• reduce step2 from ~ 300 ms to ~80ms

The gain is obviously from the fact that we create array in advance. If we start with empty array and push stuff in it, it will be resized many times during the conversion (new mem alloc, and data copy)

The conclusion is that I should be able to reduce regl-render conversion time from 600ms to 80ms (somwhere in that range) for this particular case.

Bonus exploration: colorCube from examples takes on regl-renderer 1300 ms to upload to gpu as cube data is not reused.I think I will be able to reduce that t some point below 20ms... but for that I need to finish those multiple PR's regarding geometry immutability and regl renderer shader and also webworker reuse on param change (that one I already hace proof of concept working in that new param syntax demo)

@z3dev hope you are well on ur vacation, lots of fun stuff for when you come back from sabatical 😄 . I am spamming u as I am proud of my new improved skills regarding webgl.

[z3dev]

Excellent! See #812

The use of typed buffers will be a huge performance boost, both for 3D and 2D rendering.

Keep in mind that there are multiple buffers for vertices, normals, etc.

[hrgdavor]

Keep in mind that there are multiple buffers for vertices, normals, etc.

np, I will

I will start working on #812

Now that I have measured that it is worth to calculate final size of typed arrays and then fill them (versus arr.push + convert) I will include that optimization there.

side-note: I have even noticed that although color per polygon was abandoned, color per vertex is still generated in the renderer. That opens-up some more performance to be gained later down the line by using color per geometry, so othere is no need to generate and upload color for each vertex into gpu.

[z3dev]

Hmm… although the modeling library doesn’t support setting colors per polygon, it’s possible to set color. As well as render colors per polygon. It’s probably best to keep supporting this.

[hrgdavor]

Hmm… although the modeling library doesn’t support setting colors per polygon, it’s possible to set color. As well as render colors per polygon. It’s probably best to keep supporting this.

I do not plan to touch that yet, but at some point I will return to it and check the performance hit. Booleans as far as I know have stopped keeping colors of polygons of the geometries that were involved in the operation. The v1 intro object clearly shows that as well as logo, but regl-renderer demo does not have it any more.

if measurements show a significant performance hit, I would likely go into direction of making this optional (the default then may be true/false) .