i didn’t expect that Deworm is going to grow into such serious project, but more time i spend thinking of it and with a lot of feedback from you guys (tnx a lot), deworm is going to become quite large and complex.

i am opening this tread so we can try to fix bugs and improve it together.

i think it has to do with JointVectors (3D) module included.

this module is defining the orientation of each section in the folowing way:

central line is made of vectors pointing from one point to another

every section is made around each point (circular spread)

each point has this joint vector telling where-to the section is facing

except for first and last point, joint vectors are defined in a way that each section is rotated half way along the center line thus making smooth deforming.

(i should make an image for explanation soon)

(writing this is also helping me to find a bug)

joint vectors are normalized… something here is messing the thing…

if the segment normal is pointing someway along y axis (pitch and yaw 0.25 for example), leaning from positive x to negative x rotates or flips the segment.

||https://vvvv.org/sites/default/files/imagecache/large/images/x_positive.jpg|https://vvvv.org/sites/default/files/imagecache/large/images/x_negative.jpg
positive x|negative x
segment is cyan triangle, normal is yellow line||

so i need to have new coordinate system for every segment whose x axis lays on central line. or?

still don’t know how to do it.
because if i first apply transform for a segment to align its normal with central line it might get rotated for the same reason described here.

I’ll have to admit that I need to read some more about Matrix & Vector math before I can contribute anything to solving these bugs other than wild speculative patching - but I’m on it ;)

hey, thx for your support! your topic is really concerning gregsn or me, but we both sitting tired form the latest project in bruxelles and preparing a workshop for tomorrow. so i hope you can solve it yourself, which would be best for you from an educational point of view ;) if not, you’ll have to be patient until we get some more spare time to digg into your module… best wishes.

if i want to maintain the orientation of the section laying on the xy plane and lets say rotate it 180 deg around z axis, and then rotate it 180 deg around y axis, normal vector would come to the position where it was on the first place, but section would need to be flipped upside down.
translated to deworm: if we start with section parallel to xy plane and make half circle bend upwards (around axis parallel to x) and then half circle to the right (around axis parallel to y).

it is obvious that i can not get needed section orientation by appling roll to the sections based on their normal’s angle.

it could be done by discovering the twist and appling roll to all sections after that one and before the next twist.

the roll would be a function of the angle between normal and y axis in the moment where x or z direction of normal is changing through zero (or just closing to zero).
i.e. the dot product of normal and (0,1,0) exponentialy leads to 180 deg roll in either direction.

the task is to maintain the roll for all consecutive sections without using loops, because loops would take too many frames thus making animation too slow if deworm is very long.

roll values should be in spread i.e. one for each section and when twist is about to happen calculated roll should be preserved for all consecutive sections till the next twist and then calculated again.

how to do that with spreads?

huh. i am not sure if this writing could be understood at all.

it’s a beta (well aren’t vvvve all?) cause few things still need some attention.
there is no help file included and i used my own dot and cross product modules, because those are buggy in the old version i am using. feel free to replace them.

there is a TwistFix pin that turns on… well, the twist fix.

twist fix solution is included in JointVectors(3D) module.

it’s a funny story about how i originaly started with this module and i was thinking about connecting-points as joints. first, only pitch and yaw were information that i needed. and now i had to roll some joints to fix the twist.

here is a little explanation for those who might want to help.

(sometimes i feel like i am all alone. “tell me about your childhood”, some psychiatrist would say…)

so, it goes like this:

take arbitrary orientation vector of the first section

rotate the first section and project that vector on the second section - (substracting dot product vector on second section normal)

find Cosine of angle between that vector and same orientation vector rotated with second section (dot product again).

do cross product of second section normal and orientation, so to find Sine of that angle.

divide Sine and Cosine to get Tangens

do ArcTan and divide it with 2 Pi to get vvvv angle

flip that angle over if Cosine is negative

roll that section and add that roll to all subsequent rolls

little tip:
using ArcTan instead of just ArcCos make it so smooooth. if you ever want to get precise angle, do like i did.

still reading? good. cause we need to do something here.

‘/’ node outputs 1 if number is divided by zero. that would be 90 deg angle, but it turns into 45 deg - ArcTan(1). not so hard but yet another spread.

if the first section gets close to gimbal lock during animaton, the whole worm rotates rapidly. not nice. have to watch the first orientation vector and try to avoid that. or…?

i have included some hints inside Deworm module so you can trace the way through it.

although the ‘fix for twist’ works somehow i would like to find the way to work with sections in more… well, intuitive way. what i am saying is that, sections are rolling and twisting about because of mathematical reasons, coordinate system and all… while in real life we would escape that kind of behavior or better to say, that kind of expirience.
deworm became kind of 4 dimensional problem in my head…
…
… OMG

nevermind that…

the next step is creating caps for segments the way @elektromeier suggested.

that needs:

caps geometry

texture coordinates for new vertices

the second one i find challenging.

a single word posted to this thread would give me great motivation and pleasure.

majortom, your sock-rocking worms are still very alive in my drawtool; i didn’t post an un-twisted version yet because of some control changes that still need tweaking. and i could easily imagine another five dozens of uses for that great module, however, my spare time is kind of a limited ressource :/

(btw, you do know about checking the ‘minor’-box when making minor changes to your userpage, do you? my mailbox gets a little flooded ;))

If you use Bin Size and displace parts of the worm far away, it is bad when end sections follow the central line i.e. orient themselves toward the sections on the other side of the gap.

This idea is so simple, soooo logical. I have not seen this in other patches, so it might be usefull for you as well…
after all, it makes deworm some 30% easier for CPU.

Let me explain this using one example.

Let’s say we have 100 sections of deworm. Each section is made of 20 vertices. Total slice count is 6000 (201003)

Each section has to be rotated and positioned, so we are rotating and moving groups of 20 vertices by the same values.

We have two spreads, one with Pitch, Yaw, Roll rotation vectors and one with translation vectors. Each with 300 slices (100*3)

Since we have to use the same rotation and position vectors for groups of 20 vertices we need to resample those vector spreads so to rotate and translate each vertex.

Something like this:

This works and it is not so bad for simple translation. But think about rotation. We would have to create 2000 transformations (that are 16 slices matrices) before we could apply them to the spread of vertices.

It seems so obvious to me now that it is much better to rearrange the spread of vertices and use minimal number of transformations that would cycle through new spread. We need to reorder the spread so to have: vertex 1, vertex 21, vertex 41… through 81, then vertex 2, 22, 42… and so on.

After we apply transformations we have to reorder the spread of vertices back to original order.

Here it is:

I might have discovered that ‘the earth is not flat’ here. Nevertheless it is OK to have this method documented.