Explore converting to Three.js
Closed this issue · 6 comments
The code is currently written in WebGL. Explore whether converting to three.js will make it easier to maintain and contribute to.
Currently exploring this and learning three.js as I go. I see learning shaders and how to port them to three.js as the biggest learning curve.
I would encourage you to explore converting to three.js if you're long term ambition is to make this accessible to other developers. I have spent years rewriting this code and there are so many hurdles that can be easily avoided by making the switch now (meshes, drawing lines, better camera controls, easy addon shaders, post processing effects,...just to name a few lol).
The shaders for this were wrote in WebGL 1.0, but I have 2.0 versions that are a little cleaner you can use as a reference. The challenge is that it is hard to port any part of the render pipeline over without just doing the whole thing.
One huge gotcha is the 90 rotation to the perspective matrix so that Z is aligned with the north pole (how satellite coordinates are recorded in ECI). If you don't do that, the satellites will all be rotated instead.
Thanks. I hadn’t noticed the axis issue
I have an experimental implementation here of some the items:
https://ajmas.github.io/experimental-threejs/
Next step is working on the particles, since while I did borrow some snowflake code, I need to see how best to convert it to work for the satellite representation.
I have essentially taken the approach of writing the code from scratch and then integrating with the positioning logic from the original project. When I feel ready I’ll push a draft implementation, so I can work with feedback.
Draft now added, but particles are still a work in progress.
Now with orbits, next need to deal with re-introducing the point select logic.
Note there seems to be a bug when using 'Starlink' as a group. Getting:
THREE.BufferGeometry.computeBoundingSphere(): Computed radius is NaN
Regressions will be pushed out to new issues