PDA

View Full Version : Cylinder cap points: not a Loop?



jeric_synergy
08-09-2015, 03:35 PM
Just made some bog-standard cylinders (disks), and found that SELECT LOOP does not work for the end cap points, but does for interior segments.

Is that a standard definition?? It's a bit annoying.

spherical
08-09-2015, 03:49 PM
No. If Select Loop doesn't, there's usually something in the Loop that is not like the others. Check for 1-point and 2-point polys, points not on the expected number of polys, edges on one poly or more than two polys, flipped poly in the circuit; the standard cruft. Sometimes Merge Points doesn't find ones that should be. Either widening Fixed distance or manually selecting and Welding if more than one is in the selection cures it. I get that this is a simple hockey puck made from a disk, but sometimes oddities are introduced where least expected. If in doubt, start over.

jeric_synergy
08-09-2015, 04:54 PM
This is just a bog-standard raw 'disc' untouched by any operation. That's what makes it so odd. Try it yourself.

JoePoe
08-09-2015, 08:07 PM
Yeah... standard.
You want even more frustration....... delete the top/bottom poly. NOW you can select loop.

jeric_synergy
08-09-2015, 08:11 PM
Oy.

:2guns:

Snosrap
08-09-2015, 10:35 PM
Yep- its' another one of those Modeler gotchas!

spherical
08-10-2015, 12:18 AM
Well that's just stupid! Talk about lacking basic functionality.....

Give the cylinder 2 segments and the center Loop does select.

I need a drink.

Shiny_Mike
08-10-2015, 01:22 AM
Pretty sure loops need adjacent quads, an ngon or even triangulated 'cap' messes up detection

spherical
08-10-2015, 03:29 AM
Yeah, I tried a triangulated end poly and it didn't do any different. Triangulating with Traverse found loops on the sides, however.

JoePoe
08-10-2015, 10:24 AM
I guess it depends on what kind of Triangulating :hey:.
Running Make Pole on caps results in tris.... and then select loop works fine.

It's because the resulting intersections are then back to "four-way streets".

That's why I pointed out the delete cap behavior. Remove the caps and you still have a three-way intersection.... but select loop works in that case :screwy:.

Can't seem to find it atm, but another package recently added a "smart edge extend" feature, that seemed to do a really good job at "guessing" on edge loops extending through different numbered star intersections. Will try to find it again....

jeric_synergy
08-10-2015, 12:25 PM
Maybe would should clamor for more END CAP OPTIONS in the, ::sigh:: "Disc" tool. (Gahd I h8 that name.) ;)


NO END CAPS -- seems a no-brainer.
POLED END CAPS -- would be one option.
QUAD-RIFIED -- would be another-- cylinders with Even number of sides (>=4) could be capped with quad patches --I don't think that's possible with odd numbers.
HEMI-CAPS -- we kinda got that with "Capsule", but why not fold Capsule into (ugh) Disc? Reduce the redundant tool count.


+++++++++++++++++
EDIT: while I'm talking about 'disc', I've never found the TOP/BOTTOM parameters to be really CONVENIENT. What I'd like is a LENGTH parameter-- that's the measurement that I'll actually use. Obviously, LENGTH would interact with the others, and you could lock the top OR the bottom coordinate.

spherical
08-10-2015, 03:45 PM
I guess it depends on what kind of Triangulating :hey:.
Running Make Pole on caps results in tris.... and then select loop works fine.

So the actual underlying condition is that there's a possible bug (or it never will work no matter what) with ngons and/or attached polys that are not in a sequence themselves. IOW, Traverse and Fan create Tris but they are not in the same sequence as the points that they are attached to, so Select Loop doesn't see the Loop. IOW2, there is a difference between the number of polys on each side of the Loop, so it isn't recognized as a Loop.

jwiede
08-14-2015, 01:22 PM
IOW2, there is a difference between the number of polys on each side of the Loop, so it isn't recognized as a Loop.

Hopefully more complex than that, as that situation is common at bridging and joined topo boundaries. Can it detect loops at where bridge sections meet "main body"?

JoePoe: Sure you're not thinking of the modo 901 loop extension videos, etc.?

spherical
08-14-2015, 04:07 PM
Just tried something similar. Booleaned a cylinder out of a cube. Doesn't recognize the Loop on the cylinder points until you delete the cube poly.

Then tried Bridging the 24-side cylinder to the cube:
Selected five points on the cylinder that centered on one of the cube edges. Only half the Loop was recognized; stopping at the points at the center of the two adjacent cube sides. The center point of the half-loop is on what is essentially an "extra" poly in the sequence. What makes this poly unique is that it does not have an edge between the cylinder and the tri; it's a point.

Then selected three points centered on a corner of the cube. Only that quarter of the Loop was recognized; stopping at the center of both left and right cube sides where those unique points are.

The reason that the half-loop was recognized (passing the unique point boundary on that side) was that the center point was part of the initial selection used when Select Loop was activated.

So, my conclusion is that it is the number of polys on each side of the Loop not being equal that causes it to not see a full Loop. If there is no poly there to calculate and throw things off, it doesn't see a problem and selects the Loop.

jwiede
08-15-2015, 03:08 PM
Just tried something similar. Booleaned a cylinder out of a cube. Doesn't recognize the Loop on the cylinder points until you delete the cube poly.

Then tried Bridging the 24-side cylinder to the cube:
Selected five points on the cylinder that centered on one of the cube edges. Only half the Loop was recognized; stopping at the points at the center of the two adjacent cube sides. The center point of the half-loop is on what is essentially an "extra" poly in the sequence. What makes this poly unique is that it does not have an edge between the cylinder and the tri; it's a point.

Then selected three points centered on a corner of the cube. Only that quarter of the Loop was recognized; stopping at the center of both left and right cube sides where those unique points are.

The reason that the half-loop was recognized (passing the unique point boundary on that side) was that the center point was part of the initial selection used when Select Loop was activated.

So, my conclusion is that it is the number of polys on each side of the Loop not being equal that causes it to not see a full Loop. If there is no poly there to calculate and throw things off, it doesn't see a problem and selects the Loop.

Ugh, yeah, that does sound reasonable given experiments. Unfortunately, experiments also seem to confirm bridging / joined topologies cause issues.

JoePoe
08-15-2015, 03:47 PM
It's just a weird little tool with loads of inconsistencies and special gotcha scenarios.
Case in point.... on a cylinder with a "complex" intersection: the first selection goes through (which I think is actually a mistake/bug). Take away part of the cylinder that has nothing to do with the intersection and it stops. 129277. (sorry should have stayed specific to the thread... it's the same on the cylinder "edge").


It only really likes four way intersections or open edges. With anything else it just goes "huh?" and stops. Which is a good thing really. Otherwise we would be complaining about how long it takes to DEselect the unwanted edges in loops it guessed we wanted.
It is frustrating though that it can't even deal with a simple T intersection that goes straight through... 129278
It's erring on the side of too much caution, imho.

Ultimately it just needs to go to Oz and ask for a brain.

At Wings 3D at least it has permission to go through all even numbered intersections (an even #, of course, means there's an edge directly opposite the incoming edge....making a straight line through the intersection).

And yes I was thinking about Modo Edge Selection before. In 901, it can (I believe), when confronted with an odd number, calculate the angle closest to straight and pick that direction to continue.
Watch seconds 2:58-3:09 (https://vimeo.com/124320824).

Edit: Sorry Spherical, I had hard time following your description (my brain not yours). But I don't think it's a matter of equal #s of polys above vs. below the edge in question.... If I understood right.

129279