Alignment of patches in DarkRadiant

[SneaksieDave]

Taken from discussion started here (internal link).

 

The issue of alignment of patches upon creation needs some TLC. Currently it's inconsistent and confusing -- some patches are created aligned up-down, others aligned with the current ortho view. Some decisions need to be made for less clear-cut cases. Please provide any thought out opinions on the matter below, then hopefully we can get a single consistent tracker entry out of it.

 

----

 

The request is that all patches be created axis-aligned from current ortho view. Currently, they're inconsistent in alignment, top down or sideways. What this would mean is, regardless of current alignment, whatever ortho viewport currently has focus (?) determines which way the patch is created:

 

1. Simple mesh: If looking "down"/vertically (in a global sense), the patch is created as if laying on the ground, as if it were a floor or carpet.

 

If looking "sideways"/horizontally (in a global sense hereafter) the patch would be up on a side, facing the ortho came, as if it were a wall.

 

Note: This patch already works as described.

 

----

 

2. Bevel: If looking down, create the bevel on its "side." That is, looking in XY view, the mapper would see the curve bending 90 degrees.

 

If looking horizontally, create the bevel "standing up" (as an arch). Thus, the mapper similarly sees the curve. Curved side up please (standing), as an arch, not down (sitting) as a bowl. Arches are much more common.

 

In both views, the "curve is seen" by the mapper, not the "spine" of the patch.

 

A benefit of this is that it immediately shows the mapper, "hey a curve to work with!", as opposed to "uh what is that rectangle with a line through it?" And the mapper can start shaping immediately. If they made it rotated to what they want, they can easily turn it without transforming through other axis or simply delete, rethink, and recreate it.

 

Note: Currently, this does the opposite of this request; it instead shows the "spine" of a bevel in the active ortho. Yes, this conflicts with the previous tracker request for bevel creation, but that was operating under the assumption that bevels were the only patches that would see change in this matter, so "better than nothing." It was shortsighted, I admit. A single consistent system for all patches would be more beneficial and not confusing.

 

----

 

3. Cone/Cylinder:

 

We need a decision here. Are all cones and cylinders created "standing?" That is, longways up-down?

 

Or should they be rotated with the view? To do so is more consistent with the request, and of course more functional. But, should they be axis-aligned with the ortho view (that is, looking down the length of the cone or cylinder), or anti-axis-aligned, which "shows the curve" as above for bevels?

 

Whoever makes the most logical argument for one choice or the other gets a gold star.

 

----

 

4. End caps:

 

Currently creates them "laying on the side" regardless of ortho alignment. Suggestion is that they be oriented axis aligned with ortho view as with the request for bevels above. That is, the mapper always "sees the curve" from their current ortho view, upon creation.

 

-------------------

 

Thoughts and opinions requested.

[nbohr1more]

I like this idea.

 

I cannot speculate how hard it would be to implement but I would be grateful for anything that makes the process easier.

[Komag]

I think Cylinders should be made the same as Bevels for consistency. This means that you see it very well when making it, as opposed to seeing NOTHING as when the view is centered on the interior of the cylinder. So if you want a standing pillar (most common usage I think), you'll need to be in one of the horizontal views, as you would when making a standing arch Bevel.

 

The logic would be to First use the top view to place the footprint of the pillar, Second use a side view to decide how tall the pillar will be, then make the cylinder, which is clearly and obviously seen from the side. If one wants a sewer tunnel on its side, create the long rectangle horizontal brush and then from the top view make the cylinder.

 

By the way, I think "remove selected brush" should be a more universal setting rather than just an option for the "create simple patch mesh". When I'm making a cylinder I almost always want to remove the selected brush, but always have to do it manually.

[SneaksieDave]

But the request for bevels was they be axis-aligned ("looking through the hole"). So that suggestion would actually be opposite of bevels.

[SneaksieDave]

For the record, here's an image of the method I'm suggesting; what I'm calling (possibly incorrectly) "axis-aligned." In all views (horizontal or vertical) the patch is created with this axis centered, so that the created patch always looks the same upon creation regardless of view. This gives the most functionality, because the mapper can build from top or side depending on which they need (as opposed to a constant global alignment, e.g., always making cones or cylinders "stand upright").

 

