Page 1 of 1

Pre-defined Anchor Points and Variables

Posted: Sun Apr 27, 2014 2:33 am
by NauticalMile
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:

Image

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. :arrow: 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.

Re: Pre-defined Anchor Points and Variables

Posted: Thu May 01, 2014 7:38 am
by iforce2d
About pre-defined anchor points, I could see them being useful if you are continuously destroying and re-creating a joint in the same place over and over on the same bodies... but is that what you're doing? I think I would need a bit more concrete use-case to see the benefit.

About variables, that would be kinda nice to have, but I don't think I'm fully seeing the benefit of that either. At least, I can't see how the current scripting capability does not fulfill that need. Unless I'm missing something the function an expression would serve should be possible already in script, and you would need to code the calculation either way. What would be nice perhaps is more hooks for script to run automatically. Right now there is only one, which triggers after dropping images into the scene. It would be pretty easy to add more of these at various points in the program, for example after moving, scaling items etc. That would allow you to have a joint anchor automatically follow the ratio of a fixture size as in your example. Global variables can be implemented by adding custom properties to the world itself, since it is also an item.

About capsules, you could set a non-zero radius for a line shape with two points: http://www.iforce2d.net/rubehelp/conten ... tures.html

About patterning, I mentioned a little about that in my other post just now, hopefully you will see that there. It sounds like the 'in-place' style of template/instance editing would be a good fit for situations like that. Hmm... it might also be do-able if the script hooks I mention above were implemented. In the case of the wheel rim pieces being generated from a prototype piece, you could have a script that made all fixtures called 'X' update themselves by matching fixture 'Y'. Linking this to an "after fixture edit" event script hook would cause that script to run after every fixture edit. For large scenes it would need some smart check to make sure no unnecessary changes were being made. Now you got me thinking... :) I am working on auto-tracing of images at the moment and hoping to get the next version out in the next couple of weeks, if I can fit in some script hooks like this I will add them as well.

Re: Pre-defined Anchor Points and Variables

Posted: Fri May 09, 2014 3:51 pm
by NauticalMile
Pre-defined anchor points will be useful for nested objects, or objects that will be jointed to other bodies in the world. Nested objects will typically connect to their parents via joints.

E.g. If multiple parent objects share the same child, and one or more bodies on that child are updated in a design change, it could affect the logical choice of the joint anchor point that connects the child object to a parent. The problem is: the joints connecting the parent objects to the child are owned by the parent, and thus the child has no influence where the anchor point on the connecting body should be.

All this being said, I didn't appreciate the way I could harness the power of system hooks, when combined with custom properties. Once system hooks are introduced for editing events, I'll create some general scripts that will allow for this behavior, and I think you'll see its usefulness.

By the same token patterning and expression-like-behavior should be very doable. That being said I am now very much looking forward to the arrival of more system hooks. :geek:

Thanks for all your hard work iforce. :)