Polygon Vertex List

[joolean]

Don't know if this is already possible but I can't find it.

I've been using Box2d Body Editor before Rube to create my map levels and in the json it exports, it includes a vertex list for the full polygon, not just the convexed ones.
Is this available somewhere or can it be implemented?

I use the convex polygons for Box2d naturally but I use the full polygon vertex list in order to construct the texture map for the whole polygon. This is the difference between one polygon with hundreds of vertices as opposed to tens of polygons with 3 to 5 vertices.

Alternatively, is there any sequence by which the convex polygons are exported to json so that I can reconstruct the full polygon myself?

It'd be great too if you could simply left click and move vertices around rather than having to click and press 'T' every time. It's really cumbersome for editing existing polygons. Maybe add another 'E' press that goes into a simple moving mode?

Cheers.

Btw, very awesome piece of software from a software design perspective.

P.S. What's the deal with the weird captcha for registration? Took me several minutes just to find and construct the split country names to the left and bottom of Spain.

[iforce2d]

You can set a fixture to be a loop type, which will save a more simple list of vertices with no polygon decomposition interfering with the ordering. You can duplicate an existing polygon to get it in the exact same place, and you can delete it after loading if it messes up the behavior of your game somehow. That's the best option at the moment.

I might add another movement method sometime that uses visual widgets to grab and move the selection, but it has not been voted too highly so far.

What's weird about the captcha? It's intended to be hard for a bot to answer, and I figure since people are using the net they can easily check a map. If you run a forum sometime, you will quickly find out how pervasive the spam bots are

[joolean]

Ah freakin awesome on the loop type. Thanks so much. That makes me very happy.
I'd given up and reverted back to using Box2dBodyEditor again but can give that the flick now.

I'd say moving things around is probably the most common operation everyone does. Having to press T before every move is, dare I say it, Tedius? What about having move as the default operation and then S, R or whatever for alternative stuff. The left click drag in Rube doesn't seem to be occupied by anything else except group selection, but you could just use ctrl or shift modifiers for that. Anyway just my two cents.

I will trust your word on the captchas. Given how hard even the visual ones are to read these days, I guess the spam bots must be getting much better at their jobs.
Thanks for your help.

[iforce2d]

Actually I think selecting things is the most common thing everyone does, and selecting something without intending to move it is very common too. Personally I would find it:
- more tedious to make sure that the mouse is dead still before clicking on something for fear of moving it a few pixels unintentionally
- inconvenient to have the mouse cursor always sitting on top of the thing while I move it
- difficult to zoom with the mouse wheel while also holding down LMB during movement
- likewise, awkward to pan the view, or use shift+RMB (area zoom) while dragging
- awkward to make large movements and place things precisely when using a trackpad

If you would like to try this though, let me know which OS you're using and perhaps I can set up a build for you (if you purchased PM me the email). It shouldn't be too difficult to get running. Work is killing me this week though, so it might take a day or two before I can get around to it.

[joolean]

Haha. As soon as I wrote that, I knew you'd mention about items moving a bit when trying to select them. You could select first, as you already have to do, and only then move on the second click drag. But that's not what I'm thinking of anyway.

Just to demonstrate my own use case, In RUBE I have to click a vertex, press T and then click again at the new position which is three operations on two input devices. In the other software I'm using, I simply click and drag a vertex in a single operation (no selection step). When I'm creating many levels and pushing hundreds of individual vertexes around each level, that really adds up.

All the points you made are right, but they also represent just one use case, and your software is going to be utilised by lots of people in many different ways. Your software is also much more powerful than the one I'm referring to and has more complex input needs but if you could add that ease of editing as perhaps a mode in your software, that would really be great. You have a mode for inserting many vertices fairly easily, but editing lots of them is not as easy. The quickest way to move something, is to just click and move it.

In any event though, I don't mean to waste your time on my thought bubbles. I only bought the software recently and these were just some of my impulse reactions based on the previous software I was using.
You're very generous with your time and I wouldn't entertain you wasting it on custom builds. I can get by utilising both softwares for different aspects but maybe just something to consider for future builds.

