Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplication of components possibility #9

Open
Type1J opened this issue Jan 11, 2023 · 2 comments
Open

Duplication of components possibility #9

Type1J opened this issue Jan 11, 2023 · 2 comments

Comments

@Type1J
Copy link

Type1J commented Jan 11, 2023

Components have a type, and only 1 component of a given type is valid. In your README.md, you say that parsers should reject multiple component entries with the same type. Instead of an array, why not make this a Map (BTreeMap or HashMap in Rust) to make the invalid versions unrepresentable?

@sdfgeoff
Copy link
Owner

Good question!

When messing around with parsing this lot in Rust, I ran into issues composing Components from different sources (eg if you have a game that has 3 extra components, and want to tell the parser to use it as well as the Rapier and Base components). Also, it is not trivial to iterate through the components of a struct.

That said, I'm now having issues figuring out why I thought it would be any easier with a Vec, so IDK.

Also, I ran into other issues, namely:

  • How do you represent links to other objects (eg a joint component)?
  • bevy gltf importer distorts the scene heirarchy upon import! It inserts extra entities. This caused me a bunch of confusion.
  • Making things work in both rust's static type system and blender's (relatively) static UI system both require extensive fiddling

That made me lose motivation to work on this as I needed to play too many innovation tokens on tooling. I wanted to make a specific project, sank a couple weeks into realizing that I couldn't get the data into bevy in any way other than hand–coding it at import time, and so gave up and did it in a custom fork of Godot which took 2-3 hours to add the feature I needed to the physics engine.

The tooling for Bevy just isn't quite there yet, and unfortunately I have other things I'd rather do in my free time at the moment than work on infrastructure. (I'd rather make games than make tools to make games. At this point in my life I'd rather do physical exercise/socialize than solve complicated tooling problems in my hobby time) So it's probably up to someone else if they want to take the idea and run with it.

I still like the idea presented in this repo and I'd love to try making a game with bevy in 6 months and discover this all just works. So if you want to be the guy to make this into a thing – go right ahead :)

@Type1J
Copy link
Author

Type1J commented Jan 12, 2023

I know very little about Blender's Python scripting system, but I think that I know a good bit about Rust, and Bevy isn't too far from many ECS engines, but there are features that just aren't there, and maybe that's what ultimately caused your issues. I don't have time, right now, but I do like your .scn file Blender exporter and Bevy importer (Thanks for those, by the way!), so I'm going to attempt to use them, for now. If I get stuck, and have go into the code to fix things, I'll add a PR. GLTF, for now, may be less 1-to-1 from Blender to Bevy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants