Doom Builder 2 - auto align

[Mordeth]

When in vertex mode and inserting a vertex into a linedef, DB2 apparently decides to also auto-align all the adjacent same-texture linedefs. How do I stop this from happening?

[esselfortium]

Yell at CodeImp until he realizes how annoying and time-wasting it is.

Note that it doesn't autoalign all adjacent same-textured sidedefs like you think. It just aligns the two that result from the split in such a way that, before you move the vertex around, it'll look the same as it did before you split the line.

The problem with that is, of course, is that you're usually going to be moving the vertex right after you split it, so it just makes a mess of things. I can see it being useful for when a line is automatically split by an overlapping drawing, but 99 times out of 100 when I'm adding a vertex directly, I'm going to be moving it immediately afterwards, anyway, so the resulting auto-alignment is totally wrong every damn time.

[printz]

Am I the only one who finds it a time saver? I often place the new vertex in the exact location (most often when I split the sector), and it always helps me in Eternity when I add portal-handling linedefs.

[Mechadon]

I think the best way to approach the problem is to allow both behaviors. And then just let the mapper toggle which behavior they would prefer to use when they are splitting lines.

[printz]

The thing is that even if I split a wall to reshape it, regardless of outcome, I would still go into 3d mode and x-autoalign (most of the time, when the texture is not made of panels). Or if I get lots of unwanted offset textures after splitting a wall and moving it around, I just select all linedefs and set their offsets to 0 in the dialog box.

[CodeImp]

DB2 does not auto-align anything when splitting a line with a vertex. It simply inserts a vertex and that new vertex is given interpolated texture coordinates which keep your wall look the same (so that your alignments don't get messed up). The problem you are having is most likely introduced when you move a vertex around (which is often part of a user's workflow after splitting).

Mechadon said:

I think the best way to approach the problem is to allow both behaviors. And then just let the mapper toggle which behavior they would prefer to use when they are splitting lines.

What do you mean with both behaviors? Only one is being discussed here and no other has been suggested as of yet.

Here are 2 arguments why you have this behavior and why I don't have a better behavior:

Like printz mentioned, DB needs the described behavior so that your map does not get messed up by you drawing lines across/along existing parts of the map. This is about splitting a lines with a vertex, it is NOT about resizing any line and no vertex is moved (only inserted).

The workflow Mordeth describes is probably also about moving a vertex, which inherently changes the length of one or more lines (usually 2 or more). This is where the problem lies. There is no computer in the world who can do anything with the alignment numbers on those lines in such a way that they still make sense (in all possible scenarios) without also aligning all the adjacent lines with the same texture. When you resize lines, you simply have to do your alignments again anyway, so the splitting behavior that DB has is not causing any more "harm" than you already decided to cause by yourself. If DB would change none of the alignment numbers, or if they would be reset to 0 when you move a vertex, you would still have to re-align your textures so that they make sense. Also, resetting the values to 0 when moving a vertex is not always desired and can ruin your map when you move a selection of multiple vertices around (you would lose all your alignments within that selection).

What behavior would you have in mind?

[Mechadon]

CodeImp said:

What do you mean with both behaviors? Only one is being discussed here and no other has been suggested as of yet.

What I meant was the opposite of the behavior of splitting lines as it is now. That is to not auto-align textures when a vertex is placed on a line. Wasn't this how DB1 worked? I'm a little fuzzy on the details.

As far as moving vertices goes, I honestly don't mind how it works right now. I just go into 3D mode and align stuff again usually. Mordeth just brought up placing vertices on lines, not moving them, so I figured that's what the issue was.

[esselfortium]

It's more of a frustration when working on classic-style maps (like Doom II The Way id Did), where I need to go around the map in visual mode manually resetting nearly every line's alignment to 0,0 because DB2 has changed them of its own accord during the construction process. I also sometimes end up doing the same thing when working on a temp-textured layout that I plan to texture and detail later on as a separate process. The unwanted alignment changes are more of a distraction for me than anything else.

