Pre-defined Anchor Points and Variables
Posted: Sun Apr 27, 2014 2:33 am
I thought of these Ideas while writing my other post today and decided to move them into a new thread where they are listed in the topic.
Nested objects, Joint Ownership, and Pre-defined Anchor Points
I have a strong opinion about how joints should be stored, which I elaborated on in this stack exchange answer. The upshot of it is that I believe RUBE objects should function similarly to entities in an entity component system, and it would be really good to define potential anchor points in objects, which parent objects may reference to join child objects together. I could accomplish this with scripting and custom properties, but it couldn't be represented visually. It would be so much nicer just select pre-defined anchor points in the editor and create the joint.
Variables
Another thing that CAD software provides is variables. Sometimes I found myself thinking 'I want this anchor point to be at 3/4 of the width of this fixture and about 10% higher than the origin'. Or 'I think I want this fixture to be twice as dense as that one.' In both of those cases, I have to do a little math to figure out what numbers to enter, and If I change any dimensions or densities, then I have to remember the dependent properties that have to change, and update them. In CAD, I can overcome this by defining variables. When a variable is defined based on model parameters, I can enter a simple expression using that variable into a numeric field, and the model would calculate the desired dimension. When the variable is changed, dimensions which depend on that variable are automatically updated.
Capsule Example
Consider the common capsule shape:
If I want to change the width, I have to edit the box vertices and move the circles. If I want to change the height, I have to edit the box vertices, and change the radius of the circles. If I could instead create variables, I could link the circle positions to the box width, and their radii to the box height.
As a side note, this would still be useful if the variables were not dependent on scene properties, but only defined by the user. Then, in the above example I could just define parameters w, and h and set the box vertex x co-ordinates and the circle positions as +/- (w-h/2), and the box y co-ordinates as +/- (h/2). The circle radii would also be set to h/2.
In both these cases, I would just need to change one value, and the dimensions of the capsule would change appropriately.
This capsule example also shows the need for having variables at the object scope as well as global variables (scene scope)
Patterning
iforce2d has a couple of youtube videos that show how to do patterning using scripts. But unfortunately those patterns are dumb. I don't mean stupid-dumb. I mean that once they are constructed, they don't contain any references to the original body/fixture and if you want to change anything you have to undo and edit the script that created it. If you could locate things using variables you could have patterns that actively updated.
To be clear, these dependencies need not be maintained in the exported .json files. On export, all expressions would be evaluated numerically.
Nested objects, Joint Ownership, and Pre-defined Anchor Points
I have a strong opinion about how joints should be stored, which I elaborated on in this stack exchange answer. The upshot of it is that I believe RUBE objects should function similarly to entities in an entity component system, and it would be really good to define potential anchor points in objects, which parent objects may reference to join child objects together. I could accomplish this with scripting and custom properties, but it couldn't be represented visually. It would be so much nicer just select pre-defined anchor points in the editor and create the joint.
Variables
Another thing that CAD software provides is variables. Sometimes I found myself thinking 'I want this anchor point to be at 3/4 of the width of this fixture and about 10% higher than the origin'. Or 'I think I want this fixture to be twice as dense as that one.' In both of those cases, I have to do a little math to figure out what numbers to enter, and If I change any dimensions or densities, then I have to remember the dependent properties that have to change, and update them. In CAD, I can overcome this by defining variables. When a variable is defined based on model parameters, I can enter a simple expression using that variable into a numeric field, and the model would calculate the desired dimension. When the variable is changed, dimensions which depend on that variable are automatically updated.
Capsule Example
Consider the common capsule shape:
If I want to change the width, I have to edit the box vertices and move the circles. If I want to change the height, I have to edit the box vertices, and change the radius of the circles. If I could instead create variables, I could link the circle positions to the box width, and their radii to the box height.
As a side note, this would still be useful if the variables were not dependent on scene properties, but only defined by the user. Then, in the above example I could just define parameters w, and h and set the box vertex x co-ordinates and the circle positions as +/- (w-h/2), and the box y co-ordinates as +/- (h/2). The circle radii would also be set to h/2.
In both these cases, I would just need to change one value, and the dimensions of the capsule would change appropriately.
This capsule example also shows the need for having variables at the object scope as well as global variables (scene scope)
Patterning
iforce2d has a couple of youtube videos that show how to do patterning using scripts. But unfortunately those patterns are dumb. I don't mean stupid-dumb. I mean that once they are constructed, they don't contain any references to the original body/fixture and if you want to change anything you have to undo and edit the script that created it. If you could locate things using variables you could have patterns that actively updated.
To be clear, these dependencies need not be maintained in the exported .json files. On export, all expressions would be evaluated numerically.