Hi Y'all,
@Roland, I think one of the things that makes connectivity tricky is that there is clearly some kind of overlapping core information that:
1. Almost certainly belongs in the part library to be generally useful and
2. Is used by a wide variety of different applications, not all of which need all of the data.
So use cases include:
- Aiding users in creating models (e.g. part snapping).
- Validating "physical possibility" of models (e.g. detecting illegal connections or a lack of connectivity that could cause the model to fall apart).
- Simulating real-world physical behavior (e.g. "what does the technic model do when I turn the steering wheel")
- Determining legal motion for animation (e.g. "I want to capture the fact that the doors open")
- Determining legal motion for modeling (e.g. "I want to rotate the entire radar dish up 45 degrees around the 1x2 hinge brick").
So...lots of different uses, not all of which need the same stuff.
I think Mario's looking heavily at creating models; I am looking equally at determining motion for editing (so that complicated irregular-angle modeling is easier) and at determining physical behavior as a precursor to animation (e.g. the program determines movable parts of the model and key framed poses from physics, not by hand editing).
I don't think gear support is necessary in an initial connectivity spec, but I'd like to understand how it would work to avoid having to throw out the entire design later.
@Philippe, interesting that SR3D uses a "rail around the gear teeth" model for technic bricks...re-reading my original criticisms of this technique, I must admit, the only real problem is that a worm gear has to be special cased...not -that- bad for something so complex. In a previous discussion of SR3D and connectivity, Sergio said something like "it is a work, and it is a working work" - that is, he picked a pragmatic approach that allowed him to actually code a working app. Perhaps "teeth rail connectors" are the most pragmatic solution.
@Mario, I agree, other than the worm gear, all other issues with using connectors around the rails are solvable. The connection logic is more complex, but not insurmountably so.
I've also been meaning to compare your connector types to some of the other connectivity models that have been proposed; I think what you have is a strict subset of all possible connectors with less than six degrees of freedom, but I haven't had time to dig into that yet. (My goal is to have a clear mapping from connection type to the degrees of freedom, so that it's clear how to build a physics-engine model directly from connectivity data.)
@Orion, agreed; for technic models this is desirable both for doing the modeling and for any simulation of behavior later.
Cheers
Ben
@Roland, I think one of the things that makes connectivity tricky is that there is clearly some kind of overlapping core information that:
1. Almost certainly belongs in the part library to be generally useful and
2. Is used by a wide variety of different applications, not all of which need all of the data.
So use cases include:
- Aiding users in creating models (e.g. part snapping).
- Validating "physical possibility" of models (e.g. detecting illegal connections or a lack of connectivity that could cause the model to fall apart).
- Simulating real-world physical behavior (e.g. "what does the technic model do when I turn the steering wheel")
- Determining legal motion for animation (e.g. "I want to capture the fact that the doors open")
- Determining legal motion for modeling (e.g. "I want to rotate the entire radar dish up 45 degrees around the 1x2 hinge brick").
So...lots of different uses, not all of which need the same stuff.
I think Mario's looking heavily at creating models; I am looking equally at determining motion for editing (so that complicated irregular-angle modeling is easier) and at determining physical behavior as a precursor to animation (e.g. the program determines movable parts of the model and key framed poses from physics, not by hand editing).
I don't think gear support is necessary in an initial connectivity spec, but I'd like to understand how it would work to avoid having to throw out the entire design later.
@Philippe, interesting that SR3D uses a "rail around the gear teeth" model for technic bricks...re-reading my original criticisms of this technique, I must admit, the only real problem is that a worm gear has to be special cased...not -that- bad for something so complex. In a previous discussion of SR3D and connectivity, Sergio said something like "it is a work, and it is a working work" - that is, he picked a pragmatic approach that allowed him to actually code a working app. Perhaps "teeth rail connectors" are the most pragmatic solution.
@Mario, I agree, other than the worm gear, all other issues with using connectors around the rails are solvable. The connection logic is more complex, but not insurmountably so.
I've also been meaning to compare your connector types to some of the other connectivity models that have been proposed; I think what you have is a strict subset of all possible connectors with less than six degrees of freedom, but I haven't had time to dig into that yet. (My goal is to have a clear mapping from connection type to the degrees of freedom, so that it's clear how to build a physics-engine model directly from connectivity data.)
@Orion, agreed; for technic models this is desirable both for doing the modeling and for any simulation of behavior later.
Cheers
Ben