Page 1 of 1

Some requests and some +1s

Posted: Mon Jul 01, 2013 5:47 am
by bukbukbukark
Here's a load of thoughts, in rough order of importance to me. I've seen reference to a feature voting page but I can't find it, so apologies if there's a load of repetition here. I found the proposed future updates page, so I've at least avoided some repetition :0)

* +1 for a custom property type that is a link to another item. I'd just like to clarify what I'd want from this. As others have noted, you can work around this by simply using a string property and typing in the name of the item you want to link to, and this is what I currently do. The problem is, when you duplicate items that are linked together, the links will still be pointing back to the original items rather than the duplicates. So for this feature to be truly useful it would need to handle duplicating items intelligently, and rewire any links to the new items.

* +1 for grid snap, I've posted an idea for how this could work into that thread.

* +1 for spline support. The potential problem with this (apart from all the UI issues!) is there are any number of methods of generating good-looking but not-excessive line segments from the curve descriptions, so there wouldn't necessarily be a 1:1 relationship between the Player and the game code any more, but that's not a big deal to me. I wouldn't expect to use the Player much, if at all.

* Pulley joints

* Groups. I currently use Inkscape for level creation, and use its Groups extensively. They are a little complex in the UI, but basically you can select multiple items and group them, creating a Group item that they then nest under. You can freely add to or remove from the groups, but this does rely a lot on Inkscape's tree view of the xml code, so it might be a tricky thing to add to RUBE. The reason this is so important to me is the fact that you can give Inkscape Groups properties just like any other item, and using this I can simplify tasks like scripting multiple objects simultaneously (eg for complex moving scenery), and unifying multiple images into single atlas-based meshes.

* +1 for layers, or at least some kind of organisational tool. A freeform tree view would be ideal to me, so the user could do any sort of nesting and organisation they need. And it would make my Groups request easier to deal with :0)

* I'm not sure if this has been requested before, but it would be great to be able to nudge items up and down the render order. The current type-in render order is definitely useful, but generally I'd be fine just with order of creation. A tree view would be good for this too :0)

* +1 for some kind of instancing solution, preferably with the ability to have the sources for instances kept in separate files.

* Tool for calculating the axis for prismatic joints based on where the bodies are, and/or placing items where Box2D is going to want to place them (I currently have a bit of patch-up code that projects body B onto the prismatic axis, a tool for this in RUBE would be much better) (and this is perhaps more about me learning the RUBE UI better, but it still might be useful).

* Selecting bodies by clicking within any of their fixtures/images, in addition to clicking the glowing ball. A minor point though :0)

* It would be good to make any new items created (by adding them new, or by copy & pasting) automatically selected, so you can immediately work with them (translate, rotate etc).

* It would be great to have multiple rooms within a file. I work around this by simply having big boxes that denote rooms' extents, and a bit of game-side processing to put items in their correct rooms, but an official way to make rooms would be brilliant. Items would still need to be able to reference items in other rooms. Rooms would ideally have editable properties.

* +1 for simpler collision filtering. I currently use strings defining object groups, so an 'official' method along similar lines would be great. (eg I have groups like 'Player', 'Enemies', 'Bullets', 'Static scenery' etc...)

* Some other things I've thought of could probably be addressed simply by having script callbacks. I'm not sure if these already exist but having scripts that run on startup, that are notified on things like creating new items, would allow folk to roll their own solutions to many needs.

...this is just from a couple of hours checking out RUBE, so I've no doubt there are workarounds for a lot of this stuff.

Some of these things that aren't currently in RUBE are unfortunately vital to me, but all the stuff that RUBE does currently do is very impressive, good work!


Re: Some requests and some +1s

Posted: Tue Jul 02, 2013 6:11 pm
by iforce2d
ohh Dave... my new best friend :)

- custom properties that link to another item
Definitely a great idea. It seems to me that this would require items in the exported JSON to be given some kind of unique id (eg. int) so that the user can gather them after loading, eg. getBodyById, getFixtureById. As it happens, the editor internally already does this because it's necessary for the undo/redo system to find which objects to deal with (you can see the ids in .rube files). Perhaps this could be exposed in exported files too. The other issue is how to select which thing should be linked to, which I guess could be done in the same way as choosing a body for a joint or image (click button in properties panel and then choose body in scene).

