Spring creation and force calculation

Started by
97 comments, last by Mystery 19 years, 7 months ago
yep:

read in x,y, set z=0.0

compute forces only in x & y

watch in awe (I hope).

BTW, hopefully I can get back to my code on this tonight. should be interesting to see the textured version.
Advertisement
Quote:Original post by lonesock
yep:

read in x,y, set z=0.0

compute forces only in x & y

watch in awe (I hope).

BTW, hopefully I can get back to my code on this tonight. should be interesting to see the textured version.


Ok. To compute in the x and y direction means that we have to distribute the z-force to x and y in order to restore the original length right?

Btw, once you are ready, I can post the mesh with 5 times more points then the one you downloaded. See if there is any difference. :)
No need to compute the z force at all...just make sure you compute the spring length in 3D.

I was thinking about this problem some more:

You are looking for a static solution, so there is no need to simulate dynamics, unless you want a simulation to look natural. So, you basically ignore mass (and momentum). Instead of computing the forces of springs and using that force vector to add to the velocity (etc.), using a spring constant of 0.5 just add the final "force" vector directly to the position at each time step, ignoring velocity and acceleration. This should also help the stability of the solver, and is "optimized" regarding the spring constant. You probably won't even need the spreading force (goodbye unit sock stretch method [8^)

Go ahead and post the high res mesh, Ill grab it this afternoon sometime.
Without the velocity and acceleration, how are you going to determine the new position at eact time step?

Here is the more complex mesh(ard 10,000 data points).



The original mesh is around 35mb in size and have problem finding a place to host it.


Quote:Original post by lonesock
No need to compute the z force at all...just make sure you compute the spring length in 3D.

I was thinking about this problem some more:

You are looking for a static solution, so there is no need to simulate dynamics, unless you want a simulation to look natural. So, you basically ignore mass (and momentum). Instead of computing the forces of springs and using that force vector to add to the velocity (etc.), using a spring constant of 0.5 just add the final "force" vector directly to the position at each time step, ignoring velocity and acceleration. This should also help the stability of the solver, and is "optimized" regarding the spring constant. You probably won't even need the spreading force (goodbye unit sock stretch method [8^)

Go ahead and post the high res mesh, Ill grab it this afternoon sometime.
position += modified_force

I'll grab the file in about an hour...thanks.
Quote:Original post by JesusDesoles

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


Hi JD, the result after starting from a 2D state is still not ideal. I am not using any external forces, simply spring force in the x and y direction.
OK, I'm back.

newest version:
www.lonesock.net/FlattenResults.zip

What I did:
* I used the full 3d version with spreading force to start
* I damped the motion at each step (velocity *= 0.8) to reduce dynamic effects
* I set my stick tolerance to 0.1% (my solver would iterate until motion of less than 0.1% of original length was observed, for every stick)
* Once every point was within 10 units of the ground plane (about 5% total width), I switched to a 2D solution by locking every point onto the ground plane (y = 0.0) and removed my spreading force.
* on quit I exported the new coordinates

Caveats:
* the original obj file seemed to swap y and z values
* the original obj file had texture coordinated in pixels
* the original picture was not square or a power of 2 (640x480)
* if there was a full scan of the book, then the image did not seem to line up with the original model.

the new obj files in the zip were hand re-assembled (instead of spending an hour writing a full obj importer, I spend an hour with a spreadsheet program [8^(

hope this helps
Great to see you back and the results. :)

A couple of questions:

1. So the spreading force is still the "unit sock stretch method"? If so, I still couldn't quite understand the motivation of mulitplying a constant with the position to get the "spreading force". I am not concern with the value of the constant but rather why position and velocity or even a constant force. :)

2. The left pic on your compare.jpg is the resulting image and the right one is the original one right? If so, why is there blurring near the spine of the original image? Btw, are you using just normal printscreen to capture the images? If not, I would be interested to know how to save out the resulting image. I will try to post my results too so we can do a comparision. :)

3. What is comparison.an8?

4. I am not sure what you meant by full scan? I just did a single scan on the front of the book. I believe for some applications, a multiple scan is required.

I hope to capture more test images tommorrow. If you are interested, I would gladly share them with you.

OT: Are you also involved in some kind of graphics research yourself?

Quote:Original post by lonesock
OK, I'm back.

newest version:
www.lonesock.net/FlattenResults.zip

What I did:
* I used the full 3d version with spreading force to start
* I damped the motion at each step (velocity *= 0.8) to reduce dynamic effects
* I set my stick tolerance to 0.1% (my solver would iterate until motion of less than 0.1% of original length was observed, for every stick)
* Once every point was within 10 units of the ground plane (about 5% total width), I switched to a 2D solution by locking every point onto the ground plane (y = 0.0) and removed my spreading force.
* on quit I exported the new coordinates

Caveats:
* the original obj file seemed to swap y and z values
* the original obj file had texture coordinated in pixels
* the original picture was not square or a power of 2 (640x480)
* if there was a full scan of the book, then the image did not seem to line up with the original model.

the new obj files in the zip were hand re-assembled (instead of spending an hour writing a full obj importer, I spend an hour with a spreadsheet program [8^(

hope this helps
Nice one, lonesock. The blur near the spine is to be expected since the image data is not adequate there (assuming the one on the right is the result of the simulation).

I'm in the middle of changing jobs so I may be a bit quiet for a few days still.

JD
1) Yep, still the USSM. The idea is to move every point in the mesh away from the center of gravity. The away vector is parallel to the vector (position - cg), so I just scale that down to make it less overwhelming to the solution.

2) The left hand image was mapped onto the original mesh. The right hand image was mapped onto the flattened geometry (note the stretching near the spine, as JD pointed out) I used anim8or to do the renders, so no screen capture for me.

3) comparison.an8 is the mesh file in anim8or's format. It is an awesome program, and free. Cool open format with documentation on the website. www.anim8or.com

4) the image did not seem to cover the whole of the 3-D geometry, and I was wondering if the image did indeed line up with the mesh, or if there are other, wider images that do. Did the 3D scanner take the digital picture? And is there a calibration process for it?

More test images would be great, thanks. I need to break down and write the obj loader so I can do this on the fly. And I don't work in graphics research, but I do lots of numerical simulation type things, so I love this kind of problem.

@JD: thanks, enjoy the new job!

This topic is closed to new replies.

Advertisement