Hi Y'all,
@Mario, thank you for posting the updated spec!! I think your model is pretty close to the design I've been working on for Bricksmith. My design is similar to yours (and dissimilar to Roland's) in that all matching is done by male/female pairs whose data-defined type codes define them as matches; I'm not looking to do geometry fit.
@Jakub, I am curious about this too; I'd feel more secure in my proposed data model knowing that a logical extension for gears wasn't going to invalidate the universe. But I only have two ideas and they are both "not very good".
1. Model every gear tooth as being "solid" the way we would to stop bricks from colliding and let a physics package try to combine the force from the gear teeth with the constraints of pins to put gears in motion. I don't like this because it's asking a lot from the physics package and gives us no guidance for properly placing or designing gears.
2. Define a new connection type that is sort of like a "radial rail" that wraps around the tooth-bearing surface that is the gear. Thus two gears connect if their radial rails are tangent at some point; similarly a rack can be a rail that mates with the radial rail. This has all sorts of fun issues:
- It can't handle worm gears at all. :-(
- It's not even remotely obvious how male/female connections are made - unlike all other connection types, this one is really "any gear with any gear".
- Not all gears have the same connection class.
But at least we'd have the meta-data to say "if these two gears are at this distance, they mesh up (and their relative rotations must be X to avoid tooth collisions - snapping or a grid can be applied to the tooth surface connectors.
In theory this expands to belts too if they are tensioned...please, no one model a 10-speed bicycle. :-)
@Mario, no offense, but I consider "a snapping connector at every tooth and tooth gap" to also be in this category of close-but-problematic solutions. :-( Under normal operation you'd have some teeth "very close" but not snapped in a rack-and-pinion assembly, for example, and it would be not much more useful than just having solid collidable-surfaces in terms of physics analysis.
Anyway, if anyone has some idea that's much more clever, I'd love to hear it.
Cheers
Ben
@Mario, thank you for posting the updated spec!! I think your model is pretty close to the design I've been working on for Bricksmith. My design is similar to yours (and dissimilar to Roland's) in that all matching is done by male/female pairs whose data-defined type codes define them as matches; I'm not looking to do geometry fit.
@Jakub, I am curious about this too; I'd feel more secure in my proposed data model knowing that a logical extension for gears wasn't going to invalidate the universe. But I only have two ideas and they are both "not very good".
1. Model every gear tooth as being "solid" the way we would to stop bricks from colliding and let a physics package try to combine the force from the gear teeth with the constraints of pins to put gears in motion. I don't like this because it's asking a lot from the physics package and gives us no guidance for properly placing or designing gears.
2. Define a new connection type that is sort of like a "radial rail" that wraps around the tooth-bearing surface that is the gear. Thus two gears connect if their radial rails are tangent at some point; similarly a rack can be a rail that mates with the radial rail. This has all sorts of fun issues:
- It can't handle worm gears at all. :-(
- It's not even remotely obvious how male/female connections are made - unlike all other connection types, this one is really "any gear with any gear".
- Not all gears have the same connection class.
But at least we'd have the meta-data to say "if these two gears are at this distance, they mesh up (and their relative rotations must be X to avoid tooth collisions - snapping or a grid can be applied to the tooth surface connectors.
In theory this expands to belts too if they are tensioned...please, no one model a 10-speed bicycle. :-)
@Mario, no offense, but I consider "a snapping connector at every tooth and tooth gap" to also be in this category of close-but-problematic solutions. :-( Under normal operation you'd have some teeth "very close" but not snapped in a rack-and-pinion assembly, for example, and it would be not much more useful than just having solid collidable-surfaces in terms of physics analysis.
Anyway, if anyone has some idea that's much more clever, I'd love to hear it.
Cheers
Ben