Metadata

[winksaville]

I did a quick perusal of the code and don't see any actual use cases for metadata. The tests you have imply they shouldn't change, but it would seem to me that on an operations like union, intersection and union there might be specific semantics that the user of csgrs might want to have for their metadata.

For instance if you stored color and then used a union to combine them I'd guess the user would want to control what happens and that for some operations it might be desirable to have a trait MetaUnion that would be invoked if it existed.

Just thinking outloud, thougths?

[timschmidt]

Metadata was suggested by some of the Bevy devs. It's definitely one of the less mature parts of csgrs at the moment. I'd also like to be able to offer up polygons sorted by their metadata, but that requires Eq or similar on the Metadata type. Which I suppose isn't a big deal, but without a user championing that feature I've hesitated to make lasting API decisions. Want to keep this thread open to discuss ideas?

[winksaville]

Yes keep it open. As a neophyte, I don't have a lot to offer in the way of solutions. But I do have questions, which do have value in their own way ;)

[timschmidt]

Questions and discussion and bug reports and patches all welcome. Thanks for your interest in this little library. You've already helped solve a pretty big bug!

My first real uses for metadata are coming up in https://github.com/timschmidt/ironpath and https://github.com/timschmidt/partsrs, where I can use it for color / multi-material. I figure that will inform a lot of my choices going forward. So far I've just tried to keep it preserved and assigned appropriately through operations.

Tests are an area that need a lot of work. Many have grown irrelevant as the library has developed. It would also be nice to have an example render or two for each function, demonstrating it's use, in the documentation. If you run into any documentation you'd like to correct, while using it, feel free to let me know and I'll get the change in. It's been developed fairly quickly, so there are still some rough edges. Your help in finding / fixing them is appreciated. Can I ask about your interest in csgrs? Is there something you're working on or would like to do with it?

[winksaville]

I recently met a friend who is blind and they like to use Braille and they have a very old Braille Display (BD) but it's not working. And I've learned that BDs are very expensive, the cheapest one I've seen is only a 20 character BD and it's $800. The old one they have is an 80 character BD and they are very very expensize. For example, this 80 character BD is $9,500.

Anyway, I'm interested in seeing what I can do to help. To that end I'm going try to create an open source DIY BD using 3D printing, try being the operative word :)

For the initial experiments I'm going to try to use a solenoid for each dot and the first task is to create a 3D printable spindle for the solenoid coil. Hence, I need something like csgrs to create the spindle and other parts in the future. For the spindle I don't need csgrs to be no-std, but I want to get back into more embedded work so when possible I'd like libraries that are no-std.

[timschmidt]

Makes sense. I pulled in core2 recently, to attempt to get Cursor and Error in no-std, but the STL and DXF i/o code did not like it. So I'm thinking I may have to vendor those libraries in order to work the same change on them. Not much left after that though, I already switched all the constants over to core:: so std:: isn't referenced. Similarly switched to hashbrown for HashMap as that supports no-std, though still requires alloc. Open to solutions which don't.

My next big push with csgrs is nailing down errors for the whole library. Which is doable, and should result in a library which never crashes, at the expense of having to deal with the errors. A fair trade, I think. But I'm still building out major features like error handling, so I've had very little time to test, and really appreciate anything you can report about how csgrs works for you. Good or bad, it's all useful at this point. Let me know how I can make the library more useful for you, and I'll do what I can.

[timschmidt]

Here are the prototype functions I have currently commented out in csg.rs. One requires PartialEq, one requires Eq + Hash across the metadata type:

// Group polygons by their metadata.
//
// Returns a map from the metadata (as `Option<S>`) to a
// list of references to all polygons that have that metadata.
//
// # Example
// ```
// let mut csg = CSG::new();
// // ... fill `csg.polygons` with some that share metadata, some that have None, etc.
//
// let grouped = csg.polygons_by_metadata();
// for (meta, polys) in &grouped {
//     println!("Metadata = {:?}, #polygons = {}", meta, polys.len());
// }
// ```
// requires impl<S: Clone + Eq + Hash> CSG<S> { and use std::collections::HashMap; use std::hash::Hash;
// pub fn polygons_by_metadata(&self) -> HashMap<Option<S>, Vec<&Polygon<S>>> {
//    let mut map: HashMap<Option<S>, Vec<&Polygon<S>>> = HashMap::new();
//    
//    for poly in &self.polygons {
//        // Clone the `Option<S>` so we can use it as the key
//        let key = poly.metadata.clone();
//        map.entry(key).or_default().push(poly);
//    }
//    
//    map
// }

// Return polygons grouped by metadata
// requires impl<S: Clone + std::cmp::PartialEq> CSG<S> {
// pub fn polygons_by_metadata_partialeq(&self) -> Vec<(Option<S>, Vec<&Polygon<S>>)> {
//    let mut groups: Vec<(Option<S>, Vec<&Polygon<S>>)> = Vec::new();
//    'outer: for poly in &self.polygons {
//        let meta = poly.metadata.clone();
//        // Try to find an existing group with the same metadata (requires a way to compare!)
//        for (existing_meta, polys) in &mut groups {
//            // For this to work, you need some form of comparison on `S`.
//            // If S does not implement Eq, you might do partial compare or pointer compare, etc.
//            if *existing_meta == meta {
//                polys.push(poly);
//                continue 'outer;
//            }
//        }
//        // Otherwise, start a new group
//        groups.push((meta, vec![poly]));
//    }
//    groups
// }