(Note these pics are all taken top-down, but they'd look the same from side-on.)

(Edit: also, the bevel need not point left; it can point right just the same.)

 

 

For this method, cones and cylinders need side-on support (top down already works), bevels need their current method reversed (and some tweaking to make arches stand upright from the side instead of making a "bowl"), endcaps need the same method bevels will then employ, and simple meshes need no change as they already work this way.

[Fidcal]

My view:

 

All patches as far as possible created 'facing you' or 'pointing at you' with the visible side of a single-sided texture facing you.

 

All patches show shape as far as possible but consistent with above.

 

Simple patch: as now, created facing you in the ortho view.

 

Cylinder: created 'pointing at you' so you always see a circle.

 

End cap: ditto cylinder so you see a half circle.

 

Cone: ditto cylinder. Agreed this does not show the classic cone shape but is consistent with the cylinder which is its nearest relative (kind of pinched cylinder.) It does show a unique 'dartboard' circular shape so you know what you've got.

 

Bevel: ditto cylinder so you see the shape of the angle and it is consistent with a kind of warped 'part of a cylinder' kind of thing.

[SneaksieDave]

Yep, if the mapper thinks "ah crap this bevel is on its side" then they simply need to delete it and create it from the side. Simpler than grabbing at straws with random rotations. Plus since it'll be consistent, it'll be easier to get used to what to expect / how to use it properly.

[Bikerdude]

this has always annoyed the bejesus out of me, well done for taking the time to point this out!

 

Greebo, your thoughts..

[Tels]

Here is a random idea: Couldn't DR draw at least a dashed-outline or something from the "wrong side" of a patch? That way it wouldn't be invisible and thus not as easy to miss.

[SneaksieDave]

Separate issue, a very old one, and tracked already.

[Komag]

but if a cylinder is pointed at you you see nothing, it's invisible. It would be more consistent with having everything axis-aligned, but less consistent with having everything clearly visible. I could live with either way

[SneaksieDave]

Here would be an axis-aligned cylinder (just like a cone):

 

[Komag]

Oh, I meant in the 3D view, but as I said I can live with either way

[grayman]

Would it be possible to have "Create Cylinder" create a true circle?

 

ATM, we get a square with rounded corners.

 

In the attached picture, the blue circle is "true", and the red line is what "Create Cylinder" gives us.

[Komag]

That's a whole 'nother ball of wax. At the moment, if I want a cylinder to really look round, I lower the grid some and slightly bring in the green corners, which overall helps, although it makes the compass points a bit more acute, but it's usually a worthwhile trade-off

[Fidcal]

Sneaksie: You have a black background like me. I thought I was the only one. How do you manage with some of the colours like a low light such as ambient is virtually black on black.

[Fidcal]

Two other issues relating patch alignment regarding texture alignment on default patches.

 

When you rescale texture on a patch the controls are reversed. You need to use the decrease button to make the scale bigger and vice versa.

 

 

When you first create a default simple patch decal on a wall then when you texture scale or scroll then the direction may not be oriented correctly. So, you may need to use the horizontal scroll to scroll vertically and it may be the opposite direction to what you'd expect.

 

[EDIT] Add to that last, it is not consistent. I am in the middle of adding decals and I did one north facing wall and had to scroll and scale the vertical using the horizontal controls. A few minutes later I do another north facing wall but this I need to scroll the vertical controls. These decals were all made simulataneously and are defaults - they have not been rotated or moved at all, only drag-resized.

 

[EDIT2] I need to add that I am doing grime corners which are symmetrical in four directions so no way to know which way the texture is oriented. Needs some testing with other textures but it seems the textures may be randomly rotated by default?

[rich_is_bored]

You can get pretty close to a perfect circle if you add a few columns to the default cylinder and move the points around to distribute them evenly.

 

Here's prefab just to illustrate...

 

circle_zip.txt

[grayman]

Here's prefab just to illustrate...

 

Excellent!

 

Thanks.

 

 

 

[SneaksieDave]

Sneaksie: You have a black background like me. I thought I was the only one. How do you manage with some of the colours like a low light such as ambient is virtually black on black.

Whenever I see someone with a stark pure white or pure black ortho view I run away screaming. Don't know how anyone can stare at that for extended periods.

 

Dim lights can be a bit of an issue, yes. Haven't quite thought of a solution for that yet, but one thing I suggested was that while light entities should reflect color and brightness (and let's face it, some entity color is always going to conflict with some ortho color, so there's only so much to do), that perhaps it should have established maximums and minimums for brightness. Light color and brightness don't give the mapper at a glance exact info anyway, just a relative idea/approximation, so why not have the max/mins at least allow them to be easier seen?

 

On topic:

Does it sound like people generally agree that "axis-aligned" is a way to go?

[ungoliant]

I am for axis aligned.

 

any word on this...?

Edited July 11, 2010 by ungoliant

[SneaksieDave]

Thanks for bumping. I've tracked an issue: http://bugs.angua.at/view.php?id=2306

[greebo]

This is resolved now in SVN. Patches (Simple Mesh, Cylinders, Cone and Sphere) are always created to face the current view type (XY, XZ, YZ).

[SneaksieDave]

Thanks, that'll be a very welcome thing!

[Fidcal]

Are bevels included in that?