Creating a upvector for a twisting rollercoaster

[MissStabby]

Currently i'm creating a rollercoaster generation tool.
However i've currently came across a problem i cant seem to solve.

For the rollercoaster i have created a duplicate spline of the path that my rollercoaster takes so i can use a VOPSOP to generate a up vector that lets the rollercoaster track bank accordingly. for the "side to side" banking i have managed to solve the problem using a cross product node that uses a few attribute vectors previously generated through a polyframe node.

However the problem i'm now stuck at is having houdini see the difference between hills and loops,
If i use a smoothing operation to smooth the banking or up/down offsets loopings work fine, however at hilltops the upvector curve is pulled below the original path, causing the rails to invert. Transforming the entire upvector line upwards will cause inversions to "not" invert and just cause instant reversal of the track's orientation by 180 degrees at hilltops.

here is a screenshot of how the "upvector" line behaves right now and the effects it has on the track.


Is there a way to let houdini "detect" the difference between a place for an inversion or the place for a hilltop?
I could then use a attribute to let the upvector generation switch between 2 methods of calculating the offset it should have.

 

Edited February 13, 2014 by MissStabby

[edward]

I'm not sure if it's a good idea to use a separate curve for defining the up vector. Are you doing this via object paths? http://www.sidefx.com/docs/houdini13.0/nodes/obj/path

[MissStabby]

im currently using sweep sops, strangely enough if i dont have an upvector it behaves partially correct, though then i dont have any influence over the banking and some corners it will bank in the wrong directions, for twists and hills however it will actually perform relatively correct. though at the place where the path connects to itself it has a offset that it corrects in just 1 segment which looks really wrong.

Here is a screenshot of the tree
http://i.imgur.com/SelaWqV.png

At the top i'm generating a generic coaster path (without loops) then there is a switch (switch1) that switches between generated and handdrawn coaster paths.
The section below that resamples the path depending on certain properties that the coaster has. There you see all connections go out to all the different parts of the coaster generation,
ribs/rails/supports/spine etc. 

After that there is a cluster in the center that creates the upvector path, that also fans out to all the other parts of the tree where all the sweepnodes are.
and in the end it is all merged together again into 1 node.

 

Edited February 13, 2014 by MissStabby

[edward]

So how about just resample the curve with normals ("N")? You can then just rename it to "up" for the Sweep SOP to use it?

[MissStabby]

the problem is not the linking of the upvector curve (the curve that the sweep uses to determine what part should point where) to the sweep or generating the normals ect. 
The problem i now have is that i cant seem to modify/ajust the upvector curve to account for both inversions and hills at the same time.  With a hill the "upvector" has to be higher than the track path in order for the rail to stay upright. For an inversion, like a loop/corkscrew/twist/immelman the "upvector" curve has to go lower than the track path in order for the rail to point downwards.

If i'm using polycages with vopsops that generate vectors based on crossproducts from the polycage vectors i generated previously i create a VOPSOP that works great with bends and hills.
If i just resample a curve it works great with bends and inversions but breaks at hills where it inverses the rail.

This is how my 2 methods of calculating the upvector perform in the scene, when looking at a 2d sideview of it:

I now need to figure out a method to tell houdini when to use what method, though a looping is not much different from a hill from houdini's perspective.

Edited February 14, 2014 by MissStabby

[loudsubs]

I think this hip file will help you.  the polyframe does most of the work, then a cross product gives you the third vector to construct a matrix.

coords.hip

[MissStabby]

Thanks Peon, it seems to work, especially after i put a "negate" node between normalise3 and bind1(up) this causes the "up" vector to point to the center of the curves instead of the outside.

However... when i close the curve it seems to go beserk.

For some reason it works fine when the curve is open, but as soon as i close the curve it seems to glitch and behave incorrectly.


EDIT: I also tried using an "ends" node to open the curve before and after the normal generation and vopsop but it didnt have any effect.
It seems like the polyframe breaks down after the curves get more complex than a single loop. 

Here is another rollercoaster shape that i drew, with the red line being the "up" vector from your hip file.

Edited February 14, 2014 by MissStabby

[edward]

