You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I’m imagining is a new class, something like neoscore.core.positioned_object_3d which is converted to just a plain old positioned_object after a mapping from 3D to 2D. The main function of the class would be to do the projection calculation to map the 3D coordinates to 2D. This class would also be in charge of the render order of 3D objects in the scene; objects deeper in the viewport should be rendered first so that objects closer to the viewer are rendered on top of them. In other words, objects should correctly obstruct the view of other objects from the user perspective.
There would be another layer of abstraction above positioned_object_3d, something like neoscore.core.path.Path_3d which looks almost identical to the 2D version. (Maybe it makes sense to just make the existing Path more flexible to accommodate 3D vectors?) There might be reason to make additional 3D-specific class methods in the future, but just converting the 2D tools we have to 3D would be sufficient for non-curved surfaces in 3D space.
Convenience classes for neoscore.core.path.Path_3d would include basic platonic shapes like cubes and dodecahedrons and maybe pyramids or a teapot. There should also be some way to adjust the pitch, yaw, and roll (or rotate, tilt, and tumble?) of a parent object and its children around an arbitrary point in 3D space.
The demo for this functionality would be a cube with some miscellaneous things drawn on each surface. The cube would pitch, yaw, and roll randomly to reveal each surface.
We would need to be able to adjust the field of view somehow. It makes sense to me to have a global FOV parameter living at the document/viewport level, but maybe that’s too restrictive. Maybe there’s a situation in which you want multiple FOVs acting on different 3d objects.
Is this within the scope of neoscore?
a. Even though you might be able to get a higher fidelity 3D object from something like Unity, the accessibility of Python justifies this basic 3D implementation in my mind.
Is there a more streamlined way to do this?
a. It seems reasonable to me that every point in neoscore could be three dimensional with the z value set to zero for 2D objects. In that case, maybe there is no need for a dedicated Path_3d and a two dimensional path could be a special case of a generic three dimensional Path.
The text was updated successfully, but these errors were encountered:
At first glance, I think this may work better as an extension on neoscore rather than a core component. PositionedObject is a very fundamental class in a way the 3rd version is not, and putting them side-by-side risks muddling the conceptual clarity of the core module. Everything described here should be achievable as a third party package once z-index support is re-added.
For more advanced 3d use-cases I think, as you suggest, it probably makes more sense to not use neoscore as a primary application at all. In principle a game engine should be able to run a sidecar neoscore application which uses IPC to send rendered images which can then be used as game engine textures.
I would like to add some basic backend way to project 3D lines and points to a 2D canvas. This should be a relatively simple thing to add, there’s a very clear explanation of the math here: https://math.stackexchange.com/questions/2305792/3d-projection-on-a-2d-plane-weak-maths-ressources
What I’m imagining is a new class, something like neoscore.core.positioned_object_3d which is converted to just a plain old positioned_object after a mapping from 3D to 2D. The main function of the class would be to do the projection calculation to map the 3D coordinates to 2D. This class would also be in charge of the render order of 3D objects in the scene; objects deeper in the viewport should be rendered first so that objects closer to the viewer are rendered on top of them. In other words, objects should correctly obstruct the view of other objects from the user perspective.
There would be another layer of abstraction above positioned_object_3d, something like neoscore.core.path.Path_3d which looks almost identical to the 2D version. (Maybe it makes sense to just make the existing Path more flexible to accommodate 3D vectors?) There might be reason to make additional 3D-specific class methods in the future, but just converting the 2D tools we have to 3D would be sufficient for non-curved surfaces in 3D space.
Convenience classes for neoscore.core.path.Path_3d would include basic platonic shapes like cubes and dodecahedrons and maybe pyramids or a teapot. There should also be some way to adjust the pitch, yaw, and roll (or rotate, tilt, and tumble?) of a parent object and its children around an arbitrary point in 3D space.
The demo for this functionality would be a cube with some miscellaneous things drawn on each surface. The cube would pitch, yaw, and roll randomly to reveal each surface.
We would need to be able to adjust the field of view somehow. It makes sense to me to have a global FOV parameter living at the document/viewport level, but maybe that’s too restrictive. Maybe there’s a situation in which you want multiple FOVs acting on different 3d objects.
a. Even though you might be able to get a higher fidelity 3D object from something like Unity, the accessibility of Python justifies this basic 3D implementation in my mind.
a. It seems reasonable to me that every point in neoscore could be three dimensional with the z value set to zero for 2D objects. In that case, maybe there is no need for a dedicated Path_3d and a two dimensional path could be a special case of a generic three dimensional Path.
The text was updated successfully, but these errors were encountered: