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.
diki found this bug
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…
gotta go to bed.
any ideas?
here’s the catch:
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.
what to do?
( problem with BinSize is fixed )
this happens:
https://vvvv.org/sites/default/files/imagecache/large/images/twisted.jpg
red lines are segment normals
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 ;)
tonfilm’s 3D Vector Mathematics is the bible, and now i know what to do.
o_0
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.
tnx tonfilm. i am kinda ‘gimbal locked’ here.
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.
fixed!
decided to add up all changes of section orientations, and Integral node was the answer to the question.
maybe i would have to polish a roll spread cause adding up all values could go sky-rocket. i don’t know if there is a limit for roll value.
anywayz, tnx for watching so far!
o_0
majortom
https://vvvv.org/sites/default/files/imagecache/large/images/dewormx.jpg
you´re the man, majortom :)
looks really nice and smooth now.
it needs some polishing though… i will post the new version soon.
ok, here it is.
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.
deworm v1.2beta.zip (12.43 Kb)
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:
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.
br
o_0
the new version is on my projects page.
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:
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 ;))
sorrrrrrrry! gotta pay more attention to that little boxy.
hey i just played with deworm and is great and trippy too heheh ;D nice job majortom
deworm now has Straight Cut pin.
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.
take a look:
||https://vvvv.org/sites/default/files/imagecache/large/images/normalcut.jpg|
normal cut|
https://vvvv.org/sites/default/files/imagecache/large/images/straightcut.jpg|
straight cut||
optimisation
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:
https://vvvv.org/sites/default/files/imagecache/large/images/resample.jpg
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:
https://vvvv.org/sites/default/files/imagecache/large/images/noresample.jpg
I might have discovered that ‘the earth is not flat’ here. Nevertheless it is OK to have this method documented.
o_0!
it’s a tad too late for me to follow through completely right now, but nice to see you rocking those spreads; i’ll cut myself a slice of that.