The problem i now have is that i cant seem to modify/ajust the upvector curve to account for both inversions and hills at the same time.

 

Sorry, I wasn't being clear. I was proposing to not use an upvector curve at all. In fact, there's no good way to calculate such reference frames without propagating it along the curve from some initial reference frame. The easiest is is to find the quaternion rotation between two successive tangents and use that to rotate the normal from the previous reference frame to the next one. Then as long as your points along the curve are well sampled to capture the curvature, it should be pretty good. See http://www.unchainedgeometry.com/jbloom/pdf/ref-frames.pdf for reference.

 

I took a quick look and didn't seem to find a ready VOP to do this but the formula is easy enough: http://stackoverflow.com/questions/1171849/finding-quaternion-representing-the-rotation-from-one-vector-to-another (just use the first answer). Beware that you must first check if your tangents are pointing in the same direction, in which case you should just do no rotation (ie. just use the previous frame's normal).

 

EDIT: As the reference points out, you will not get the ends to match up exactly using this approach. The Path Object (and corresponding use with follow curve IK in the InverseKin CHOP) takes a slightly different approach where it looks at the successive normals and interpolates something that is even distributed from one control point to the next. This way, the ends will line up if they have matching normals but I'll leave that as an exercise for the reader.

[MissStabby]

wow thanks, sure seems like a good excersice "for the reader"
I gotta admit that i'm relatively new to houdini (about 6 months or so) so quaternions are new for me.
but I'm going to have a go at it. 

EDIT:

Hmm i took a look at the the path object, and it looks very promising, though the system seems to also "upright"  the position, 
however that abrupt motion could be "detected" by a vopsop and then compensated for in some way.

Here is a gif showing what it does with the vectors:

Edited February 15, 2014 by MissStabby

[edward]

The process that I'm talking about occurs when you do a Bones From Curve with kinematic enabled. So I don't think your test is using it.

Once you have the quaternion set up in vex/VOP, there's a function to convert it to a matrix3 so you can just multiply your vector by that. There's also a Rotate by Quaternion VOP you can use as well.

[magneto]

Edward, instead of using that stackoverflow code, would it work to use the Align VOP with Matrix3 to Quat VOP?

[Guest mantragora]

I admit, I did not read all the posts here, but maybe something like this will work?

http://www.mediafire.com/download/apucpja15kazxkg/WEEEeeeeeeee.zip

[edward]

Edward, instead of using that stackoverflow code, would it work to use the Align VOP with Matrix3 to Quat VOP?

 

Ah yes, that was the VOP I was trying to find! Thanks! Then you don't need to convert to quaternion at all.

[magneto]

Ah yes, that was the VOP I was trying to find! Thanks! Then you don't need to convert to quaternion at all.

 

I used to have a hard time finding that VOP in the beginning, as the VEX function is called dihedral after all

[edward]

After actually trying this out myself, some more thoughts:

• The Sweep SOP already does what I describe when told to automatically sweep. So instead of doing it manually like I described with quaternions, you can actually just sweep some lines through your curve to get the reference frames I described.
• The Follow Curve IK with the Path object is really what you need except it's not in a easily usable form for this problem because it requires actual bone objects instead of just outputting reference frames.
• The real problem is that you need to specify constraints as to where the roller-coaster should be upright, ie. at the beginning and end of loops. So you can use these to evenly distribute the twist over the loop. Given this, the problem might not be too bad, rotate each successive frame around the Z axis by the quantity 360 degrees divided by the number of curve segments in between them.
• For helixes, it's similar I think except that it might be n*360 degrees distributed evenly, where n is the number of loops you have.
• For a more automatic way, perhaps what you do is start the sweeping algorithm from both ends of the loop (ie. do the same thing with the curve reversed). Now blend the two results with some feathering at the ends.

 

FWIW, I've attached the manual way that I ended up trying out before realizing I had just recreated the Sweep SOP's algorithm.

refFramesQuat.hipnc

[edward]

One more thought a day later. You can just try to add a separate rotation to "fix" the sweep algorithm. Look at how much you need to turn the last point to match what you want, divide it by the number segments to get there, and now twist all the intermediate references frames by this correction.