Editor Prototype: Bevy Mesh Terrain Editor

[ethereumdegen]

This is an opinionated map editor for Bevy that is intended to be a standalone application. I am using it for my own game. It supports terrain painting (splat and height) as well as Doodad placement (basically, entity placement.) The doodads can be translated, given names, and given custom components for whatever the user may need.

Doodads can be exported in a Scene file or in special bundles called "zones" which are like sub-scenes with a simpler protocol. I think that this editor has a lot of good ideas AND is fully featured for my own personal purposes and so i want to share it with the bevy community for feedback and thoughts.

[ethereumdegen]

The general idea here is that this editor is purely designed to create 'data' for your game: that is, the terrain files data and the doodads files data. All game logic is meant to reside completely separately. The only things i was really lacking with Bevy were ways to create my terrain data and doodads placements data and so with this I am fully featured.

[cart]

Is the bevy_editor_pls vendoring necessary or could it use a git reference? Vendoring will make it hard to stay up to date, and also bloats the repo, so it should be a last resort.

[ethereumdegen]

I did think about this.. originally it was a git reference but it was a reference to my own fork. Unfortunately I changed a lot of things and I tried to make my changes decoupled but it was not possible for me to do so. Since it was a reference to my own fork anyways and so much had been changed, I opted to just bring it in to make it simpler. I do realize that this will make it more annoying for me to keep it up to date with bevy versions.

For example I added more menu options in the hierarchy and they reference my new doodad code and if that was in a separate crate, i would need to add that crate as a dependency to the standard_windows anyways. etc. etc.

I COULD make the pls_editor and pls_editor core be references but the standard_windows which has the majority of the code is heavily modified.

[BD103]

I did think about this.. originally it was a git reference but it was a reference to my own fork. Unfortunately I changed a lot of things and I tried to make my changes decoupled but it was not possible for me to do so. Since it was a reference to my own fork anyways and so much had been changed, I opted to just bring it in to make it simpler. I do realize that this will make it more annoying for me to keep it up to date with bevy versions.

I think in this case I would prefer it to be a Git reference, even if it was to your own fork. A fork let's us easily view what changes you made from the original, and it reduces the amount of code we have to maintain / update in the future.

[alice-i-cecile]

Closing out for now; this is useful prior art but given the direction we're taking I think this is liable to be a pretty messy thing to incorporate at this stage.