Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
Unfortunately, our initial simulation run has revealed that we have a number of issues that need to be resolved, not least of which is the fact that our dynamic spheres are not only failing to reach their targets, but they are in fact not even being caught by, nor--it would seem--even rolling properly into our launcher tube geometry. This obviously puts seriously kink in our simulation plans, as none of the required interaction between dynamic objects can occur unless each step in the process works correctly. For this reason then, it seems sensible to start our refinement work on getting the spheres into the launcher tubes themselves.
To refresh our minds as to just what is happening at the moment, let's quickly run the simulation for a recap. As we can see, rather rolling nicely into the waiting launcher tubes, the first spheres in line simply drop straight through the holding racks themselves. If we just select one of the holding racks and make a quick inspection of the static rigid body modifier's properties, it would seem that everything is set up as it should be. In truth though, it actually isn't. The mistake we've made--albeit an honest and understandable one--is in the physical shape option we've chosen.
Because this is obviously a concave piece of geometry, we've set our physical shape option to Concave, which seems to be entirely appropriate, but it really isn't. When dealing with static rigid bodies that have concave graphical meshes the option we need to use from the dropdown list is Original, not Concave. In fact, this particular physical shape type-- Original, that is--is only available for static rigid bodies, which in itself gives us a big clue as to when it ought to be used.
If we select that option, as you can see, we have no parameters with which we need to work. Instead, MassFX simply uses our object's actual or graphical mesh to create the physical shape it will use in the simulation. Now remember, these are instanced modifies so changing this on one launcher will apply the same modification to all of them. With that change made, when the run the simulation again our spheres roll nicely off the holding racks and drop straight into to launcher tubes--well, almost. If we just hit the P key to switch to our perspective view, select our counter- top, and then again use orbit selected it to swing around to a front view, if we just reset and rerun the simulation, we could see that the launcher tubes themselves are the next issue we need to tackle, because at this moment in time they are simply letting our dynamic sphere objects pass straight through them.
The solution, you may guess, is very straightforward. As the launcher tubes, like the holding racks, are set up to be static rigid bodies, switching their physical shape over to Original ought to sort things out nicely. So, let's do that. As with the holding racks, we do only need to alter one of the modifiers here, because we are again working with instances. With the change made, let's run the simulation again, just to check that things are working as expected-- which they clearly are not.
The problem we are running into now essentially comes down to simulation accuracy or rather, a lack of it. To remedy this we can come over to the global controls found in the MassFX Tools dialog and simply increase our number of substeps. I'm going to go from 0 to a value of 1. If we run the simulation again, you can see that that's simple change now gives us a higher level of accuracy inside the simulation, which of course means that our geometry is now caught inside the launcher tubes. However, another problem we clearly need to address as we look at our simulation is the fact that our spheres are not really launching with much gusto at all.
These would never reach that target objects. To add a little punch to the launch animation let's select all of the animated discs and come down to the animation timeline. The first thing we need to do here is select a group of keyframes. Now, having made the selection, if we don't see a selection range bar, we can just right-click, go to Configure, and then Show Selection Range. Now we can just speed our timing up by scaling these keys down to around about 60% or so of their original values.
We will need to repeat this of course for each group of keyframes found on the timeline. With all of those tweaks in place, if we just take a look at the simulation now, we can see that our launchers are behaving in a much more expected manner. If we do still run into some calculation collision errors due to the fact that we have now increased the speed of our animated discs, we can simply go and increase our Substep value a little more. In fact, what I'm going to do is increase this to a value of 6, just to ensure that we don't get anymore collision calculation errors for the duration of our simulation.
Up to this point then, things are definitely shaping up slowly, but surly. However, if we just hit the C key and switch over to our main camera, running the simulation from this point of view shows that our collider objects also have a number of issues that need to be dealt with. This is what we will tackle in our next video.
Get unlimited access to all courses for just $25/month.Become a member
107 Video lessons · 34607 Viewers
94 Video lessons · 24137 Viewers
100 Video lessons · 4819 Viewers
83 Video lessons · 9741 Viewers
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.
Your file was successfully uploaded.