- spline support
This would be implemented by treating vertices of a fixture as the control points of a spline, and the actual Box2D fixtures would be generated based on that, similar to the way multiple actual Box2D polygons for concave polygon are generated from the original concave one. Options would be given for spline type (bezier, catmull etc) and min/max spacing of actual edge segments, and maybe a few more to facilitate hollow pipes.

- groups
Custom properties can be made to tag items as belonging to some category, which is a little more flexible than a tree where things can only be in one group (presumably... I have never used Inkscape).
I have plans to add script functions to get items by custom property, which would allow you to script multiple objects with the same tag. However, since there is no parent item for the tag, it does not give you anything to set properties in. Will have a think about that...

- layers
This also would most likely be more like a tag system, so that items could belong to more than one layer. Come to think of it, it does indeed sound a lot like the groups I just mentioned, except that it would be implemented in the application itself rather than script. Layers would typically be used to show/hide things in the editor view to help un-clutter the scene, and also most likely as a method for grouping things into foreground/background, eg. for parallax layers. Hmm... it might be good if tags could be designated as mutually exclusive or not - sometimes you might want to make sure an item cannot have both foreground and background tags.

- render order
Sometimes I think it would be nice to say for a pair of two images, which should be in front, and let the program deal with the actual render order enumeration when exporting. Internally the program would bubble sort them to get appropriate numbers. This would make it easier to set up areas where a lot of images are overlapping, because otherwise you need to keep a cache of render orders in your head to know what order to give them.

- prismatic joint axis calculation
Not sure what you mean here I'm afraid. When setting the limits of a prismatic joint (hit 'L') you can see where Box2D is going to want to place body B, and slide it along the axis to help you see the path it will travel on, if it will hit anything along the way etc. So you can hit 'L' just to see that without actually setting the limits. Same goes for revolute joints.

- selecting bodies by clicking within their fixtures/images
Good idea!

- make bodies selected after creation
Consider it done, I'll add an option in the settings dialog.

- multiple rooms
Not sure what you mean here either... is this specific to a certain type of game?

- simpler collision filter settings
I get the feeling you might have missed the collision bitplanes panel, which was added in the last update. You can see a bit about this in the help under Editing items -> Editing fixtures, or in this video from about 4:04

- script callbacks
There are some major improvements for scripting coming in the next update, including the ability to read and write files, #include other scripts, and have multiple scripts open and editable at the same time in the script panel. Scripts can be bound to keypresses, or other events in the program to act as callbacks. The first release of this will probably just include a callback to do something with images after dropping them into the scene, but will be expanded later for other things like just before export, or just after opening a file etc.

Really appreciate this feedback, thanks!

Re: Some requests and some +1s

Posted: Wed Jul 03, 2013 7:21 am
by bukbukbukark
Hehe! :0)

ALAS - I'd written up a fulsome reply, but like an arse I clicked on that youtube link and lost it all. I thought I'd set up all links to open in new tabs, that'll teach me.

Quick short version then:

- custom properties, sounds perfect

- spline, sounds very good, I have some suggestions for how to edit them, also you might want to check out Anti Grain Geometry for a very neat curve approximation algorithm, it produces nice looking curves with fewer line segments, I had a simple line-length algorithm initially but replacing it with the AGG gave me back a few fps from simpler geometry as well as looking slightly nicer

- groups, I just read your explanation of instantiation, and the 'object' you talk about there sounds perfect. If an 'object' has a presence as an item, and editable properties, then that would be perfect

- layers, tags sounds great actually, if tags could appear in the combo-box at the top of the item list that would be pretty awesome

- prismatic, I must have done something odd, it seems fine now. But still, a tool to generate the local axis so it runs along the two bodies origins would be neat, also the other way so bodyb projects onto the local axis. But not a big deal.

- multiple rooms, yes, like a mario level that is split into separate rooms. Not a biggie, more wishful thinking

- collision filtering, I'll check this out AFTER HITTING SUBMIT THIS TIME, sounds perfect

