This is a discussion, not a feature.
Summary
Transitioning Ply to become macroquad-independent and introducing a first-class, Spline-inspired 3D API. This issue is intrinsically vague to serve as a brainstorming hub for how Ply can solve 3D in Rust without losing its code-first, zero-boilerplate roots.
Why
Right now, 3D games have two complex paths:
- ECS Behemoths: Simple tasks often require thousands of lines of boilerplate and ECS queries.
- Clunky Giants: Hide your logic behind opaque editor formats and binary asset files.
I would like an engine with the insane simplicity of Ply, combined with the visual ease of a tool like Spline. It must be simple, without macros or unreadable file formats, while remaining highly versatile.
Ideas
Since this is 2.0, we can break every backwards compatibility rule in the book. It will not be backwards compatible, but that does not mean we are deleting the beautiful layout API, just reworking some things.
3D Builder
We continue to leverage the builder pattern and closures. Something like this:
scene(|s| {
s.camera(|c| /* idk */);
s.light(|l| /* idk */);
s.model(PLAYER_MODEL, |m|
m.position((x, y, z)).rotation(rot);
);
});2D within 3D
2D and 3D should coexist. 3D probably exists within 2D (not sure), but 2D can also exist within 3D. We should add something like a .depth() property to 2D elements, but this may have difficulty coinciding with .z_index(), since that's just an index and not a concrete distance, so maybe we remove .z_index().
Editor
Building 3D perfectly in code is challenging. But in the case of Ply it must actually integrate itself with the rust code. I'm not sure how to do this yet.
Immediate Mode 3D
A big question is if we can hang onto the immediate mode paradigm for 3D. I think we can but it will require some MANAGER magic.
Breaking Free constraint from Macroquad
Moving away from macroquad to a custom backend will give us full control over depth buffers, z-sorting, and the modern graphics pipeline. There would be a lot of work here, but right now macroquad is quite a shackle on us.
Physics
A physics engine is a must for 3D. It must integrate seamlessly.
This is a discussion, not a feature.
Summary
Transitioning Ply to become macroquad-independent and introducing a first-class, Spline-inspired 3D API. This issue is intrinsically vague to serve as a brainstorming hub for how Ply can solve 3D in Rust without losing its code-first, zero-boilerplate roots.
Why
Right now, 3D games have two complex paths:
I would like an engine with the insane simplicity of Ply, combined with the visual ease of a tool like Spline. It must be simple, without macros or unreadable file formats, while remaining highly versatile.
Ideas
Since this is 2.0, we can break every backwards compatibility rule in the book. It will not be backwards compatible, but that does not mean we are deleting the beautiful layout API, just reworking some things.
3D Builder
We continue to leverage the builder pattern and closures. Something like this:
2D within 3D
2D and 3D should coexist. 3D probably exists within 2D (not sure), but 2D can also exist within 3D. We should add something like a
.depth()property to 2D elements, but this may have difficulty coinciding with.z_index(), since that's just an index and not a concrete distance, so maybe we remove.z_index().Editor
Building 3D perfectly in code is challenging. But in the case of Ply it must actually integrate itself with the rust code. I'm not sure how to do this yet.
Immediate Mode 3D
A big question is if we can hang onto the immediate mode paradigm for 3D. I think we can but it will require some MANAGER magic.
Breaking Free constraint from Macroquad
Moving away from macroquad to a custom backend will give us full control over depth buffers, z-sorting, and the modern graphics pipeline. There would be a lot of work here, but right now macroquad is quite a shackle on us.
Physics
A physics engine is a must for 3D. It must integrate seamlessly.