Spring creation and force calculation

Started by
97 comments, last by Mystery 19 years, 7 months ago
Quote:Original post by lonesock


2) every point gets a lateral accel (my spreading force), as well as gravity:
- AccelX = PositionX * 0.1
- AccelY = -10.0 (gravity)
- AccelZ = PositionZ * 0.1


How did you come with this? How is the force related to the position? Thanks.

Quote:Original post by lonesock

I would like your texture file, but I'm moving, so I'm not sure when I'll get a chance to work with it...when is your project due?


Let me know when you are ready and I will host the texture file. My final project submission is due early next year but this part(flattening of the structure) is long overdue according to my schedule. :(
Advertisement
the spreading force:

I want every point pulled gently away from the center of the object (not in the "up" vector). So, since I centered the object around 0,0,0 the position vector of each point is also the direction vector that I want to pull it. Think about a quad centered around the origin. each corner is pulled straight out (like a blanket, with 4 kids pulling on the corners), so the force goes from the center through the position. I just adapted that in 2D to the current situation (I think the official name is the "Unit Sock Stretch Method" [8^).

Go ahead and post the texture (preferably the highest quality .png). I'll grab it tonight, but may not get to implementing it till Tuesday.
Ok. Here is the link. :)

I will try out the spreading force. It looks really great. :)


Quote:Original post by lonesock
the spreading force:

