Redirect flow?

[nemyax]

Is there a quick way to redirect the flow of two splines at an intersection? For example, to go from the left state to the right (and vice versa) in the screenshot below:

 

I haven't been able to find a solution that doesn't involve detaching and breaking stuff.

[Fuchur]

Not that I would know of... and there would be more than one additional option to connect those splines... it would be at least two...

 

See you

*Fuchur*

[Rodney]

I can see why one might want to go from the right example to the left but not from the left to the right.

 

But to answer your question I can think of a couple different approaches although they all rely on removing/altering splines.

 

The first method would be to select the splines that are inappropriately connected and hit the comma key to select the entire spline.

Hitting delete after that will then allow you to lay in a new more appropriate spline.

 

An alternative to this would be to 'divide and conquer' by selecting the spline nearest the point of contention and then hit the Y key to insert a Control Point half way down that spline.

After inserting the new CP then hit the K key to 'kill' the undesireable part of the spline. Do this for each of the four directions that will need to be repaired/reassigned and then stitch them back together appropriately.

 

There are surely other ways... such as resampling the spline* but I can't think of a method that changes the continuity of a spline without changing the continuity of the spline.

 

*When using ResampleSpline wizard the idea would be to resample the spline but use the same (or similar) number of CPs in the spline. Effectively what you'd be doing is recreating the model with proper spline continuity. Which leads me to yet another approach which would be the 'copy/paste' method. In that you would select all but the specific Control Points you wish to change and then Copy/Paste either into the same Model or into a new Model. Then close off the hole in the resulting mesh with the proper spline continuity.

[Rodney]

Here's a quick video example of that last methodology:

 

 

Replacing Splines.mp4

[nemyax]

I can see why one might want to go from the right example to the left but not from the left to the right.

A human wouldn't want that, but to a program, both configurations are fine.

 

So it turns out I couldn't find a quick way because there was none. That's strange: I found myself in need of a spline rerouter five minutes into the program. Can't believe no one's asked for one before.

[Rodney]

Can't believe no one's asked for one before.

 

 

If you are programming one I'm sure it'll be most appreciated.

 

The reason folks wouldn't ask for one is that (as you state) to a human the problem on the right would be obvious.

A computer however would have to know which of many possible combinations it needs to use in order to guess right.

It'd be somewhat like looking up at the stars at night and attributing zodiac imagery to the stars by connecting the dots.

The odds of those connections being 'correct' being... astronomical.

 

A programmatic (and graphical) approach might be to display one or more of the available options for connectivity and the user would then choose their preferred continuity.

I would guess that several other methods for determining flow would work as well.

For instance, if a spline was known to move consistently in a plane with minimal deviation in orientation it should not suddenly guess that the next spline segment suddenly shoot off in a new perpendicular orientation from that original orientation. If all splines ran equally north/south and east/west that would be largely sufficient to maintain a similar continuity.

Unfortunately (or fortunately) splines don't always conform to the same orientation.

 

but to a program, both configurations are fine.

 

To a program that hasn't been programmed with the capacity to identify the error or determine wrong continuity from right.

[nemyax]

Rodney

The problem looks a lot simpler than you make it appear. See this shoddy diagram:

A spline is directed (note the green pointies). It has an inbound part before the intersection (marked red) and an outbound part after it (marked blue).

Suppose you have two commands:

1. Create continuity between inbound half-spline A and outbound half-spline B; create continuity between inbound half-spline B and outbound half-spline A; fuse. That's the state in the middle.
2. Create continuity between inbound half-spline A and inbound half-spline B; create continuity between outbound half-spline B and outbound half-spline A; fuse. That's the state on the right.

You can name the commands something like "Reroute Left" and "Reroute Right". You try one of them on a problem spot, and if the result doesn't make you happy, you just undo and use the other one.

And that kind of solution is no programming feat at all.

[Rodney]

And that kind of solution is no programming feat at all.

 

 

I'm not a programmer so can only explore what success might look like.

 

After posting I was trying to imagine what that success might indeed look like and the thought of 'smart splines' or a mode that allows for the coloration of splines came to mind.

The idea being to use the color red to suggest splines that the computer isn't sure if it has optimal continuity. This would give the user a visual clue as to where to look to improve spline continuity.

There are several problems with your take on simplicity but I'm not smart enough to identify or address them all.