[iforce2d]

Thinking about this a bit more, it really is a good case for having another sub-mode, and as you suggested the 'E' key is the place for it
Specifically, it would probably be piggy-backed onto the first 'E' mode (where the points are shown as hollow circles and you can add them along edges). The difference would be that when the mouse was close to an already existing point, clicking LMB would start a movement of the existing point. This would mean that you couldn't add a new point too close to existing ones, but zooming in a bit would let you place them closer if necessary.

[joolean]

Yes that would be perfect thanks.
But please to make it so that you just click and drag the vertex in a single op, not click to select, move the mouse to translate and then click to release. I get that the latter has the advantage that you can pan and zoom mid translation however that is already catered for and wouldn't really be much improvement over the current situation.
Thanks.

[iforce2d]

ah, you read my mind again... I would be loathe to break the consistency with all the other manipulation style elsewhere in the program, but I'm sure a checkbox in the options to do it whichever way the user prefers would keep us all happy

[joolean]

Lol, when you wrote
"The difference would be that when the mouse was close to an already existing point"
I was like, hangon a sec.

It seems to me the way it works at the moment is so you can pan and zoom mid operation, but has the downside that it adds more keypresses/mouseclicks to every operation whether you use pan/zoom or not.
How about having another global mode that does the opposite?
Mode 1 (Operation based):
a. Click mouse to select item
b. Press modifier TRS
c. Move mouse to modify. Can pan/zoom in here
d. Click mouse to complete.
Repeat from a for next operation. This is the current system

Mode 2 (Tool based)
a. Press modifier TRS
b. Click on item and drag mouse to modify. Repeat for next operation.
b.i While mouse is down, press and hold 'z' or 'space'. While key is down, moving the mouse will zoom/pan, but not move the mouse pointer from its item.
b.ii Release key and continue operation b.
c. Press modifier TRS to turn it off

Mode 1 is operation based in that every operation is a new start (you have to press TRS before each one).
Mode 2 is tool based in that you select the tool and it stays in use till you select a different one.
In mode 1, you're paying the cost for pan/zoom with an extra mouseclick on every operation even if you don't use those features.
In mode 2, you only pay for these features when you use them with a keypress.

Mode 2 is the way nearly everything else I can think of works. Select a tool item, then click and drag to modify things until you select a different tool.
If you think of Photoshop for example. If you want to paint something, you select the brush tool and then click and drag on the screen. You don't have to press 'b' before every brush stroke.
Likewise, it also uses a keypress to apply mid op modifiers. E.g. Hold spacebar to pan.

Anyway, hope that provides a different way of thinking about it.

[iforce2d]

Mode 2 does not seem to be applicable to rotation or scaling... isn't this more a concern for translations? I mean, requiring the click to select the item and also begin the rotate/scale means that the mouse will be right on the item at the start of the action, making any degree of control of the rotate/scale pretty bad.

I don't think the action of painting with a brush is a relevant comparison. With a brush stroke, the location of the mouse at the beginning of the action is obviously very important, as is every movement of the mouse relative to the canvas for the duration of the action. But for translation of an item neither the start or finish location of the mouse is important, only the relative offset between them is. Most likely that is why they decided to implement the space-bar-to-pan-canvas feature, because they knew people would need to be holding down the LMB, and using keyboard to allow panning is easier than requiring them to use RMB at the same time.

As I said though, there is definitely a case to be made for many successive translations, and the idea of entering a mode to do it is a good one. Now that I think about it a bit more (again...), rather than having this on the 'E' key which restricts it to vertices, how about having it on the 'T' key as you suggest, so that it can apply to all item types. The difference to your suggestion is that it would not extend to 'R' and 'S' as well. Come to think of it, currently the 'R' and 'S' keys work a bit differently to 'T' because hitting R/S repeatedly toggles between rotating/scaling around the cursor or the selection center, whereas repeatedly hitting 'T' does nothing. What if repeatedly hitting 'T' toggled between the current behavior, and the new 'one click per translate' behavior.