Hi Merlijn,
I don't think I agree with this...let me try to explain why:
I think the benefit of "range" being in the library is to avoid duplicate work. If (1) connectivity is in the library and (2) range is included in connectivity and (3) more than just Bricksmith uses this info then...
- While I am working I decide to set the range limits on a part I am using (a door or a hinge).
- I then submit this to the part tracker as a part update.
- If approved, any other apps using range limits pick this up for free.
In other words, I think the LDraw library is the best coordination medium between apps; I'd like to be able to recycle range data and not have every app that does physics have to rebuild this data by hand.
Let me also argue why non-physics apps might want this:
One reason why Alan asked me about connectivity in Bricksmith was that he wanted to be able to rotate groups of parts around their natural hinge point as an -editing operation-. In the attached picture, I built the classic space radar dish pointing forward because it's way, way faster to build when "on grid" - parts can be positioned rapidly on a grid without even having snapping.
But then when I want to tip the dish up, what I'd like to do is rotate a subset of parts around the hinge.
- In the current code, I have to manually enter the numeric rotate point as text. This is a giant PITA.
- With connectivity, Bricksmith would at least be able to know that the hinge has a rotation point around which to turn.
- With rotation limits, Bricksmith would also be able to know that the hinge can go from 0-90 and then must stop.
From an editing standpoint, this last case has the potentially to be a lot more user friendly: the rotation can be free and unconstrained by a grid and -still- not exceed the natural 0-90 bounds. For rotations where the user wants a tweaky weird angle (e.g. the angle is based on some trig relationship and isn't going to fall into a nice grid of every 3 degrees or 5 degrees) having the rotate be off grid but limited is the most user-friendly.
If there's a part that's going to collide, yes, AABBs are needed. But even without them I think that basic rotation limits make modeling easier.
There's no question that there's no -harm- in leaving limits off the spec...the whole design assumes editors will bring additional functionality to the table. But I also think there is an opportunity cost to not including this kind of data and requiring everyone to re-invent the wheel.
Cheers
Ben
I don't think I agree with this...let me try to explain why:
Merlijn Wissink Wrote:I quite like the idea of limiting hinges to what's possible in real life, but I think this has to be incorporated by the programmer programming the editor. I don't think something like that really benefits from being included in the library.
I think the benefit of "range" being in the library is to avoid duplicate work. If (1) connectivity is in the library and (2) range is included in connectivity and (3) more than just Bricksmith uses this info then...
- While I am working I decide to set the range limits on a part I am using (a door or a hinge).
- I then submit this to the part tracker as a part update.
- If approved, any other apps using range limits pick this up for free.
In other words, I think the LDraw library is the best coordination medium between apps; I'd like to be able to recycle range data and not have every app that does physics have to rebuild this data by hand.
Let me also argue why non-physics apps might want this:
Quote:Reason for that is that there's very little use of the limited hinges without other "physics" anyway. For example, if I add a few bricks onto the hinge, the limit in real life would change. In a editor without physics other than the limited hinges, the limited hinge feature already becomes useless.
One reason why Alan asked me about connectivity in Bricksmith was that he wanted to be able to rotate groups of parts around their natural hinge point as an -editing operation-. In the attached picture, I built the classic space radar dish pointing forward because it's way, way faster to build when "on grid" - parts can be positioned rapidly on a grid without even having snapping.
But then when I want to tip the dish up, what I'd like to do is rotate a subset of parts around the hinge.
- In the current code, I have to manually enter the numeric rotate point as text. This is a giant PITA.
- With connectivity, Bricksmith would at least be able to know that the hinge has a rotation point around which to turn.
- With rotation limits, Bricksmith would also be able to know that the hinge can go from 0-90 and then must stop.
From an editing standpoint, this last case has the potentially to be a lot more user friendly: the rotation can be free and unconstrained by a grid and -still- not exceed the natural 0-90 bounds. For rotations where the user wants a tweaky weird angle (e.g. the angle is based on some trig relationship and isn't going to fall into a nice grid of every 3 degrees or 5 degrees) having the rotate be off grid but limited is the most user-friendly.
If there's a part that's going to collide, yes, AABBs are needed. But even without them I think that basic rotation limits make modeling easier.
Quote:I think it's best to include nothing more than connection data and bounding boxes in a part. That way, there's nothing really specific like hinge limits and there's enough information for editors to do with it whatever they like.
There's no question that there's no -harm- in leaving limits off the spec...the whole design assumes editors will bring additional functionality to the table. But I also think there is an opportunity cost to not including this kind of data and requiring everyone to re-invent the wheel.
Cheers
Ben