I want every point pulled gently away from the center of the object (not in the "up" vector). So, since I centered the object around 0,0,0 the position vector of each point is also the direction vector that I want to pull it. Think about a quad centered around the origin. each corner is pulled straight out (like a blanket, with 4 kids pulling on the corners), so the force goes from the center through the position. I just adapted that in 2D to the current situation (I think the official name is the "Unit Sock Stretch Method" [8^).

Go ahead and post the texture (preferably the highest quality .png). I'll grab it tonight, but may not get to implementing it till Tuesday.
got the image, thx.
Er.. I couldn't find any information on the "Unit sock stretch method" over the net. Do you have a link or something? Btw, why is there a need to create a force in z direction? Shouldn't it be enough for the x-direction to simulate a spreading out effect?


Quote:Original post by lonesock
the spreading force:

I want every point pulled gently away from the center of the object (not in the "up" vector). So, since I centered the object around 0,0,0 the position vector of each point is also the direction vector that I want to pull it. Think about a quad centered around the origin. each corner is pulled straight out (like a blanket, with 4 kids pulling on the corners), so the force goes from the center through the position. I just adapted that in 2D to the current situation (I think the official name is the "Unit Sock Stretch Method" [8^).
Quote:Original post by lonesock
it seems that the solver is nice and stable, but the initial connector lengths are _not_ correct for a final flat solution, so it "jumps" after a while.

Thank you for the confirmation.

Quote:Original post by lonesock
I believe the "bouncy" part is because the constraints (original stick lengths) are not actually solvable for a flat final configuration.

True. Gauss Seidel will jump at this. The conjugate gradient method would not jump but the result would not be a nicely spread out system either since the energy minimum of the original network (under gravity) is not one that is totally spread out. The false preconditions from the 3D scan will kick any solver's ass thrown at it.

Quote:Original post by raydog
Quote:
I've used the NAG-library routines for finding the minimum energy configuration for random fibre networks for example, and successfully I might add.

Can you provided some more details on finding the minimum energy configuration? How is this solved mathematically?

Using, e.g., the conjugate gradient method:
The system dynamics are specified by F = KU, where F is the Force/Momentum vector, K is the stiffness matrix, and U is the displacement/angular displacement vector, respectively. Minimize the function f(U) = 1/2 Tr(U)KU - Tr(F)U + c, where Tr is transpose, not trace. As the stiffness matrix K is both symmetric and positive definite, the minimum is found at the point where Grad( f(U) ) = KU - F = 0. The system is iterated using Uk+1 = Uk + Ak Pk where Ak are chosen such as to minimize f(Uk+1), and the optimization direction P is conjugated to the matrix K, i.e., <Pi, KPj> = 0, for i != j. (excuse the possible typos, this is from the top of my head)

It should be noted, however, that the original method Mystery has, and the Gauss Seidel lonesock pointed out both effectively do a minimum energy search. Minimum energy search is what Nature does every single second.

Quote:Original post by Mystery
Er.. I couldn't find any information on the "Unit sock stretch method" over the net.

Lonesock is pulling your leg here. There is a slight problem though. How do you determine the correct strength for this spreading force, lonesock?

I'm still pushing forward the idea of dropping this problem to pure 2D before simulating it with any of the methods brought up to date. If there are no overhangs we could just eliminate the z-dimension and spread the network from there with the method of choice. The rest lengths of the springs/sticks would be gathered from the original 3D network, of course. You've seen the data, lonesock, what is your view on this? Note, that this will not take care of the false edge lengths of the original network but it _will_ speed up the solver of choice.

How accurate is the 3D scan, Mystery? How, exactly, do you get the connections and the edge lengths from the document to be restored? Was the geometry solved by lonesock the original or the subsampled one?

JD

[Edited by - JesusDesoles on August 30, 2004 2:37:15 AM]
Quote:Original post by JesusDesoles
Lonesock is pulling your leg here. There is a slight problem though. How do you determine the correct strength for this spreading force, lonesock?



Haha. No wonder the official sounds a little strange. Maybe lonesock can do a little writeup on his "theory". I am curious how he derive 0.1. Maybe it is a matter of trial and error. For my case, 0.018 seems to work pretty well but I am afraid this is a case to case basis.

Quote:Original post by JesusDesoles
I'm still pushing forward the idea of dropping this problem to pure 2D before simulating it with any of the methods brought up to date. If there are no overhangs we could just eliminate the z-dimension and spread the network from there with the method of choice. The rest lengths of the springs/sticks would be gathered from the original 3D network, of course. You've seen the data, lonesock, what is your view on this? Note, that this will not take care of the false edge lengths of the original network but it _will_ speed up the solver of choice.



If we simply drop it down to the plane, wouldn't the reduced total surface area suggest the possibility of overlapping surface area. Also it might be a bit tricky to find a terminating condition.

Quote:Original post by JesusDesoles
How accurate is the 3D scan, Mystery? How, exactly, do you get the connections and the edge lengths from the document to be restored? Was the geometry solved by lonesock the original or the subsampled one?

JD


It is the subsampled version. The 3D scanner will scan the object and store the geometry in a wavefront file.

This the camera/scanner that I am using -> http://philip.greenspun.com/wp/display/2681/2710.wimpy

The first section will store all the coordinates of the vertices. The 2nd section is the texture information and the 3rd section will indicate which 3 vertices will form a triangle.

[Edited by - Mystery on August 31, 2004 1:17:14 AM]
Quote:Original post by Mystery
I am curious how he derive 0.1. Maybe it is a matter of trial and error. For my case, 0.018 seems to work pretty well but I am afraid this is a case to case basis.

Every fitting parameter diminishes the value of a scientific theory. One should at least try to explain where the parameters come from.
Quote:Original post by Mystery
If we simply drop it down to the plane, wouldn't the reduced total surface area suggest the possibility of overlapping surface area.

Not necessarily. The surface area of the artificially flattened geometry is of course less than that of the original three dimensional geometry. The flattened state is the new initial configuration of your simulation. The method (G-S for example) notices that the sticks (, springs, whatever) don't fit into this initial state and starts arranging the node coordinates so that the sticks fit thus spreading out the network. The sticks don't fit because their lengths are derived from the original 3D structure. They do fit if the network is spread out and on the simulation goes.

As lonesock and I have suggested the stick lengths are wrong to begin with and this causes the fluctuation in lonesock's simulation. This fluctuation would occur also in the 2D simulation discussed. Dropping the simulation to two dimension is not the answer to the problem at hand. It is an optimization and a way to streamline your theory once you're happy with the basic dynamics of your process.

Quote:Original post by Mystery
Also it might be a bit tricky to find a terminating condition.

Once you get the simulation right it is easier to start searching for a new terminating condition. Don't worry about it yet.

Quote:Original post by Mystery
It is the subsampled version. The 3D scanner will scan the object and store the geometry in a wavefront file.

It would be good to see lonesocks simulation running on the original (not subsampled) network. It may be that the subsampling gets the stick lengths wrong.

JD

[Edited by - JesusDesoles on August 30, 2004 7:38:21 AM]
Hi, All.

OK, the spreading parameter (position / accel gain) was just a guess...in fact the whole idea was just a guess that I implemented in a 30 minute (hack) proof of concept. So, not very scientific, I'm sorry [8^). However, since I am not using springs, there is no penalty for a large force as there will be no extra lengthening of springs. It is more important that the spreading force be balanced, so there is no skew. This would be different for a spring simulation.

Sorry about the joke on the name of the method, Mystery. You are free to call it whatever you will [8^)

For a generic case, I would recommend starting the solution in 3-D, because I have no idea if there will ever be overhangs. However, if the data acq tool is a simple heightfield scanner (one z for every x,y pair), then starting in 2D would be preferable, IMO.

ways to improve the scheme:

* much finer mesh...makes the spring / stick lengths more accurate.

* use knowledge of the final structure: we know it is going to be a perfect rectangle, we could add that information into the solver (e.g. add more error weight for edge points not along the rectangular boundary) (e.g.2. constrain every edge point to someplace on the rectangular boundary, then use springs for the internal points so they will find their "happy place"

* break each current stick into 2 joined sticks...this will implement a tension only kind of solution (in compression the stick will fold, but not affect any of the original coordinates used in the triangles). So you will get a flat solution, however you've changed the problem statement, so that may be an issue.

* we could do a "stick length correction factor" based on the curvature of the surface at that point: something like 1.0 for perfectly flat, and 0.9 at 45 degrees or something. This is just another hack unless you do the math.

Hope this helps, Mystery.
Quote:Original post by JesusDesoles
Not necessarily. The surface area of the artificially flattened geometry is of course less than that of the original three dimensional geometry. The flattened state is the new initial configuration of your simulation. The method (G-S for example) notices that the sticks (, springs, whatever) don't fit into this initial state and starts arranging the node coordinates so that the sticks fit thus spreading out the network. The sticks don't fit because their lengths are derived from the original 3D structure. They do fit if the network is spread out and on the simulation goes.

As lonesock and I have suggested the stick lengths are wrong to begin with and this causes the fluctuation in lonesock's simulation. This fluctuation would occur also in the 2D simulation discussed. Dropping the simulation to two dimension is not the answer to the problem at hand. It is an optimization and a way to streamline your theory once you're happy with the basic dynamics of your process.


JD


Here is what I tried:

1) Read the obj file and initialize the springs with their rest lengths.
2) Set the position of each particles to its lowest point so that a 2d structure is formed.
3) Start the simulation with only the spring force, ignoring gravity.

No terminating condition at the moment. Just observing how the simulation goes from here.

Results:
Structure becomes unstable after a while(much faster than original method)

Question: Shld the spring force acts only on the x and y axis and ignore the z-axis?

This topic is closed to new replies.

Advertisement