The question does present itself in that out of the available options none present an optimal spline continuity (both the image in the middle and on the right are non-optimal for the purpose of Control Point connectivity... it may or may not be the case that they are of a proper spline continuity but the patches/CPs represented are both suboptimal. At a guess I'd say that rather than reroute continuity it would be better to terminate each of those splines. Programatically the UI could then have a method that graphically display the location of the beginning and ending of every spline. (Similar to your suggestion of red/blue for inbound/outbound)

 

But this is what complicates the simplicity you suggest in that your case is not restricted to only those possible splines.

For instance, each of those spline segments could be individual splines with no continuity.

And for your purpose, that might be the better approach to take (i.e. treat each spline segment as if it has no adjacent continuity).

You could then 'paint in' or trace (retolologize?) the desired continuity.

 

I'm probably just not seeing any benefit of creating those bad patches.

I can see a lot of negative though... poor alignment/placement of decal imagery, display artifacts, etc.

[nemyax]

I'm probably just not seeing any benefit of creating those bad patches.

 

A:M's OBJ import creates a lot of atrocious continuity. It just has no notion of "least tension" flow. If there were a dumb rerouter like the one described above, cleaning up would be so much easier.

 

 

But this is what complicates the simplicity you suggest in that your case is not restricted to only those possible splines.

For instance, each of those spline segments could be individual splines with no continuity.

I'm specifically looking into the unambiguous case of a continuous intersection. Anything more complex probably ought to be handled manually anyway.

[robcat2075]

 

 

So it turns out I couldn't find a quick way because there was none. That's strange: I found myself in need of a spline rerouter five minutes into the program. Can't believe no one's asked for one before.

 

I can tell you why it's not a common request... if you want to know.

[robcat2075]

Here are my two entries in the manual rerouting derby...

 

clip3560ReroutingBadSplineIntersection.mov

[John Bigboote]

SO - you are looking for a feature that takes a selected intersection of 2 splines and reverses the union with a keyboard shortcut? With the potential usage being to repair imported obj files...?

[nemyax]

John Bigboote

Something like that.

[robcat2075]

There must be some judgement at work in the current OBJ importer because it does make the correct connection at each junction most of the time. I wonder what's different about the times it makes the wrong connection.

[Fuchur]

I think this should not be very hard to implement, simply because A:M knows which spline has which CPs and should be able to see the splines the CP belongs to... It is very hard to see which it should belong to (guess which one is the right one) but since you ask for just a switcher, that should be possible. (I'll ask Steffen about it...)

 

BUT since you change patches there, you will very likely loose UV-data at that part... (since after switching the flow / continuity there, it will create other patches not available before...)

 

See you

*Fuchur*

[robcat2075]

 

 

BUT since you change patches there, you will very likely loose UV-data at that part... (since after switching the flow / continuity there, it will create other patches not available before...)

 

There should be a way to save what was on the four old patches and slap that onto the four new patches since the general arrangement of them is the same and and the outer boundaries are the same.

[nemyax]

There must be some judgement at work in the current OBJ importer

It might be angle-based.

 

 

I'll ask Steffen about it...

If he agrees to do it, that will be fabulous. Can he publish the sources for prying eyes if he does?

[Fuchur]

I am not sure... if it would be a plugin, it would be possible, but I'd say it should be a system function which is very likely not publicly available.

We will see.

[robcat2075]

If it was something you needed to do a lot you wouldn't want to have to keep doing >Wizards>plugin every time.

[Fuchur]

exactly what i thought here. > system function.

[robcat2075]

For this to be very useful I think it will need preserve the old decal on the new patches.

 

.

[pixelplucker]

Doesn't the OBJ importer work fine as long as the model is all quads? Isn't it always an issue if there is an n-sided face in the obj?

There were tests done before and I believe people found with sub-division models that used the doo sabin worked better than the more common catmul clark method. Not sure where that post was.

 

For any mechanical models as obj files coming in to AM in the modeler I never had much success especially with complex geometry, for organic/character models, they seemed much better. I did try the Troer converter but have yet to get it to work without either a crash or spaghetti.

 

Alternatively, if the model is sloppy in the first place it is probably better to use the snap to surface feature and just trace over the model in AM. This can be less work and give you a much more optimized model verses fiddle farting (technical term for correcting garbage) with an imported model.

[nemyax]

Doesn't the OBJ importer work fine as long as the model is all quads?

Nope. All-quads is no safeguard.

[pixelplucker]

Did you try the Troer converter? I have seen some good results that others got using it. I couldn't and haven't spent time fiddling with it.

 

For mechanical stuff that isn't animated in the sense of deformations or in need of bones etc. Importing an obj works really nice. I use MOI 3d quite a bit for cad modeling and I name my groups in there so when I export the model out I can quickly select the surface groups and change the material properties on them.

 

Here is a quick sample I used for a product. The award, holes, and screws are done in MOI, the insert inside is done in AM for the decal. Note I use only triangles from MOI, no quads, no n-sided faces.