feat: experimental 3D view #71
Conversation
Implement 3D viewer of current design in new "3D" tab by using `solid-three`, specifically its `next` branch. Used `Entity` pattern as opposed to `createT` pattern mainly as personal preference. Also added lighting using (admittedly) magic numbers to give visual contrast to 3D. Also used magic numbers to get in frame on own machine.
Fixed style on canvas so that isometric view does not overflow its containing `<Paper>` element.
Moved JSX initialization of full mesh to a separate component, `SiliconMesh`, so that hopefully can do boolean operations on the separate meshes to fix their z-fighting. Also ended up, for `SiliconMesh`, subverting the normal `Entity` pattern and directly implementing the adding of the meshes to the scene using `three`. As of the time of development `solid-three`'s Entity wasn't updating, even when `createEffect`'s callback was being called and updating `group`. This is probably my own misunderstanding, but got to work for now by essentially doing the scene management directly.
Added `OrbitControls` to 3D viewer, allowing users to rotate, pan, and zoom the silicon. This reveals that the supposed blocking of diffusion by the polysilicon is not actually being rendered, which will likely have to also come from implementing boolean geometry. Additionally, there is a bug (or an incovenience?) that zooming out too much causes the mesh to go out of render distance and so disappear.
Included `three-csg-ts` in order to utilize CSG (Constructive Solid Geometry) to fix z-fighting issues, especially in substrate. Currently incredibly inefficient. Also in installing, was a scary "overriding peer dependency" message, but overall still seems to work. Was specifically for a `magicast` module. Worth keeping in mind.
|
Commit dc9e0aa introduces new dependencies, specifically |
|
Additionally, I'm considering if "Adapt for more screen sizes, removing magic numbers in process" would be better suited for a different PR, particularly because other components (see If this item can be reserved for another PR, I think the 3D view is ready for review. |
|
Finally, it should be noted that this current implementation is quite inefficient and naive. For context, in order to fix the z-fighting, BSG was used with an This inefficiency appears when opening the 3D tab and when editing the design while the 3D view is open. It's small but definitely noticeable from 
|
|
Thanks! 5s is quite significant (even 0.5s is noticable). What is the impact of disabling the z-fighting? would this still be usable? |
|
Also, wouldn't adding a relatively small number (e.g. 0.00001) to z-height of some of the layers fix he z-fighting? |
|
Sorry for the late reply!
It's worth pointing out, however, that the smaller scale of siliwiz means this aesthetic issue is much more prevalent than in the official viewer.
|
2 participants
WORK IN PROGRESS - This change likely shouldn't be merged yet. I just wanted to get the code out to community in case anyone wanted to tinker on it.
Implement 3D viewer of current design in new "3D" tab by using
solid-three, specifically itsnextbranch.Used
solid-three'sEntitypattern as opposed tocreateTpattern mainly out of personal preference, could probably be either way. Look here for more info: https://github.com/solidjs-community/solid-three/tree/next?tab=readme-ov-file#basic-usageAlso used magic numbers to get the display to fit on my machine; almost certainly NEEDS WORK to be universal and applicable for most users.
To Do
That can think of right now...
Paper.