jscad.app seems to render twice as fast than openjscad.xyz, why?

[Hermann-SW]

You can verify my numbers.

• open two chromium or two chrome browsers, one with jscad.app, the other with openjscad.xyz.
• Download this jscad file: https://gist.github.com/Hermann-SW/b3e85c8fe6827cd29238c14f9da346be
• use file manager to drag&drop the downloaded file into both browsers
• edit downloaded file, change "faces" in bottom "getParameterDefinitions" from initial "Pentagons" to initial "6coloring" or back
• writing change to file when watch with seconds is say at multiple of 10 seconds
• note time taken for color change in display for both

I measured on Raspberry Pi5 with 64bit Raspberry PiOS (Debian based) 6s/12s refresh time for jscad.app/openjscad.xyz. I measured on Intel Celeron j4125 with 64bit Ubuntu 22.04 9s/18s refresh time for jscad.app/openjscad.xyz.

While jscad.app has other cool features, like base64 data uri (and will have base64 gzipped data uri) compared to openjscad.xyz, twice the rendering performance is a killer argument for jscad.app ...

Only real jscad.app issue for me is the brightness issue (compared to openjscad.xyz): https://github.com/hrgdavor/jscadui/issues/83

[hrgdavor]

@Hermann-SW if number of those utility spheres grows more, you could also see more benefits in jscad.app when creating a single sphere and placing it in different location via transform

const utilSphere = sphere(...)

// in loops or elswhere needed use translate
translate([x,y,z], utilSphere)

translate creates a new geometry object where mesh is the same but location info is different, and if not used in booleans, you can create many of them this way, even with high segment count, and jscad.app should use instancing optimisation of threejs and run it very fast.

[hrgdavor]

Only real jscad.app issue for me is the brightness issue (compared to openjscad.xyz): #83

we are working on that, and @platypii also agrees such setup similar to xyz is better, as it is also used in other CAD software because it is more practical.

[Hermann-SW]

@Hermann-SW if number of those utility spheres grows more, you could also see more benefits in jscad.app when creating a single sphere and placing it in different location via transform

const utilSphere = sphere(...)

// in loops or elswhere needed use translate
translate([x,y,z], utilSphere)

translate creates a new geometry object where mesh is the same but location info is different, and if not used in booleans, you can create many of them this way, even with high segment count, and jscad.app should use instancing optimisation of threejs and run it very fast.

Thank you, I will definitely use that in new application of my GP3D repo that generates JSCAD for 3D output.

I cannot speed up current demo becuase of the "half vertex" handling, which is different for each sphere: https://gist.github.com/Hermann-SW/b3e85c8fe6827cd29238c14f9da346be#file-c36-10-fixed-jscad-good_enough-jscad-L17-L44

In new demo I will have many spheres like in this OPenSCAD screen recording animation https://stamm-wilbrandt.de/images/Peek_2023-12-11_22-24.gif and I can live without "half vertex" and use your "const utilSphere" approach.

I will have many same radius spheres, but they will be colored differntly. Should I have one utilSphere per color, or is single utilSphere good enough and coloring is like translate no issue?

[hrgdavor]

try this for comparison of what reuse instancing can give.

const jscad =  require('@jscad/modeling')
const { intersect, subtract } = jscad.booleans
const { colorize } = jscad.colors
const { cube, sphere } = jscad.primitives
const { translate } = jscad.transforms

module.exports = {main : ({// @jscad-params
  multiplier = 4
}) => {
  let reused = sphere({size:2})

  let out = []
  for(let x=0; x<multiplier; x++){    
     for(let y=0; y<multiplier; y++){
       for(let z=0; z<multiplier; z++){
         out.push(translate([x*10,y*10,z*10], reused))
       }
     }
  }
  return out

}
}

[hrgdavor]

Should I have one utilSphere per color, or is single utilSphere good enough and coloring is like translate no issue?

color should work like transform (translate, scale, rotate), so one utilSphere should be enough.

[Hermann-SW]

I am really impressed by that small model. model data url

I measured on Raspberry Pi5 with chromium browser rendering time for different multipliers: multiplier	time[s]
15	8
16	12
17	14
18	17
19	21
20	25

It is OK having to wait for 25s for 8000 spheres — zooming and rotating afterwards is fast.

[hrgdavor]

yeah, next step is to allow exporting currently edited script as gzipped data url. ... after that also parameter values in url

[Hermann-SW]

yeah, next step is to allow exporting currently edited script as gzipped data url.

That will be cool, I have "Share" button in my app for that: https://stamm-wilbrandt.de/GraphvizFiddle/ That button does only urlencode the editor content, no base64 and no gzip yet.

... after that also parameter values in url

They are already in URL, just base64 gzip encoded ;-)

When using "drag&drop+file change" method to work with jscad.app, I just change in dropped file, and jscad.app refreshes. For Firefox that does not work with that method, I do

pi@raspberrypi5:~/GP3D $ tools/view_gzb64 gp.jscad
Opening in existing browser session.
pi@raspberrypi5:~/GP3D $ 

initially to view file in jscad.app. For parameter change I just change parameter in file and execute above command again to get URL with updated parameters.

[hrgdavor]

@Hermann-SW declaring paramters and using them via form can allow for further optimizations, because you can cache things even more agressively.

try this https://jscad.app/#https://3d.hrg.hr/jscad/three/examples/parametric_butt_hinge_3.7.js

if you change view options, then boolean ops are skipped, and only previously calculated meshes are returned. They are returned with different transform. This may not be a perfect useful example, but show the benefits. (try "thow angle" slider it ahs live:1 option that is specific to jscad app). TIP: increase "Fastener options" / "count" to slow down the render of booleans.