(2018-11-09, 19:38)Roland Melkert Wrote:(2018-11-09, 11:44)Lasse Deleuran Wrote: Psych: Memory usage: 36.3MB. [color=#000000]Rendering time: 1.039ms. Number of points: [color=#000000]375.432.[/color][/color]
Executor: Memory usage: 862MB. [color=#000000]Rendering time: 1.8185ms. Number of points: [color=#000000]11.333.253.[/color][/color]
[color=#000000][color=#000000]This is what happens when you combine points for the full models:[/color][/color]
[color=#000000][color=#000000]Psych: Memory usage: [color=#000000][color=#000000]16.6MB. Rendering time: [color=#000000]3.121ms. Number of points: [color=#000000]99.687.[/color][/color][/color]
[/color][/color][/color]
Executor: Memory usage: [color=#000000]313MB. Rendering time: [color=#000000]99.495ms. Number of points: [color=#000000]2.700.145.[/color][/color][/color]
[color=#000000][color=#000000][color=#000000]That rendering time is completely unacceptable. Here is what happens when points are only combined for the individual parts (not the full mode:[/color][/color][/color]
I don't understand how can it become slower, or are you counting the preparations too?
In LDCad each part gets prepared for rendering separability and the result is stuffed in VBO.
Also finding the unique points is not only useful for indexed meshes but also very helpful during smoothing.
Yes. I am counting the full time to sort all points of the model. Sorting 11mio. points takes forever in the browser, but I had to see it in practice in order to rule out the approach.
Three.js is putting an abstraction layer above what I actually have as individual VBO's. I am planning on reading up on this and try to take advantage of it, rather than allowing it to be some black box. I can also see that BrickSmith has had huge performance boosts by using parts being VBO's as you mention, so the rendering can simply be "draw this VBO/part here, there and there". If I can figure out how to do this as well, then I might get a similar big performance benefit.