Available for Immediate Download - RSMeshTexTools
Download Here
I've been working on a plugin that extends RhinoScript to allow for access to an object's render mesh without having to go through the hassle of adding the render mesh directly to Rhino. You can retrieve the vertices, faces, normals, texture coordinates, etc from the rendermesh directly from the parent object and then work with the resulting "virtual" mesh as a list of faces and vertices.
Another part of this plugin is querying texture coordinates for any point on the object as opposed to being limited to only having texture information for the vertices of a mesh. This really opens up the possibilities for using the existing texture coordinates of an object, along with textures, to drive parameters from within scripts.
This plugin is specifically for scripters, not for end users, as this plugin does not add any functionality or commands to Rhino. Scripters, feel free to distribute this plugin along side your scripts. You can also use the accompanying functions that are included with the plugin within your scripts, provided that credit is still given.
Please check out the RSMeshTexTools page on the McNeel wiki for further information (should be up in just a bit), or download the zip file and go throught the ReadMe and MethodReference files. If you have any requests, comments, or issues with the plugin, feel free to comment here or post on the Rhino newsgroup and I'll get back to you. I'll try to get one or two practical examples of using this together in the next few days, so keep your eyes peeled for those. I'd also like to thank Jarek Bieda and Clement Greiner for there inspiration on putting this project together, along with their feedback and testing.
October 16, 2009
July 6, 2009
RhinoHair Alpha 0.1.2 Released
Here's another update for RhinoHair. There are a few things in this build that I'm glad to get resolved, so this should be pretty solid as it stands right now. The biggest thing is that hairs being generated with opposite normals is now fixed. So now all the hair strands will match the normals that show up when you run the Dir command in Rhino. The other two things that are cleared up are the mesh strands all being one object, and the mesh normals. These issues are both worked out now, so this should make it easier to deal with the mesh once its added into Rhino.
The next stage is going to be remembering all of the stuff about the hair objects...parameters, points, strands, meshes...so that there will be easier access to this between running commands. This should make adjustments and changes much easier, and make the overall process a little quicker as well since things won't be getting calculated over and over.
I did start to play around with it a little bit more myself. I figured it would be a good idea to create a little bit of a logo first, so that's what I did :). At the top of the post is the head on version, and there's a stacked, hi-res version of the logo at the end there. The detail you can get with the hair is quite nice, and pretty hard to replicate through other means (displacement, etc).
There were a few questions that I asked last time that didn't really get much response, so I'll ask them again. Your feedback would be much appreciated.
+ Is there any desire to have alternate/additional outputs, ie. Points or Polylines, in addition to the meshes?
+ Would you like control over the gravity vector? If so, how would you prefer to input that information?
+ How important is capping the mesh strands (for RP purposes I assume)?
Download
Installation
If you've never installed RhinoHair before, just unzip to a location on your computer where you won't go moving it around (the Rhino Plugins directory is a pretty good place), then Drag and Drop over a running instance of Rhino. If you have previously installed, just replace the old RHP file.
The little SR mix-up is straightened out now, so it will work with SR4b of Rhino. If anyone needs it working on a earlier SR, please let me know. Sorry for the inconvenience. Same download link as before.
June 28, 2009
RhinoHair Alpha 0.1.1 Released
Been making some more additions to Rhino Hair over the last week or so. Here's a quick run down of the new things in this build.
+ Sticky Settings - They will be remembered within the current Rhino session
+ Multiple Bend Types - There are now 3 different models for bending due to gravity; Constant, Times2, and Power2. Times2 is the default and was the type previously implemented
+ Length Variation
+ Width Variation
+ Tapering
The next thing I'm working on is getting the hair points (+strands and meshes) to be remembered from object to object. This should make editing things like strand width, tapering, adding more strands, and things like that much easier and faster since it won't require regenerating everything from scratch. After that retrieving the texture coordinates for the will probably be the next hurdle.
I looked into what it would take to be able to ESC to get out of a process, and at the moment its something that's over my head. Once I get a few more things done I'll get back on it.
Now for some known issues...
+ Some surfaces within polysurfaces may have hairs generated on the "opposite" normal...I still have to look into what is causing this
+ There was some reported twisting with some mesh strands. This appears to be due to how I'm generating the plane at that point. Some more research into this is needed
+ All of the mesh strands are still individual objects. Creating the mesh as one object will likely be in the next release
+ Normals are pointing inwards on the strand. This will likely be fixed in the next release
Lastly, a few questions for anyone out there who cares to chime in...
+ Is there any desire to have alternate/additional outputs, ie. Points or Polylines, in addition to the meshes?
+ Would you like control over the gravity vector? If so, how would you prefer to input that information?
+ How important is capping the mesh strands (for RP purposes I assume)?
Thanks to all who've shown an interest in the plug-in so far. Keep the comments and suggestions coming, and if you come across any issues please let me know.
Download Here
Installation
If did not install the previous version, then you shouldn't have an issue installing this plug-in as you would any other (drag and drop, plug-in manager). If you did have the previous version installed, just make sure to replace the previous RHP file with this one.
+ Sticky Settings - They will be remembered within the current Rhino session
+ Multiple Bend Types - There are now 3 different models for bending due to gravity; Constant, Times2, and Power2. Times2 is the default and was the type previously implemented
+ Length Variation
+ Width Variation
+ Tapering
The next thing I'm working on is getting the hair points (+strands and meshes) to be remembered from object to object. This should make editing things like strand width, tapering, adding more strands, and things like that much easier and faster since it won't require regenerating everything from scratch. After that retrieving the texture coordinates for the will probably be the next hurdle.
I looked into what it would take to be able to ESC to get out of a process, and at the moment its something that's over my head. Once I get a few more things done I'll get back on it.
Now for some known issues...
+ Some surfaces within polysurfaces may have hairs generated on the "opposite" normal...I still have to look into what is causing this
+ There was some reported twisting with some mesh strands. This appears to be due to how I'm generating the plane at that point. Some more research into this is needed
+ All of the mesh strands are still individual objects. Creating the mesh as one object will likely be in the next release
+ Normals are pointing inwards on the strand. This will likely be fixed in the next release
Lastly, a few questions for anyone out there who cares to chime in...
+ Is there any desire to have alternate/additional outputs, ie. Points or Polylines, in addition to the meshes?
+ Would you like control over the gravity vector? If so, how would you prefer to input that information?
+ How important is capping the mesh strands (for RP purposes I assume)?
Thanks to all who've shown an interest in the plug-in so far. Keep the comments and suggestions coming, and if you come across any issues please let me know.
Download Here
Installation
If did not install the previous version, then you shouldn't have an issue installing this plug-in as you would any other (drag and drop, plug-in manager). If you did have the previous version installed, just make sure to replace the previous RHP file with this one.
June 10, 2009
Rhino Hair 0.1.0 - First Public Alpha Released
Now available for download, the first public alpha of RhinoHair, a hair solution for Rhino. Please note that this is an alpha version of the software and users do so at their own risk. The software is no where near complete, yet the features currently available should be helpful for many users. Release notes are contained within the zip file, and it is highly recommended that you read over them before installing an using the software.
Installation
The zip file contains the two files, the release notes and the Rhino Plug-in file. The plug-in can be installed through the Rhino Plug-In manager or, after placing the file in a static location, the plug-in can be dragged and dropped on to a running instance of Rhino.
Usage
The plugin exposes one command, RhinoHair. After selecting either a surface or polysurface, you will prompted for strand parameters including number of hair strands, number of segments, gravity, and normal variation. After that there is one last propt for details about the mesh creation including the width of the strand and the number of sides used to construct the mesh. The plug-in then goes through the process of generating base points, strands, and then the meshes, with the meshes being added to Rhino.
Feedback
Any response to the plugin is encouraged. Feel free to attach any commen.ts to this post or start a thread at the Rhino newsgroup.
Download Here
Installation
The zip file contains the two files, the release notes and the Rhino Plug-in file. The plug-in can be installed through the Rhino Plug-In manager or, after placing the file in a static location, the plug-in can be dragged and dropped on to a running instance of Rhino.
Usage
The plugin exposes one command, RhinoHair. After selecting either a surface or polysurface, you will prompted for strand parameters including number of hair strands, number of segments, gravity, and normal variation. After that there is one last propt for details about the mesh creation including the width of the strand and the number of sides used to construct the mesh. The plug-in then goes through the process of generating base points, strands, and then the meshes, with the meshes being added to Rhino.
Feedback
Any response to the plugin is encouraged. Feel free to attach any commen.ts to this post or start a thread at the Rhino newsgroup.
Download Here
June 9, 2009
Alpha version of Hair to be released later this week
Over the last few weeks I've been cranking away with getting Hair working as a plug-in for Rhino. It was a little rough getting started (this is my first full blown plug-in with VB.Net and first venture into OOP design), but after a few bumps in the road and some computer trouble things are are looking up. Below is an example from the plug-in. I know it doesn't look much different from the previous images, but the strands are now actually much different than they were before. In some conversations that I had with some interested users they expressed to need to have a view independent solution for the hair rather than the flat, view dependent solution that I was using before. The plug-in also runs much faster than the scripted version, with about 2000 hair strands (meshes and all) being generated in about a minute.
As the title says, I'll be releasing an alpha version of hair later this week, hopefully tomorrow. I just have to get some of the parameters exposed so that they can be set by a user (right now they're all hard coded). The version's going to be a little bit "bland" as there are still some features that I've yet to get to implementing. At this point, I figured I would let any one interested begin to work with it as I get some of those features working. For the time being its just going to be a command line tool, but I would like to move it to having a dialog box and a better interface for making changes.
As the title says, I'll be releasing an alpha version of hair later this week, hopefully tomorrow. I just have to get some of the parameters exposed so that they can be set by a user (right now they're all hard coded). The version's going to be a little bit "bland" as there are still some features that I've yet to get to implementing. At this point, I figured I would let any one interested begin to work with it as I get some of those features working. For the time being its just going to be a command line tool, but I would like to move it to having a dialog box and a better interface for making changes.
May 12, 2009
Its Been a While
I know its been a little while since I've posted anything, so I wanted to let you all know what I've been up to. Over the last month or so I've been busy helping a friend out with an animation for her thesis, which came out very well (I'm still waiting on her approval to show it and put up a post about it). Although it was quite a lot of work, I got a chance to do some 3D painting, which I had yet to find time to do. It was a lot of fun, and I finally got a chance to put my tablet to work. The project was mostly done in 3dsMax, but the painting was done in Modo. This was the first time that I had worked with Modo, and I must say that it is a very nice application. I was quite surprised with how capable it is and how easy it is to work with. If there are standard CG/Polymodeling/SDS parts to your workflow, I would very much recommend taking Modo for a spin.
Anyway, during the last month or two I've had a number of conversations over on the Rhino newsgroup about some rendering specific tools that are much needed for Rhino. So, I'm actually going to move towards actually developing a few small pieces of software to fill a few those voids. You guys have seen the cloth experiments that I've been working on here, so this will be one of the tools that I plan on developing. The other one, which I'm actually going to be working on first, is a hair generator. I actually started work on this over the summer, but it kind of fell by the way side. At this point I don't have any specific time tables for releasing either one of these two plugins, but as I do more work on them, I'll have more of an idea. Hopefully I'll be able to get at least an initial version of the hair plugin going in about a week, but we'll see.
Here's an example of the result of the hair script as it was during the summer and a screen cap of some initial prototyping in VB.Net.
Anyway, during the last month or two I've had a number of conversations over on the Rhino newsgroup about some rendering specific tools that are much needed for Rhino. So, I'm actually going to move towards actually developing a few small pieces of software to fill a few those voids. You guys have seen the cloth experiments that I've been working on here, so this will be one of the tools that I plan on developing. The other one, which I'm actually going to be working on first, is a hair generator. I actually started work on this over the summer, but it kind of fell by the way side. At this point I don't have any specific time tables for releasing either one of these two plugins, but as I do more work on them, I'll have more of an idea. Hopefully I'll be able to get at least an initial version of the hair plugin going in about a week, but we'll see.
Here's an example of the result of the hair script as it was during the summer and a screen cap of some initial prototyping in VB.Net.
March 26, 2009
Cloth Systems - Relaxation
So one of the interesting things about a cloth system is that it can be adjusted to achieve surface relaxations. In fact, there really wasn't very much modification to scripts at all. In the case of the normal cloth simulations, the force of a given spring was proportional to the difference between its original length and its current length. The relaxation doesn't take into account the original length of the spring, and instead, the its force is solely derived from its current length. Although I could have left the gravitational forces in for the simulation, I choose to remove them so that the result is based just on the surface.
The thing that I find most interesting about these relaxations is that because of the support for object intersections that was added to the cloth simulation, the relaxations can actually take into account other objects. This leads to some interesting opportunities for relaxation and form.
The thing that I find most interesting about these relaxations is that because of the support for object intersections that was added to the cloth simulation, the relaxations can actually take into account other objects. This leads to some interesting opportunities for relaxation and form.
March 15, 2009
Cloth Systems - The Next Iteration
Well, I've added a number of features and made a load of changes to the script, and I like how is coming along. There were 3 things left over from the previous experiments that I took on first - cloth mass, per-node weighting, and motion retention. All of those have made the the simulations much more "predictable" and a more natural simulation. With the cloth mass and per-node weighting the simulation will now achieve similar results for meshes that are the "same", but just at different resolutions. So that means I can test a simulation with a coarse mesh, then run a nice one with a fine mesh.
The motion retention is the really cool one as the elastic cloth can actually bounce, swing back and forth, and other "natural" movements. When I first added the motion retention I didn't have any sort of decay on the motion that was retained. So this lead to some pretty interesting results including the cloth bouncing around for quite a while. I added some decay, which can account for air resistance or something to that effect, and now the results are much more natural.
The biggest thing that I added though was collisions. This was definitely a very involved aspect of this current set of scripts and took quite a bit of time. There are actually 4 different kinds of intersections that are used within the script; two approximation methods and two exact methods. The first two approximation methods are really for speed, since I didn't want to use Rhino's intersector for every single test. If I had done that, the simulations would have progressed at a snails pace. One of them is a bounding box test which checks and sees if either of the two points used for a given iteration (the place where the node currently is and where its going to be next) are within the bounding box of the test object. This actually worked very well for objects that had a full bounding box (like a sphere), but for flat surfaces this did not work well at all. So the second approximation test was a line-plane intersection test which got around that problem.
The two exact methods are for NURBS surfaces and meshes, but both work in almost exactly the same way. So after a node has been determined as within the bounding box or intersecting a plane, the intersection then gets handed off to one of these two methods depending on the type of object its colliding with. The intersection right now is fairly simple, and looks to see where the node would hit the object, then adjusts it based on the plane at the point of intersection. Although for the first round, this is working quite well, there's still some more tweaking that has to be done. At this point there isn't any notion of "sliding" on the surface or any friction with the surface. I'd like to add this kind of interaction, but I'll have to scratch my head for a little while to come up with some sort of means of achieving it. Also, I believe that other cloth sims have a notion of being slightly offset from the original surface, which prevents the cloth from overlapping the collision objects in a weird way. This is something I may want to look into.
The last thing, which I have done absolutely no work on, is the cloth interacting with itself. This is definitely going to be the toughest thing to work out, and again, its going to take a lot of head scratching on my part. I think I'm happy where things are at the moment and may take some time to just play around with the simulations as they are and come up with something that actually uses these scripts. Besides, my head hurts a little after putting these together :)
The motion retention is the really cool one as the elastic cloth can actually bounce, swing back and forth, and other "natural" movements. When I first added the motion retention I didn't have any sort of decay on the motion that was retained. So this lead to some pretty interesting results including the cloth bouncing around for quite a while. I added some decay, which can account for air resistance or something to that effect, and now the results are much more natural.
The biggest thing that I added though was collisions. This was definitely a very involved aspect of this current set of scripts and took quite a bit of time. There are actually 4 different kinds of intersections that are used within the script; two approximation methods and two exact methods. The first two approximation methods are really for speed, since I didn't want to use Rhino's intersector for every single test. If I had done that, the simulations would have progressed at a snails pace. One of them is a bounding box test which checks and sees if either of the two points used for a given iteration (the place where the node currently is and where its going to be next) are within the bounding box of the test object. This actually worked very well for objects that had a full bounding box (like a sphere), but for flat surfaces this did not work well at all. So the second approximation test was a line-plane intersection test which got around that problem.
The two exact methods are for NURBS surfaces and meshes, but both work in almost exactly the same way. So after a node has been determined as within the bounding box or intersecting a plane, the intersection then gets handed off to one of these two methods depending on the type of object its colliding with. The intersection right now is fairly simple, and looks to see where the node would hit the object, then adjusts it based on the plane at the point of intersection. Although for the first round, this is working quite well, there's still some more tweaking that has to be done. At this point there isn't any notion of "sliding" on the surface or any friction with the surface. I'd like to add this kind of interaction, but I'll have to scratch my head for a little while to come up with some sort of means of achieving it. Also, I believe that other cloth sims have a notion of being slightly offset from the original surface, which prevents the cloth from overlapping the collision objects in a weird way. This is something I may want to look into.
The last thing, which I have done absolutely no work on, is the cloth interacting with itself. This is definitely going to be the toughest thing to work out, and again, its going to take a lot of head scratching on my part. I think I'm happy where things are at the moment and may take some time to just play around with the simulations as they are and come up with something that actually uses these scripts. Besides, my head hurts a little after putting these together :)
February 27, 2009
Cloth Systems - First Cloth Experiments
After putting together some basic experiments to get familiar with springs physics the goal was now to get this all working on a peice of "cloth". Although the basic concepts of springs remain the same, there are some new challenges when it comes to implementing it as cloth. At this point, we're trying just to get back to square one with cloth, so rather than addressing some of the observations from those experiments now, I'm just going to get the engine turned over...then we can begin to tune it.
Challenges with cloth
In the previous experiments the topology, or the organization/structure of the geometry itself, was consistent and was also very simple. There was some flexibility with the catenary chains, but cloth is really a whole different story. Now we're faced with nodes that are much more dynamic (there may be anywhere from 2 to n springs connected to a given node) and we also must uncover the connections between each node ourself...its not going to jump out at us.
Unconvering the connections was the first issue tackled and was more about sorting through face verticies of the mesh to find out where those connections actually were. Dealing with the dynamic number of connections was more in how the code was structured than anything else, so two down...how many more to go?
In order of a cloth simulation to actually do anything, there has to be some nodes must be acted on by a different set of forces than the others. with out that our cloth just falls? This means one or more of three different things; certain nodes are fixed (therefore allowing no force to interact with it), nodes are allowed to interact with other objects (mostly these are physical geometry, but could include another force like wind), or nodes are allowed to interact with the geometry of the cloth itself (ie worry about self intersecting conditions). These are also ordered in complexity from easiest to hardest, so since at this point I'm just worried about getting this balloon off the ground, we're fixin' some nodes. Luckily this one is merely a boolean value that's stored per node...if true we can move it, it not, then its stayin' where it is.
Cloth Sim Tests
To be honest, I was kinda surprised when the first scripts actually ran, because they actually ran so smoothly. At this point, they're quite primitive as far as cloth sims go, but they are starting to show some promise. From here, its more about making this sing...right now they are at a caveman grunt.
Another observation
I know I haven't actually rolled the observations of my basic experiments into the simulation yet, but these simulations generated another observation which I think will be another key factor. Right now the way the simulation is structured each iteration is static. What that means is that there is no motion retention from the previous iteration. I've actually made this stumble in the past with some gravity simulations that I created (heavenly bodys type gravity), and considering the changes that it made within those simulations it will make a huge difference to the simulations here as well.
Next Step
From here I think there's some "clean up" that's necessary. At this point, I think its important to address some of the observations that I've had about these different experiments. After implementing those, I think that the next thing will be figuring out interactions with other objects. I'd also like to try and incorporate some friction into those interactions as well, but we'll see how that goes.
Challenges with cloth
In the previous experiments the topology, or the organization/structure of the geometry itself, was consistent and was also very simple. There was some flexibility with the catenary chains, but cloth is really a whole different story. Now we're faced with nodes that are much more dynamic (there may be anywhere from 2 to n springs connected to a given node) and we also must uncover the connections between each node ourself...its not going to jump out at us.
Unconvering the connections was the first issue tackled and was more about sorting through face verticies of the mesh to find out where those connections actually were. Dealing with the dynamic number of connections was more in how the code was structured than anything else, so two down...how many more to go?
In order of a cloth simulation to actually do anything, there has to be some nodes must be acted on by a different set of forces than the others. with out that our cloth just falls? This means one or more of three different things; certain nodes are fixed (therefore allowing no force to interact with it), nodes are allowed to interact with other objects (mostly these are physical geometry, but could include another force like wind), or nodes are allowed to interact with the geometry of the cloth itself (ie worry about self intersecting conditions). These are also ordered in complexity from easiest to hardest, so since at this point I'm just worried about getting this balloon off the ground, we're fixin' some nodes. Luckily this one is merely a boolean value that's stored per node...if true we can move it, it not, then its stayin' where it is.
Cloth Sim Tests
To be honest, I was kinda surprised when the first scripts actually ran, because they actually ran so smoothly. At this point, they're quite primitive as far as cloth sims go, but they are starting to show some promise. From here, its more about making this sing...right now they are at a caveman grunt.
Another observation
I know I haven't actually rolled the observations of my basic experiments into the simulation yet, but these simulations generated another observation which I think will be another key factor. Right now the way the simulation is structured each iteration is static. What that means is that there is no motion retention from the previous iteration. I've actually made this stumble in the past with some gravity simulations that I created (heavenly bodys type gravity), and considering the changes that it made within those simulations it will make a huge difference to the simulations here as well.
Next Step
From here I think there's some "clean up" that's necessary. At this point, I think its important to address some of the observations that I've had about these different experiments. After implementing those, I think that the next thing will be figuring out interactions with other objects. I'd also like to try and incorporate some friction into those interactions as well, but we'll see how that goes.
Cloth Systems - Basic Springs
This is actually a project that I had going a while back, but just picked back up. We've all seen those super cool cloth simulations that create such a realistic result. Well, there's a lot of really advanced stuff going on within these simulations, but at their heart they rely on spring physics. Rather than thinking of these systems as simulating an infinitely smooth surface, think of them as a series of nodes that are connected by springs. These springs each exert their own force on that node and through a series of iterations you can simulate the motion of surface as a whole.
Springs 101
Springs are actually a pretty basic structure....Here's the formula (sorry for the math :)
F = k*d
k is the coefficient of the spring which is basically a multiplier. d is the distance the spring has either been compressed or stretched. Therefore, when the spring is at its relaxed state it exerts no force and the more we change the springs length the more force it will exert. For our purposes we just need to keep track of the original distance and the current distance.
Experiment 01 - Two Springs Pushing Back on Each Other
The first experiment was just to get more familiar with Springs and to get the iteration part down. This experiment started out with a rather simple situation...two springs that pushed back on each other to reach equilibrium. After specifying the two end point, a point in between those points is specified that is an initial condition. Then a spring coefficient is specified for each spring. Iterate through that until the forces equal each other out.
Experiment 02 - Catenary Chain
For the second experiment I wanted to move something that required more complex iteration and included an outside force (gravity in this case), yet still was simple enough to understand aspects of the simulation. So I choose to simulate a catenary chain with a theoretical spring in between each vertex of a polyline.
Observations
There were several discoveries that came out of this experiment that I'm not sure is a normal outcome or idiosyncratic to my implementation. The first one was the extent to which calculating the influence of gravity affected the solution. I guess this is pretty straight forward, but it took a number of different tries to actually come up with a proper factor for gravitational influence on the system. Too much and the chain sags like an old lady at a nursing home...too little and the chain looks too flat. Since there's no real mass within a curve it allowed for enough room for testing these different values. Note to self: Find a way to dictate an actual mass
The second discovery that came up was that the number of divisions of the curves influenced how "deep" the solution. Since the calculation of all of the forces was being calculated per node, with more nodes, there was more of a potential influence on gravity. Looking at these two issues together it appears that not only must there be a way to derive a particular mass, and therefore a specific force of gravity, but also divide that force among the different nodes so that they are only affected by the amount of mass that they actually influence.
I guess in some of these initial experiments there just wasn't enough "real world factors" in the calculations. Since these were just to "get my feet wet", I'm not too worried about them. I will however keep these in mind for the next step...which is an actual cloth :)
Lastly, there's also a few issues with springs getting "out of hand". Basically during the course of the iterations, the spring gets stretched in an unbalanced way, and its force starts to throw off the rest of the iterations. As that force pulls the spring back on the next iteration, the other spring attached to the node has no option but to counter balance this with its own force. The "back and forth" begins to grow and eventually this throws the simulation into a state of extreme noise. I'm not 100% sure how to counter act this (I'll have to do more research), but its probably going to involve clamping the force vectors to a maximum value and/or dampening the forces themselves to prevent getting out of balance in the first place. At the moment though, this only appears to be an issue with stiffer spring coefficients, so I'm going to put this on the back burner until there's more developed and other issues are ironed out. Lets just pretend I didn't say anything about this ;)
Springs 101
Springs are actually a pretty basic structure....Here's the formula (sorry for the math :)
F = k*d
k is the coefficient of the spring which is basically a multiplier. d is the distance the spring has either been compressed or stretched. Therefore, when the spring is at its relaxed state it exerts no force and the more we change the springs length the more force it will exert. For our purposes we just need to keep track of the original distance and the current distance.
Experiment 01 - Two Springs Pushing Back on Each Other
The first experiment was just to get more familiar with Springs and to get the iteration part down. This experiment started out with a rather simple situation...two springs that pushed back on each other to reach equilibrium. After specifying the two end point, a point in between those points is specified that is an initial condition. Then a spring coefficient is specified for each spring. Iterate through that until the forces equal each other out.
Experiment 02 - Catenary Chain
For the second experiment I wanted to move something that required more complex iteration and included an outside force (gravity in this case), yet still was simple enough to understand aspects of the simulation. So I choose to simulate a catenary chain with a theoretical spring in between each vertex of a polyline.
Observations
There were several discoveries that came out of this experiment that I'm not sure is a normal outcome or idiosyncratic to my implementation. The first one was the extent to which calculating the influence of gravity affected the solution. I guess this is pretty straight forward, but it took a number of different tries to actually come up with a proper factor for gravitational influence on the system. Too much and the chain sags like an old lady at a nursing home...too little and the chain looks too flat. Since there's no real mass within a curve it allowed for enough room for testing these different values. Note to self: Find a way to dictate an actual mass
The second discovery that came up was that the number of divisions of the curves influenced how "deep" the solution. Since the calculation of all of the forces was being calculated per node, with more nodes, there was more of a potential influence on gravity. Looking at these two issues together it appears that not only must there be a way to derive a particular mass, and therefore a specific force of gravity, but also divide that force among the different nodes so that they are only affected by the amount of mass that they actually influence.
I guess in some of these initial experiments there just wasn't enough "real world factors" in the calculations. Since these were just to "get my feet wet", I'm not too worried about them. I will however keep these in mind for the next step...which is an actual cloth :)
Lastly, there's also a few issues with springs getting "out of hand". Basically during the course of the iterations, the spring gets stretched in an unbalanced way, and its force starts to throw off the rest of the iterations. As that force pulls the spring back on the next iteration, the other spring attached to the node has no option but to counter balance this with its own force. The "back and forth" begins to grow and eventually this throws the simulation into a state of extreme noise. I'm not 100% sure how to counter act this (I'll have to do more research), but its probably going to involve clamping the force vectors to a maximum value and/or dampening the forces themselves to prevent getting out of balance in the first place. At the moment though, this only appears to be an issue with stiffer spring coefficients, so I'm going to put this on the back burner until there's more developed and other issues are ironed out. Lets just pretend I didn't say anything about this ;)
Subscribe to:
Posts (Atom)
