thi-ng / umbrella

⛱ Broadly scoped ecosystem & mono-repository of 198 TypeScript projects (and ~175 examples) for general purpose, functional, data driven development
https://thi.ng
Apache License 2.0
3.31k stars 144 forks source link

[geom] groupFromTessellation not exported #475

Open nkint opened 1 month ago

nkint commented 1 month ago

Hi! Not sure why but the new from-tessellation is not exported correctly. (I am super excited from graphFromTessellation ⚡️❤️😱💥)

$  cd /tmp
/tmp $   mkdir test-geom-tessel
/tmp $   cd test-geom-tessel
test-geom-tessel $   yarn init
test-geom-tessel $   yarn add @thi.ng/geom
test-geom-tessel $   cd ./node_modules/@thi.ng/geom
geom $   cat package.json | grep version

  "version": "7.0.1",

geom $   ls f*
fit-into-bounds.d.ts fit-into-bounds.js   flip.d.ts            flip.js

I am expecting to see from-tessellation as well....

I might miss something...

postspectacular commented 1 month ago

Hi @nkint — this new feature (like many more recent examples) is still relying on the as-of-yet unpublished v8 of thi.ng/geom, so you'll have to use the repo version. This next update is one of the largest in recent years and I've been working it now for over a month. Hope to get it out sometime next week (at last!)

nkint commented 1 month ago

thanks, no hurry 😅

This next update is one of the largest in recent years

Seems exciting! Can I ask you a quick spoiler? Just out of curiosity, what is the reason that drives you to this refactor? Sorry I'm missing for a long time and I don't want to flood you with questions...

postspectacular commented 1 month ago

Lots of reasons, incl. long planned additions, but also just quality of life improvements:

I'm sure I'm missing a ton of other features here, just take a look at the comparison with the v7 version (most of the commits since then are related to this major overhaul):

https://github.com/thi-ng/umbrella/compare/%40thi.ng/geom%407.0.1...develop

Hope that helps! :)

nkint commented 1 month ago

Yes thanks! 👏 Great work! Always learning from inspecting your commits/refactor-process.

While lurking last commits I also noted some rewrite of algorithms from tranducers to simple for loop (random example):

image Is it just a completely unrelated random thing, a shift in paradigm, or an optimization effort?

postspectacular commented 1 month ago

Hehe... here the shift away from transducers was for mainly for these reasons:

1) the new tessellators are generating faces of point indices (aka vertex IDs) rather than just emitting points and we're also storing these results in a tessellation object, rather than just emitting a sequence of faces. this all gives us more flexibility for post-tessellation uses (e.g. graph building), but also is much more suitable for WebGL... 2) I wanted the different tessellators to be as uniform as possible (in terms of implementation) and for some of them there was no easy/efficient way to do them in this transducer style (transducers are flexible, but not a silver bullet :) 3) The use of transducers here was a performance bottleneck, especially considering these tessellator functions are kind of a performance hot spot, so it's been worth it replacing them. e.g. in the edgeSplit() example you posted above, the new version saves 2 array allocations, a loop and some other overhead for each single edge, all quickly adding up... 4) The diff you posted isn't actually the latest version (which is shown below). There you can see that the target tessellation has now actually an interface (and there're two implementations available for now, one with mesh-like characteristics to dedupe vertices). Again, this is a type of update which doesn't really suit a transducer approach...

https://github.com/thi-ng/umbrella/blob/071536d81e8fa593673d1f1997bc0be360364f23/packages/geom-tessellate/src/edge-split.ts#L5-L22

Btw. This all is not to say that transducers are inefficient in general or that you should stop using them, it's just one of the examples why there're many approaches/paradigms used throughout umbrella: Rather than insisting that everything is a nail for our hammer (as often w/ frameworks), different situations/contexts are just calling for different solutions...