It would be much appreciated if I could tell DB2 whether I want it to interpolate alignment when it's auto-splitting from line overlaps (I do) and whether I want it to interpolate alignment when I'm adding a new vertex manually (I don't). I've heard a lot of complaints about this functionality, and so I know there are a good number of people who agree that it's a nuisance.

[printz]

esselfortium said:

It would be much appreciated if I could tell DB2 whether I want it to interpolate alignment when it's auto-splitting from line overlaps (I do) and whether I want it to interpolate alignment when I'm adding a new vertex manually (I don't).

Yeah, placing new sectors and overlapping lines is precisely the case where I appreciate the interpolation, especially when I work with slanted lines whose offsets are not multiples of 8. And I rarely add just a vertex manually for this purpose.

Unfortunately, when I attempt to place a vertex manually (right-click), it often resorts to line-draw mode.

[Mordeth]

Mechadon said:
I think the best way to approach the problem is to allow both behaviors. And then just let the mapper toggle which behavior they would prefer to use when they are splitting lines.

I would like this. The autoaligning is -very- disruptive to my workflow and it made me rage a bit on the inside when I didn't find a toggle button for that behaviour.

Doom Builder 2 is awesome btw, except for the single issue above. I've switched from DB1 a few days ago, now that my own PC is in storage during our complicated house moving. Best editor I've ever had the pleasure of using, thanks!

[CodeImp]

Ok so which is the "other" behavior? Use "0" values for texture coordinates of the newly inserted vertex? And how often would you want to switch between behaviors? And why? Would a setting in the preferences dialog suffice?

[Gez]

CodeImp said:

Ok so which is the "other" behavior? Use "0" values for texture coordinates of the newly inserted vertex?

Personally, I'd be fine with that.

CodeImp said:

And how often would you want to switch between behaviors?

Still personally, pretty much never. If I can get a behavior where manually inserted vertices result in zeroed offsets while automatically-inserted vertices (when drawing lines over other lines) use the current method, I'll be happy. :)

[printz]

If I attempt to manually insert a vertex, and I accidentally go into line-draw mode, which still creates that vertex, but I have to right-click again, does that new vertex count as manual or automatic?

Note that unfortunately the "manually place vertex WITHOUT adjusting alignment ANY MORE" won't be quite beneficial either -- quite often I split the linedef to keep the vertex placement, but assign a special to only one of the resulting linedefs. I would have to redo the alignment, manually or auto, if it got reset like in Doom Builder 1. This applies for example when I reserve short linedefs (of specified length) to make Linked Portal handlers and anchors.

So I'd appreciate if it's completely user-settable in the Options: all the way from Doom Builder 1 behaviour to Doom Builder 2-so-far behaviour, so everyone can benefit.

[CodeImp]

Gez said:

If I can get a behavior where manually inserted vertices result in zeroed offsets while automatically-inserted vertices (when drawing lines over other lines) use the current method, I'll be happy. :)

Yes, I'll have to make that distinction in the code, but that is doable.

printz said:

If I attempt to manually insert a vertex, and I accidentally go into line-draw mode, which still creates that vertex, but I have to right-click again, does that new vertex count as manual or automatic?

No, that is a drawing operation so it will count as automatic. If you are having problems pointing your mouse near a line, just go to Preferences -> Editing tab and increase the "Split linedefs within range". You can also initiate a drawing operation with CTRL+D so you don't have to rely on right-click for that.

[Dragonsbrethren]

Personally I'd be happy with offsets getting zeroed regardless of whether the vertex was added automatically or manually. My mapping aesthetic is (very intentionally) vanilla, and I only worry about texture alignment if something looks particularly bad.

As for how often I'd change the option after it was set, likely never.

[gggmork]

I have like, an 'idea' (I knew it was an idea because I smelled something burning and I wasn't cooking any pancakes). Maybe in practice it might suck and might be hard to implement etc, and I don't personally ever bother with texture alignments enough to care much about them myself.

So like maybe when you start drawing a sector, it remembers which point was drawn first. The first line is given zero x offset, then each next line's X OFFSET is set to the SUM of all the previous line's LENGTHS up to the first point drawn (kind of obvious I guess).
This is like the picture on the left.
Then when you MOVE a point it just recalculates all offsets from the 'starting point' again, making all the lines offsets = the sum of the previous lines lengths, thus keeping the textures smoothly wrapped even when you move points.

45+71+101+115 = 332 total perimeter
typical 128 long texture doesn't tesselate perfectly with 332 which is why you need to pick an arbitrary point to start texturing from (the first one drawn), then doing the calculation mentioned above would result in the texture smoothly wrapping around all oddly lengthed lines (until it reaches the start point again which won't be smooth in that case because 332 % 128 != 0.

[CodeImp]

I like your thinking, but that really isn't going to work for anything more complex than a single sequence of vertices and lines in a 'circle' like your drawing. As soon as vertices start getting shared by more than 2 linedefs, you're in trouble. And maps usually have that quite a lot! Also, it would be way too late for DB to implement such a thing as it requires the editor to be completely aware of the order in which everything was drawn. DB2 isn't made to do that and it really isn't that easy to change such a fundamental thing in a program at this mature development stage (maintenance).

[40oz]

Yeah I think I brought this up to some fellow mappers before. I think in 1994 this feature probably would have been wonderful. I'm finding many PWADs from 1994 that have sectors with many vertices close together to look rather ugly when all the textures are 0,0

However, I think that because doom builder supports a fast and easy to use Visual Mode, It's really not all that necessary. I honestly find my big pet peeve in mapping with DB2 is that almost everytime I create a set a rooms, I usually run around in visual mode pressing 'R' on everything so that I can do the texture alignments myself. I think this has a lot to do with me not really understanding what DB2 is doing and knowing how to use it to my advantage, but I still think I'd be better off without it at all. And an option to toggle between the two would be good for all mappers.

[boris]

CodeImp said:

Use "0" values for texture coordinates of the newly inserted vertex?

I think it'd be better to simply retain the offset of the un-split line. I imagine it'd be pretty annoying if you have a y-offset on a line and that, too, gets reset after splitting the line.

[gggmork]

WARNING: more crappy thoughts that are best to ignore and probably wrong somehow because I suck at thinking of complex stuff, even when I have an obvious simulation like 3d mode right in front of me. Whatever, just thinking aloud even though you mentioned it'd be too late to implement at this stage probably:

I assume when making a new sector from scratch, each new line made at least has access to data of previous line. If so, each new line's xoffset could = previous line's length + previous line's xoffset (same basic calculation result in previous picture, but it only needs the previous line's info, not a chain of previous line's infos). That probably assumes you're making a sector clockwise.

I made a 'pizza' shape, with a bunch of slices coming to a point, each with oddball lengths, and each next slice ++32 to ceiling and floor, so there's complex textures to align everywhere.

So now the sidedefs of the pizza 'slices' are independently aligned (as much as can be because maybe the perimeter doesn't tesselate with texture length), but the pizza 'crust' isn't aligned. Maybe a way to do that could be some sort of mode where ALL the sidedefs of a slice are moved simultaneously when you move one of them. Like each slice is made of crust + 2 lines to center, so if I move a slice's crust to the right 15 units, the rest of that slice's sidedefs also move to the right 15 units. In other words you have a bunch of slices/subsectors with internally aligned sidedefs, but not aligned relative to other subsectors. But it would be easy to manually align subsectors to eachother in 3d mode or something because all sidedefs of a slice/sector would move simultaneously, without having to tediously do each sidedef.

For the pizza shape I think it probably looks best if the 'start' of the alignments is at the center of the pizza, so maybe some sort of rule could be to start alignments on points that have the most attached lines or something.

[Mordeth]

CodeImp said:
Ok so which is the "other" behavior? Use "0" values for texture coordinates of the newly inserted vertex? And how often would you want to switch between behaviors? And why? Would a setting in the preferences dialog suffice?

Either a setting in the preference dialog, or a toggable thing like 'snap to grid' is. Something that at least gives full control back to the user/designer.

[gggmork]

Here's 2 plugin ideas if anyone's interested since I suck at programming:

1-'round selected points x/y locations to nearest grid coordinate'
For example, sometimes you rotate stuff 45 degrees. When you rotate it back to original position, many points are slightly off the exact grid positions where they originally were (probably each point accumulated rotation decimal rounding x/y imprecision or something), so this 'function' or whatever would snap each point to its closest grid coordinate (at current grid size setting I guess).

EDIT: nevermind, I remembered db1 has point 'snapping', so i can save, do it there then take it back to db2.

2-Like if you highlight 10 different sectors and type ++48, then ALL have 48 added to their current values. Simple idea to allow typing *= or ** or whatever, which would multiply each ceiling or floor by their current value instead of add (used to easily resize (vertically) a whole selection of varying sectors).

[Dragonsbrethren]

boris said:

I think it'd be better to simply retain the offset of the un-split line. I imagine it'd be pretty annoying if you have a y-offset on a line and that, too, gets reset after splitting the line.

On second thought, I prefer this idea over what I said.

[CodeImp]

Ok, here is my decision.

For automatically splitted linedefs (due to drawing lines or using the curve lines tool), the behavior stays the same (the texture coordinates are interpolated so that your texture alignment essentially stays unmodified).

For manually splitted linedefs, I am making an option for this in the preferences. You can choose from:
- Interpolate texture coordinates (default, as this is the original behavior)
- Duplicate texture coordinates
- Reset X coordinate and duplicate Y coordinate

Hows that?

If you don't want to wait for the next official release, keep an eye out for someone to build an unofficial one, these guys usually post here, or use Tiger's script to build it yourself (also on that forum) but you need Visual Studio and some other tools for that.

[Dragonsbrethren]

Sounds good to me.

[printz]

CodeImp said:

For manually splitted linedefs, I am making an option for this in the preferences. You can choose from:
- Interpolate texture coordinates (default, as this is the original behavior)
- Duplicate texture coordinates
- Reset X coordinate and duplicate Y coordinate

Thank you.

[Mechadon]

Sounds good to me as well. Thanks CodeImp :)

[Dragonsbrethren]

Anyone make a build of this yet?

[Snakes]

Oh, cool. A nice update to DB2 that somehow passed right under my radar.

[Mordeth]

Haven't seen a new build yet, but it does sounds like what we wanted. Thanks Codeimp!