|
|
Scripting idea. A "cable" object.
About Truespace Archives
These pages are a copy of the official truespace forums prior to their removal somewhere around 2011.
They are retained here for archive purposes only.
Scripting idea. A "cable" object. // Scriptorium
Post by ProfessorKhaos // Feb 2, 2007, 7:22pm
|
ProfessorKhaos
Total Posts: 622
|
I never quite know which forum to post in but given that this is probably going to be yet another script implementation I figured I'd pitch the idea here.
I remember a few versions of trueSpace back a somewhat pitiful attempt by myself to model cables strung about a ship... ya... it was supposed to be the titanic... I know... not very original :) It was harder to get right than I thought. Cable droop wasn't very consistent along the length and the cable diameter turned out to be way too large. Would have been nice to have a script object that I could change cable diameter, tension, etc and have the rest calculated mathematically for me.
Anyway, maybe this idea will be somewhat useful.
I was thinking of making a script that could create a cable with variable amount of droop (based on tension) from point to point. Should actually be fairly easy to implement. Hardest part is figuring out the best interface for selecting the two endpoints.
Right now I'm thinking that the end points of the cable could be defined using an object's coordinates (perhaps with an offset of some sort for precise adjustment). May have to take into account some rotational issues.
Mesh could be UV mapped as well so that a rope or cable texture/bump map could be applied along the length of it.
My ultimate goal would be to allow a ship tied up to shore to have it's rope get taunt and slack when the distance between the ship and the mooring changes. Wouldn't stop the ship from going too far, but it could allow the rope to stretch a bit.
In some ways I'm sure this can already be done in the physics simulation model used by trueSpace. I'm thinking more along the lines of dynamic mesh creation that makes use of a quick single-purpose algorithm.
No plans for object collision detection in this one. For that you're surely better off using trueSpace's physics model. This would just be a quick way to make clotheslines, guide wires for antennas, power lines, etc...
I think I've got a good start on the project but any helpers would be welcome. Maybe the project could become the basis of a mid-level script tutorial for folks. You widget masters might have a lot to contribute to this one. I'm still a bit freakish when it comes to tweaking interface stuff (got the course but have to sit down with it and comb through it first).
Cheers!
Glen |
Post by ProfessorKhaos // Feb 3, 2007, 2:14am
|
ProfessorKhaos
Total Posts: 622
|
You are correct about the algorithm. I've been doing a little research into ropes and strings. Basically, we're talking about a particle system. Similar to what you've probably seen for flag animations and such.
For the scope I intend I'm not sure I would use the physics engine.
I was thinking of the following:
Define 2 points in 3D space, preferably defined by a vertices on objects.
Calculate an initial distance between the two points.
Add extra rope based on tension parameter and store final rope length.
Calculate rope droop based on tension and rope stiffness/springiness.
As 2 points in 3D space change, adjust droop to keep rope same length (some degree of stretch) but take up slack based on new distance between points.
To make the rope more dynamic, I would create particles along it's length with mass that react to each other and the forces from gravity and wind. I didn't think of tying this into the existing physics engine but it may be possible.
Other probable controls would be number of bend points along the length, number of vertices in a given cross section (minimum of 3, max ~ 32???), number of UV repetitions along cable length.
I find the other ideas intriguing though. Been starting with what I currently know but always welcome new information. Physics engine would have the advantage of collision detection so cable could be drooped over stuff. |
Post by Wigand // Feb 3, 2007, 2:29am
|
Wigand
Total Posts: 462
|
It is very interesting, that you have the same idea with the cable.
And it is the reason why I asked how I could make a nurbs-path with scripting.
If it would be possible, it would be easy to make a chain along a path. I hope you understand what I mean.
I often saw strings, chains, cable in 3D projekts with no natural forms or size.
I already looked for an answer. First I thought it could be a so called
"parable" like y=x^2 but this is wrong. You need a formula with
hyperbolic cosinus. And the kurve is called "Kettenlinie = german" (chainkurve catenary?) . There are some JScript implements in the net.
You are better JS programmers, so its easier for you to change
the scripts into TS.
Here is an applet with all you would need.
http://www.arndt-bruenner.de/mathe/java/kettenlinie.htm |
Post by ProfessorKhaos // Feb 3, 2007, 6:15am
|
ProfessorKhaos
Total Posts: 622
|
Cool! I sense we are in agreement then that a cable object could be very useful.
Hyperbolic cosine is indeed the straightforward approach to cable droop. A very good static solution and perhaps even dynamic to some degree (in the case of the points moving closer or further apart).
Computationally it may be a very desireable solution because of the ease of calculation.
One reason for the particle system solution would be the simulation of stretch and bounce. More complex to be sure. Probably requires some sort of timing control to get the motion right. Perhaps more ideal for keyframe animations.
I can see advantages to both approaches.
Perhaps first stage is to create a mesh generator (object, not control based script so it automatically refreshes) that can take a series of 3D points and just generate a rope with UV map. Keep this as a separate script module that could be interfaced to either solution.
2A would be to build the hyperbolic cosine version for static & basic animation functionality.
2B would be to build the particle system based solution for complex animated functionality.
3 would be to find a way to udate the endpoints based on tagged objects in the scene.
The first stage could then be used for a variety of projects outside of just the drooped cable. Say someone creates a pulley system object or a spool of rope. Because of the potential for vertical lengths of rope and such I'm thinking that the joints in the rope (for lack of a better term) should be oriented relative to the angle between the segments rather than moved in height alone. That would make the first stage a bit hard to accomplish but perhaps where some time invested would pay off nicely. I may be able to salvage some code I did on tS6.6 for a roller coaster mesh generator/simulator I did in python a couple of years ago.
I will see what I can do with Die Kettenlinie applet. It gives me good confidence that the project can be completed one way or the other. Guess the shoe is on the other foot now as I am reading it in german (courtesy of babelfish.altavista.com).
Personally I will be happy when I can make a ski lift with moving rope and chairs bouncing in the wind. :D
Wigand, your suggestion is very helpful though. I think it will have the best practical use for most folks and solves the original problem as stated.
P.K. |
Post by trueBlue // Feb 3, 2007, 6:53am
|
trueBlue
Total Posts: 1761
|
Hyperbolic cosine :confused: I'll just watch an enjoy. Not sure if this will help but check out what Dele made.
http://forums1.caligari.com/truespace/showpost.php?p=19671&postcount=20 (http://forums1.caligari.com/truespace/showpost.php?p=19671&postcount=20) |
Post by ProfessorKhaos // Feb 3, 2007, 7:03am
|
ProfessorKhaos
Total Posts: 622
|
That's one of the missing pieces that will greatly help! Thanks for pointing it out trueBlue! Of course thanks to Dele for the original script.:banana: I can also think of several uses in structural items for Dele's object too.
Another thought for keeping the mesh generator separate from the dynamics is that the cable might be replaceable by more complex constructions like a chain. Too much to tackle up front but perhaps a worthy enhancement down the road.
I'm thinking that the basic version would make a great mid-level tutorial topic for scripting. The math stuff does get a bit intimidating but perhaps that's something we provide as a self contained engine and focus the tutorial on some subsection of the project.
I'm going to add additional relevant references to this post as discovered so they're all in a group
http://mathforum.org/library/drmath/view/53706.html <--- very good page for catenary lines with endpoints at different heights
http://web.njit.edu/~jcl7/pastimes/catenary/index.html
http://www.arndt-bruenner.de/mathe/java/kettenlinie.htm (German text) |
Post by ProfessorKhaos // Feb 14, 2007, 4:31pm
|
ProfessorKhaos
Total Posts: 622
|
Looks like I finally got a pretty good handle on the hyperbolic cosine approach. Tried a quick particle simulation approach with mixed results. Turns out the numerical stability of the particle sim appears to be quite sensitive to number of segments, cable length, gap width, etc...
Still working on the mesh generator. Just used boxes to represent the segment joints in the particle sim'd method for now.
Hopefully some promising images to show soon.
Some math with the hyperbolic cosine approach breaks down if the cable length is too short for the gap to be spanned. I think I have a reasonable way to address it though by forcing the cable to be long enough in the extreme cases. Rope would stretch and possibly snap in real life anyway.
P.K. |
Post by ProfessorKhaos // Feb 18, 2007, 7:40pm
|
ProfessorKhaos
Total Posts: 622
|
Successfully tested a catenary curve fitting routine in tS7 today. Haven't rigged it up beyond that point for actual mesh work.
Turns out the equations are a real bear to tackle, even with references (one of which was incorrect!!!)
Basically, you want to give the script object 2 points in space and a length of cable. It's job is to calculate the 'a', 'xc', and 'yc' terms in the equation below
y = a*cosh((x-xc)/a) + yc
xc and yc are relatively easy to obtain once you get the value of a. Alas, simple algebra doesn't work and you have to resort to iterative methods to find the right value. Restating xc in terms of a is tricky. Think I destroyed an entire tree of notebook paper running through this several times and getting shades of wrong answers. This one looks right though.
Current version just steps through all values of a from 0.01 to 20 in 0.01 step increments and finds the best value in that range. Future version may use newtonian approximation methods depending on need for efficiency. Script ran much faster than I thought it would.
Screen capture below shows my use of excel plots to confirm the output validity:
Still have to translate script from 2D to 3D but that's actually the easy part.
Cheers!
P.K. |
Post by ProfessorKhaos // Feb 18, 2007, 8:16pm
|
ProfessorKhaos
Total Posts: 622
|
For those who enjoy a challenge...
Here's the equations I'm using
given: L = length of chain
P1 = (x1,y1), P2 = (x2,y2)
deltaY = y2 - y1
deltaX = x2 - x1
y = a*cosh((x-xc)/a) +yc
------------------------------------------------
For symmetrical case (y1 = y2)
L = 2*a*sinh(deltaX/(2*a)) <---- L is known, deltaX is known, solve iteratively for 'a'
------------------------------------------------
For asymmetrical case (y1 <> y2)
deltaY = a*(cosh(deltaX/(2*a) - ln((L-deltaY)/(L+deltaY))/2) - cosh(-deltaX/(2*a) - ln((L-deltaY)/L+deltaY))/2)) <---killed a forest of trees to get here...
again L, deltaX, and deltaY are known so solve iteratively for 'a'
Note: you can't use the above for the symmetrical case because the significance of the L terms gets lost when deltaY goes to 0.
------------------------------------------------
Once 'a' is obtained, xc and yc come relatively easy
xc = (a/2)*ln((L-deltaY)/(L+deltaY)) + (x1+x2)/2
yc = y1 - a*cosh((x1-xc)/a))
------------------------------------------------
Some of the above are greatly simplified if you precompute cable "constant"
cc = ln((L-deltaY)/(L+deltaY))/2
It can be substituted into the asymmetric deltaY calculation and the xc calculation (which is used for either) and doesn't depend on the value of a, so it makes the iterations quicker if you calculate it up front.
I use threshholds to determine if y1 and y2 are "equal enough" for the symmetric vs asymmetric cases. Similar test with x1 & x2 (if equal, just drop a folded rope straight down). Script also has 2 ways to deal with a cable that's too short to cover the distance (direct line, vs stretched catenary) |
Post by Wigand // Feb 22, 2007, 7:24am
|
Wigand
Total Posts: 462
|
Sorry, I have no time to test all of your formulas, but I think your project
is on the right way. I'm looking forward to see how you will create
the rope (a nurbs path/curve would be great). I think it will be the difficult part of the job.
For me, but not for you. ;) |
Post by ProfessorKhaos // Feb 22, 2007, 5:43pm
|
ProfessorKhaos
Total Posts: 622
|
Afraid I haven't done enough to tackle a script based nurbs solution at this time so my plans were for a polygon based solution. Can see no reason why nurbs solution couldn't leverage off of this script's output though. Perhaps that may be a good followup project for someone.
Should be close to another update by this weekend. Depends on the success of my efforts to improve upon the iterative technique for finding the value of 'a' above. Got a Newtonian method sketched out on paper but still need to confirm if it works the way I think it will with a variety of values.
Glen |
Post by ProfessorKhaos // Feb 24, 2007, 9:08pm
|
ProfessorKhaos
Total Posts: 622
|
Abandoned the newtonian approach for one quite a bit simpler...
Provided x2 > x1 and cable is long enough to span the gap, and
f(a) = calculated cable length based on value of a - actual cable length
when the value of 'a' is correct the calculated cable length matches the actual cable length and f(a) returns a value of 0.
Thus:
f(a_guess) < 0 if a_guess > a_actual
f(a_guess) = 0 if a_guess = a_actual
f(a_guess) > 0 if a_guess < a_actual
I start with an arbitrarily large value for 'a_guess' and divide by 2 until f(a_guess) goes from negative to positive, then I know that the correct 'a' exists somewhere between a_guess and a_guess*2.
from here, I assign
a_low = a_guess
a_high = a_guess*2
I then do a similar search between a_low and a_high. If f(a_middle) > 0 then I know that the a_middle can become the new a_low because the proper value for a is between a_middle and a_high....
converges quite rapidly on an answer too with a final precision set by a specific tolerance threshhold.
Got it working under a variety of conditions. Doesn't like the case where horizontal distance between coordinates is extremely small but I have a way to deal with that very specific case.
Glen |
Post by ProfessorKhaos // Mar 1, 2007, 8:19pm
|
ProfessorKhaos
Total Posts: 622
|
Not much free time lately...got a couple of hours in tonight.
A little more progress... now solves for cable droop between 2 3D points. Still have to hook up to a mesh generator before the cable object will be viewable.
testout_x, testout_y, and testout_z indicate the x,y,z location of a given point on the cable.
testout_zz is the relative distance along the cable (0 = start of cable, 1 = total length of cable). This will be useful for proper UV mapping along a cable's length for the mesh generation stage.
Example below uses 2 cube objects to specify endpoints of the cable.
Glen |
Post by ProfessorKhaos // Mar 5, 2007, 5:39pm
|
ProfessorKhaos
Total Posts: 622
|
Created a test object... doesn't draw the rope but shows endpoints (bigger boxes) and 5 points along the way (small boxes). Exact spacing of 5 middle points are not necessarily even intervals along rope so look more for the curve shape than the point placement.
You can lengthen/shorten the rope and change endpoint positions using the sliders. Catenary (cable droop) solver is the same one as shown in SE above.
Hyperbolic cosine/sine was the ticket to this solution per Wigand's suggestion.
I've encapsulated this project but the endpoints can be any object's coordinates... just tap into the matrix for the object. We'll have to see how the final mesh generating version works.
.rcd file below can be tried in truePlay (panel shows automatically)
Glen |
Post by ProfessorKhaos // Mar 6, 2007, 4:44pm
|
ProfessorKhaos
Total Posts: 622
|
Moving on to the cable mesh generation section... |
Post by ProfessorKhaos // Mar 10, 2007, 8:51pm
|
ProfessorKhaos
Total Posts: 622
|
Managed to create a cable-like mesh but having some issues. I believe it's due to surface normals somehow.
Been examining the cone script object and it seems to have the same issue. Shading at the edges appear rounded over probably due to a lack of normals assignments.
Terrain generator example doesn't appear to have this problem, likely because the shared edges are supposed to be blended and the outside edges have nothing to blend with, thus they remain sharp. UV mapping is accomplished via planar projection brick, which is not something that works well in my app. Want to have the UV mapping cover around the circumference of the rope and along it's length.
One of the troubles I've had with scripting is that I'm still having a hard time understanding exactly how a mesh object is structured. The table put together by Emma, along with the additional developer's guide data object descriptions is helping a bit.
Would be nice to see an example object generating script that produces a cube with fully assigned normals and UV mappings. This is slightly more than the cone script object achieves.
I could probably force hard edges if I had to by creating duplicate vertices at corners but that seems like the wrong approach to take.
Anyone got some examples?
Glen |
Post by Emma // Mar 11, 2007, 1:59pm
|
Emma
Total Posts: 344
|
Think that is similar to the problem I had with those diamonds. Look at the
thread there where tomasb gave some explanaiotns on
http://forums1.caligari.com/truespace/showthread.php?t=1628
and then some more on the next following page. Must say I didn't understand all he said there, only so much that you have to build up that normal stream similar like your vertex and edges stream. Because of the circumstances I didn't invest anymore into that, maybe I should return. Please look at above mentioned info and say if you get more from that. Player side doesn't know anymore the way from Modeler where you would selelct faceted or not with your material rather than with the normals, so for the future it would be necessary anyway to get used to mormals.
Your script is great work :banana: you are really digging deep into this |
Post by ProfessorKhaos // Mar 11, 2007, 6:14pm
|
ProfessorKhaos
Total Posts: 622
|
Thanks Emma. Based on what I've read in the other thread, this *IS* the problem (lack of normals that is...)
Shading on segments sorta resembles long elipses instead of cylinders which are the true segment shapes. This could happen easily since I'm closing the faces of each segment to mitigate obvious artifacts if the rope doubles back on itself sharply. Results in the averaging of normals over the ends of each segment, thus a rounded edge look.
Understanding cross products and normals is not outside of my engineering background but I am working with some puzzlement to understand how to actually write the code to define the normals "stream". Math of things I can visualize pretty well... mostly just transcribing engineering notes but some syntax specific or object structure areas of scripting I seem to do best by example. Been looking through your table and through the docs that came with the dev guide.
If someone were to take the time to show me how to do a simple object with UV and normals defined too (such as a cube or cylinder) I would gladly help others and it would allow me much progress on my rope object.
Rope could be used for a great many things beyond sagging cables too. It just follows a series of xyz points so the utility is greater than a single project. Could serve well in pulley systems (i.e. cranes).
I even went so far as to try and dig around inside the object primitives built into the modeller side but got to the shape defining brick only to find out that it's precompiled and thus not an example that can be used for scripts.
HELP??? NEED A WORKING EXAMPLE OF OBJECT WITH UV MAPPING AND NORMALS DEFINED PLEASE??? :jumpy:
Glen |
Post by Emma // Mar 12, 2007, 1:59pm
|
Emma
Total Posts: 344
|
Yes that was what I was also hoping for just a simple example like
a simple cube:
8 vertices
25 edges
12 faces
-take these few script lines
- end write normals
- end write normals data stream
thats all, now just implement on objects with more faces
:( but no one did give me that simple explanation, so I was figuring around with the MeshModifier stuff, but didn't get a result so far, don't even know if it is the right way
MeshModifiers.
ActivateSelectionTool( )
AddFace( str )
BuildNormalmap( str )
CancelSelectionBasedTool( )
ChangeSSLevel ( int )
ConvertSelection ( str, str )
DbgFunc1 ( )
DbgFunc2 ( )
DeleteElements ( )
DuplicateSelection ( )
EnableCrashReporting ( )
ExtrudeSelection ( )
FlipFacesNormals ( str )
GrowPointEditSelction (str )
InvertConnected ( str )
InvertSelection ( str )
MergePolygons ( str )
MeshBinaryTool ( str )
MirrorSelection ( str )
NormalSweepSelection ( str )
OutlinePointEditSelection (str )
PeDeselect ( str )
SelectConnected ( str )
ShowMeshEditSettings ( str )
ShrinkPointEditSelection ( str )
SimplifyMesh ( str )
Smoothdivide ( str )
SmoothPointEditSelection ( str )
SplitPolygons ( str )
Subdivide ( str )
TipSelection ( str )
UVMapping ( str , str )
WeldPairs ( str )
WeldSelection ( str ) |
Post by ProfessorKhaos // Mar 12, 2007, 3:11pm
|
ProfessorKhaos
Total Posts: 622
|
They are pretty busy these days with beta testing (great understatement) so I'd imagine it'd take a little time to get a few moments of their time for this.
Think what I'll try to do is create a simple cube-generating script (similar to their cone generating one) and then precalculate the normals and the UV coords. I'll see how far I can get and if I can't find the answer a cube-generator should be one of the easier scenarios for them to help me with when they do get some time.
Tomasb's posts to your thread do give me a bit more insight than I had so maybe I can work my way through or at least give me something to show them for input.
From what I understand, normals work much as vertices and triangles work. Two lists... a list of 3D vectors and a list of indices.
I'd assume the list of normals indices corresponds to the same ones in the triangles vertex list.
i.e.
given a normal list of:
normal[0] x0,y0,z0
normal[1] x1,y1,z1
normal[2] x2,y2,z2
normal[3] x3,y3,z3
normal[4] x4,y4,z4
normal[5] x5,y5,z5
.
.
normal[n] xn,yn,zn
you'd have a normals index list like the following:
triangle[0]: normal[0], normal[1], normal[2]
triangle[1]: normal[2], normal[1], normal[3]
This rougly corresponds to the vertex list as follows:
vertex[0] x0,y0,z0
vertex[1] x1,y1,z1
vertex[2] x2,y2,z2
.
.
vertex[n] xn,yn,zn
triangle[0]: vertex[0], vertex[1], vertex[2]
triangle[1]: vertex[2], vertex[1], vertex[3]
normals list wouldn't necessarily be the same size as the vertex list if the same normals or vertices were reused in different places. For instance, a cube would really only need 6 normals though each vertex in each triangle would reuse the normal at least 3 times and two triangles would both use the same normal because you're using them to form a square.
Anyway, that's my guess...script to follow... hopefully successfully. Maybe in another thread though to keep this one clean for the cable object. |
Post by ProfessorKhaos // Mar 13, 2007, 3:45pm
|
ProfessorKhaos
Total Posts: 622
|
Workin' out some of the mesh kinks in this thread...
http://forums1.caligari.com/truespace/showthread.php?t=2363
Will resume below with cable specific progress... |
|