- script callbacks, sounds epic


Re: Some requests and some +1s

Posted: Wed Jul 03, 2013 7:25 am
by bukbukbukark
The collision filtering looks awesome! I had indeed missed that.

I'll be sure to watch the rest of the video before I say another word.

Those combustion engines are amazing, good work :0)

Re: Some requests and some +1s

Posted: Fri Jul 05, 2013 2:27 am
by bukbukbukark
The spline editing suggestions and one other thing:

- splines

Not sure if you intended to have a specific spline fixture, but just in case, I'd say you should keep the curve info at the vertex level rather than the fixture level. Each vertex would have a few different types that it could be:

* No handles, where the vertex is part of two straight lines. Equivalent of what you have right now.
* 'Corner', where there are no restrictions on how the handles are placed, and there can also be either two handles or just one handle if the vertex is part of both a straight line and a curve.
* 'Smooth', where there must be two handles and they are restricted to being collinear. You can still move the handles freely, but as you move one handle, the other handle also moves to stay in line.

...and you'd be able to freely change which of these types each vertex is.

For the UI, you could almost get away with editing the type in the existing vertex property list, although some buttons in the toolbar would probably be nicer. And you'd still need a simple way to remove handles from a curve and turn it into a straight line, which I guess would have to be done either from a button on the toolbar while you have all the relevant verts selected (to me, the preferable method), and/or by having the ability to simply delete handles.

I don't think you'd need to go any further than that. There could always be scripts to do more fancy smoothing.

- groups

I'm not sure if I was very clear with what I said, so just to be sure - I meant that your proposed 'object' sounds like an ideal replacement for the group thing I was asking for. So if you do instantiation, and do it using the object idea, the only thing I'd need would be for each object to have editable properties in the UI. This would be a really powerful feature!

Re: Some requests and some +1s

Posted: Fri Jul 05, 2013 7:58 am
by iforce2d
hmm.... good point. Yes, the curve info would remain at vertex level and you would simply choose what kind of spline you want to generate from it, in the same way as you can switch between polygon, line, loop etc shape types already. I had not considered making it possible to switch between straight edges and spline at a vertex boundary, but that would be really neat. In fact I had not considered handles at all, I was just thinking to use the bare points to generate the spline...

One nice feature of using the same points for various shape types is that you can put multiple shapes onto the same fixture, for example you can have polygon, loop and circle shapes on the same set of points, like this:
multipleShapes.png (31.25 KiB) Viewed 13607 times
Note that the UI does not expose this, I had to edit the .rube file, but the foundation is there to be exposed in future. That's why the purple 'Shapes' section of a fixture has a tree structure. Here is the .rube file, so you can see how moving the points affects all the shapes:

Following this design, ideally the points themselves should remain oblivious to the shapes that are being built on them, so it would be nice if the information defining which points are a straight/curve boundary could be kept in the shape. That seems like the only way to handle having multiple splines on the same points. Then again, the information about straight/curve switching, and handles, is intrinsically linked to a specific point... holding that info in the shape would require an awkward-looking list of some sort.

Hmm... thinking about it a bit more, even if multiple splines were made on the same points, the chances of the user wanting different straight/curve switching and handles for each spline is probably very unlikely. Just to illustrate what I am thinking of for having multiple splines on the same points, suppose you had settings like this under the purple 'Shapes' section of the fixtures properties:
[Spline, splineType=naturalcubic, type=chain, offset=1, minSegmentLength=0.1, maxSegmentLength=5, maxAngle=30]
[Spline, splineType=naturalcubic, type=chain, offset=-0.5, minSegmentLength=0.25, maxSegmentLength=5, maxAngle=90]
multipleSplines.png (13.58 KiB) Viewed 13607 times
...which might give you something like this:
The black line is the spline following the points, and the red and blue are the actual Box2D chain fixtures generated. The idea is you could make nice pipes and tubes by having multiple offsets. In future, maybe other arrangements like fat pipes and polygons generated from closed splines could be added too.

Now that I look at this, I can't think of a situation where you would want to have multiple splines on the same points, but with different control handles. I guess you are right, the straight/curve switch and handles info can be a property of vertices themselves.