Box2D editor - R.U.B.E. Pro
Last edited: September 01 2012Development log
R.U.B.E is currently under development. This page has been added to at random times when something interesting was added, and it has become quite lengthy... click one of the dates on the left to jump to different sections.
(6 Jan 2012) The multiple document interface is mostly complete, but documents cannot actually be edited yet. Although some of the editing code can be taken from the free version, the next step is implementing undo/redo which is a non-trivial procedure and means that a lot of the editing code cannot be simply copied, and must in fact be written with more care than it originally was. At this juncture I'm also thinking that getting scripting functionality implemented early in the project will make things easier later on too - hence the long projection time for the first release :)
(17 Feb 2012) Items in the scene are given automatically generated names and can now be detected by mouse over, and their details are viewable in tootips. The problem of how to differentiate between and select items at the same location has been solved by showing a context menu in which all the items at that location are listed and can be selected by name. This context menu expands down the hierarchy of items, and as the focus moves around within the menu the tooltip is shown and that item is highlighted in the scene for clarity. 'Metafixtures' are used instead of dealing with b2Fixtures directly. Unicode support seems to be working well. Still can't actually select anything or make any changes to the scene yet :)
(22 Feb 2012) The built-in script editor uses Angelscript to access and alter items in the physics scene. This will be useful for repetitive tasks, or when items must be placed in exact positions, or based on offsets from other items, or following splines or mathematical curves etc. I am intending to associate every atomic action (eg select, move, delete, etc) with a script function so that scripts can be created by graphically manipulating the scene and recording the generated snippets as text. Theoretically, the entire process of creating a scene could be recreated from the script using the exact same actions the user originally took (this is a boon for debugging and user support!).
These action atoms will also form the basis of undo/redo commands. This raises the interesting possibility of being able to undo a few steps, then edit the contents of the script in the redo buffer before redoing - whether that will have any practical application is still hard to tell. Here is the result of a simple script which takes the first 250 dynamic bodies of the cars scene and arranges then in a sine wave:
Each opened document has its own script, and the contents of the script panel
changes as each document is made active. The script input area has syntax highlighting
for helpful feedback while typing. Script compilation errors are shown
below the main panel and the faulty lines are highlighted so they can be located easily.
The script is automatically compiled after a few seconds of inaction, similar to XCode4.
In addition to this 'current script' attached to each document, in future scripts may also be
registerable in the application so they can be bound to a keypress.
(5 Mar 2012) Added a textual browser so that items can be located without needing to find them in the graphical view. This is a tree view so you can drill down into the same structure as the context menu to select/deselect objects and change their names. The list is sorted and a filter can be applied to help find the objects in a large scene.
Undo/redo is now working for item selections, name changes and script execution. At risk of sounding like a broken record... you still can't actually save any changes to the scene yet :)
Here is the scene from my Ludum Dare entry with the filter 'car' applied:
(7 Apr 2012) Added the property inspector panel and implemented script access and undo/redo for all non-joint properties. This turned out to be a lot more work than I had thought, since virtually none of the code from the free version could be used... oh well.
I still have some thinking to do regarding methods for manipulating joints. It would be nice to have a more intuitive way to create and adjust them.
(8 Apr 2012) Added a built-in help framework. Angelscript provides methods for iterating over all existing object types and their functions, so this was a handy way of collecting accurate information on the scripting functions, and ensures none are missed out by human error. Human still has to write all the help text though...
(10 Apr 2012) Added a context help panel to ease the learning process. Although the Blender-style method of manipulating items in the scene is very efficient once you get the knack, I have to admit the first part of the 'learning curve' is quite steep. Video tutorials are probably the best way to overcome this but I believe the program itself should help as much as possible too - after all, it does know exactly what the user is doing.
Also improved the item list panel so that items in the scene are highlighted when the mouse
hovers over their name in the list.Finally started implementing movement of items, managed to use a little of the old code but even then it's mostly only as a guide as I type out the new version rather than refactoring. On the other hand the undo/redo works very nicely and I think the new system was worth the effort.
(20 Apr 2012) Translation of bodies, fixtures and vertices, and the undo/redo and scripting thereof is now done. The entire structure of how fixtures are stored and controlled has been changed, this took quite some time. The dedicated circle fixture has been dropped and a circle is now represented by a vertex list of one vertex. A 'vertex list' defines the path a fixture will follow but it has no visible/physical substance of its own. Instead, shapes will be mounted on the fixture and these shapes will use the points of the vertex list - for example a shape that was originally created as a polygon can be changed to a chain shape any time.
This was quite some work to implement but it provides a better foundation for things to come in the future such as splines, and also allows for supporting multiple shapes on one fixture (eg. fat lines, polygon with outer chain 'skin', or multiple chain shapes at different distances from the centerline).
Polygon decomposition has also been completed, apart from some validation checks. You can choose between the poly2tri library which creates a constrained delaunay triangulation and supports holes (but not yet for R.U.B.E though):
...or Mark Bayazit's algorithm which does not support holes (afaik) but
produces a more desirable result for use as rigid body colliders (less sharp pointy shapes):
As Bender might say, "fun on a bun!"
(25 Apr 2012) Implemented validation checks for polygon decomposition (decomposition will not be attempted for self-intersecting vertex lists). The check runs on every mouse move while manipulating vertices so the user can immediately see which segments are self-intersecting. To keep this efficient for large vertex lists, AABBs for every segment are kept to cut down on the number of segment/segment tests.
The polygon decomposition method will now fallback to poly2tri if the Bayazit method fails.
Also implemented basic 'fat' lines and polygons. Here is an example of how changing the radius will affect a line shape and a polygon shape. Notice these are all on the same fixture... only the shape type/radius has been changed between screenshots, to generate various Box2D shapes.
(6 May 2012) Basic manipulation (translation, rotation, scale) has been implemented for bodies, fixtures and vertices. Deletion of bodies, fixtures and vertices and the undoing of these deletions has also been implemented. Creation of b/f/v via the GUI is not implemented yet, but the underlying functionality for doing so is in place - that is, you can create b/f/v with a script. One bothersome thing about undo/redo is that whenever you start implementing an action, you also need to implement the reverse of that action. On the other hand, all that needs to be done now to create these items via the GUI is to run a script.
These latest changes can't really be shown in a screenshot, so here is a shot of something else that was done recently, some stress/performance testing.
... ok that wasn't so stressful. This smaller version is just shown first because in the next screenshot
it's not so clear what's in the scene. By the way, here is the script that produced this scene.
As you can see, a snippet of JSON is given to the functions which add bodies and fixtures to the scene. Please
note this is how the undo/redo system works, but it's not really intended for users to give definitions like this.
A more typical way of making settings would be with the member functions of each item as used inside the loop
(setType, setPos, setAngle etc). Likewise a fixture could be changed with member functions such as setDensity, setFriction, addVertex etc.Anyway, below is the real stress test, with each loop counter running to 100 instead of 10, to give a total of 10,000 bodies. On my PC (3GHz) this script takes about 1.5 seconds to run. Undoing the script is considerably slower at about 14 seconds. More important though is checking the behavior of the program with a large dataset, which was the purpose of this script.
Specifically, operations based on mouse movements are the biggest concern. With this test set, on my PC these kinds of operations (mouse over highlighting of items, panning scene with mouse) are quite tolerable until the number of items onscreen reaches about 4600 or so. Bearing in mind that the layout of items here is the pathological case, this seems quite reasonable... anyone regularly editing Box2D scenes with this number of items in one place probably needs their head checked anyway (click here to get an idea of what 4600 items onscreen looks like).
Even with the view as shown above with all 10,000 items visible, the mouseover selection highlight
follows the mouse at about 2-3 fps, and panning the scene also refreshes at about 2-3 fps. This is somewhat limited
by the capability of the graphics card, or at least it would be on a PC with a low-end graphics card. My
card (9800GTX+) is considered pretty ordinary these days, but its unlikely to be the bottleneck here. Rather,
the huge number of OpenGL primitive draw calls used to render the scene is probably the limiting factor. In any case,
editing a scene like this would be very rare so I'm satisfied with the performance for now.A more likely suspect for slowdown of the mouseover highlighting is the code used to perform picking of what item the mouse is over. Although it's not mentioned in the 17 Feb update, a lot of effort went into optimizing the mouseover pick to not consider anything that was not on screen. It's only now with the item creation script available that this can finally be tested properly. Although not checked thoroughly, given that the pan fps and the mouseover pick fps are about the same, it should be safe to assume that the picking code is not a bottleneck.
In future, it might be nice to have 'layers' to allow the display of certain items to be turned off and on. This would have the benefit of making editing easier as well improving performance. Recently when editing the fully rendered tank I found that having many fixtures in the same place was getting annoying. Some of the fixtures were clearly in very different roles (some were merely to attach a texture to, some were functional in preventing the tracks from getting messed up), so I really wanted to have a 'layers' feature. Incidentally that tank demo was made with the good old free version of R.U.B.E because this pro version still... uhhh... cannot save files :)
(4 Jun 2012) A lot of progress made recently but not much to show in a screenshot. The last big chunk of work (joints) has now been done. Joints can be added, manipulated, deleted, undo/redo all functional etc. Some improvement has been made over the free version for the setting of joint limits in revolute/prismatic joints, and the setting of axes in the wheel/prismatic joints, to make these slightly more intuitive.
All actions are now logged to a script log which will function as autosave data. You can paste the contents of the log into the script panel and execute it to reproduce the changes you made. Hopefully this will be useful as a crash report. It will also be handy for users of the trial version because the trial version will not be able to save the scene to json files in the normal manner. Although the script log does not provide a way to export data from the program, it still allows people to save their progress and come back to it later.
It's not a very exciting screenshot, but here is the menu for adding items to the scene, along with one of the script files that it runs. With all functionality exposed through scripting, features like this become quick and easy to add. This menu is defined in a json file, and each menu item corresponds to a script file. The program checks the modified time of the menu definition file and refreshes the menu if it has changed, and the script files are read afresh for every execution, meaning that this entire menu can be customized and added to on the fly. R.U.B.E will ship with some generic default actions in this menu, but users can easily set up their own entries for common tasks.
(18 Jun 2012) Added support for backing images. This was going to be added as an update at a later stage, but was brought forward since it's quite a handy feature, and the next task (saving+loading meta data for scenes) will have less unknowns if the backing images are already implemented. So the release date is no nearer than it was in the last update... but with a good excuse right?
Image files (only PNG for the time being) can be dropped into editor views and the images can be selected, moved, rotated and scaled in the same way as other items, and their properties can be edited in the property inspector. Undo/redo and scripting is not currently implemented for images, but it could be in future depending on user feedback, or if it becomes annoying not to have it between now and release.
Here is a game level with some edge shapes drawn over the top, up and running in just a few minutes.
(image taken from petermcclory.com).
(27 Aug 2012) Well although this page has not been updated much in the last couple of months there has been plenty of progress - just not much to show off in a screenshot. The major additions have been undo/redo for images, the ability to attach images to bodies (instead of just static backing images), exporting of all image info, a 'check for updates' feature and an integrated feedback dialog with screenshot capability, support for more image types, MacOS API changed to Carbon (hello Tiger :), a sample (C++) to load the data made by R.U.B.E, more script functions, and many bugfixes.
Apart from work on the program itself, recently a lot of time has also been going into setting up a new section of the website to host the user pages where purchasers will be able to log in and download the full version, and the database etc to run this, along with a nifty release notes management system, and a novel way of individually building each binary on the fly for all three operating systems.
And at long last, work has finally begun on proper documentation. Bearing in mind that the documentation is still a work in progress, if you would like to take an early look at the trial version of R.U.B.E, now you can! Head over to the new pages here:
www.iforce2d.net/rube
If you are new to R.U.B.E you might like to check out the 'Getting started' section of the help.
And don't forget, any feedback is much appreciated!
