Carrying on the container theme I fulfilled a request for some of these...
I have now received a further request for one of these.
Decided to give it a go because its a crane, which I can't resist, but also, it gives me the opportunity to try and make it a transfer point object and animate it to actually load the train. Should be interesting. :)
Sunday, 26 February 2012
Friday, 17 February 2012
Problems with oil drums
Jim Nobbs contacted me to say there was a problem with the oil drum clutter items I had made fior Railworks, since the upgrade to TS2012 and he sent me this video to illustrate the issue.
At first I thought the problem must be with the stencil shadow, but amendments to that made no difference. Then I remembered that these were the 2nd models I had made in 3ds max, when I was struggling with the concept of kuju shaders (still struggling). When I checked, I had used TrainBumpSpec.fx which doesn't appear to be supported by TS2012, so I replaced the shader with TrainBasicObjectDiffuse.fx and that resolved the issue.
A fix has been posted on UKTS.
At first I thought the problem must be with the stencil shadow, but amendments to that made no difference. Then I remembered that these were the 2nd models I had made in 3ds max, when I was struggling with the concept of kuju shaders (still struggling). When I checked, I had used TrainBumpSpec.fx which doesn't appear to be supported by TS2012, so I replaced the shader with TrainBasicObjectDiffuse.fx and that resolved the issue.
A fix has been posted on UKTS.
Container Stacker
Continuing the container port theme I have modelled a container stacker.
Two of the models are static but I decided to animate the third one. This created a number of learning curves for myself.
Obviously, the various parts had to be linked together, so they moved as a unit. Having linked everything it was necessary to assign controllers to each link. It is possible to define what attributes an object will inherit from its parent. So, for instance, the lifthead is set to inherit movement from the extender, but not rotation. Consequently when the arm is raised the lifthead stays parallel to the ground because it doesn't inherit the rotation.
Having linked the relevant parts, their pivot points had to be moved to reflect the animation I would be applying. So, for instance the main arm is pivoted at its attachment point to the body.
The problems started with the cylinder and piston. They need to move and rotate, but they don't rotate by as many degrees as the arm. This is resolved by the magic animation command the look at constraint. I have added one to the cylinders which means they always point towards the pivot point of the pistons. It was necessary to have the opposite situation, where the piston look at the cylinder pivot point, but this is illogical in computer terms, however, I got round it by placing a dummy at the cylinder pivot point and getting the pistons to look at the dummy.
So now, when the arm is rotated, the cylinders and pistons remain in line with each other, as shown below. [The thin blue lines are the look at constraints]
Having got the moving parts linked and constrained, it was time to animate which was comparatively straight forward, until I ran the resulting video. Nothing seemed to work properly and it took me a couple of days to realise my errors. Firstly, how did I get the container to follow the lifthead for some of the time and not at others? This is resolved by yet another constraint called, not unsurprisingly, the link constraint which allows you to specify what an object is linked to and for how many frames of animation. So, in the case of the container it is linked to the lifthead between frames 85 and 166.
Secodnly, when you move something in 3ds max animation autokey mode it assumes that the movement should be extrapolated back to the previous key for that object, not, as I thought, to the previous key for any object! For instance, if I move the body then rotate the arm, the body ignores the key set for the arm movement and behaves as if that key didn't exist. The issue was resolved by changing to set key mode where I can set an animation key exactly when and where I want to.
The resulting animation looked like this...
...or, to be precise, it looked like the first half of the video. I then decided it would be best if the video looped round, so after a bit of a web search I came across the 3ds max dope sheet. This allowed me to copy the animation, reverse it, then add it back to the end of the original. So now I had a complete looping video.
In the end it took longer to battle my way through the intricacies of linking/constraints/animation than it did to build the model, but I have added to my knowledge base and, hopefully, passed some of it on through this blog.
Two of the models are static but I decided to animate the third one. This created a number of learning curves for myself.
Obviously, the various parts had to be linked together, so they moved as a unit. Having linked everything it was necessary to assign controllers to each link. It is possible to define what attributes an object will inherit from its parent. So, for instance, the lifthead is set to inherit movement from the extender, but not rotation. Consequently when the arm is raised the lifthead stays parallel to the ground because it doesn't inherit the rotation.
Having linked the relevant parts, their pivot points had to be moved to reflect the animation I would be applying. So, for instance the main arm is pivoted at its attachment point to the body.
The problems started with the cylinder and piston. They need to move and rotate, but they don't rotate by as many degrees as the arm. This is resolved by the magic animation command the look at constraint. I have added one to the cylinders which means they always point towards the pivot point of the pistons. It was necessary to have the opposite situation, where the piston look at the cylinder pivot point, but this is illogical in computer terms, however, I got round it by placing a dummy at the cylinder pivot point and getting the pistons to look at the dummy.
So now, when the arm is rotated, the cylinders and pistons remain in line with each other, as shown below. [The thin blue lines are the look at constraints]
Having got the moving parts linked and constrained, it was time to animate which was comparatively straight forward, until I ran the resulting video. Nothing seemed to work properly and it took me a couple of days to realise my errors. Firstly, how did I get the container to follow the lifthead for some of the time and not at others? This is resolved by yet another constraint called, not unsurprisingly, the link constraint which allows you to specify what an object is linked to and for how many frames of animation. So, in the case of the container it is linked to the lifthead between frames 85 and 166.
Secodnly, when you move something in 3ds max animation autokey mode it assumes that the movement should be extrapolated back to the previous key for that object, not, as I thought, to the previous key for any object! For instance, if I move the body then rotate the arm, the body ignores the key set for the arm movement and behaves as if that key didn't exist. The issue was resolved by changing to set key mode where I can set an animation key exactly when and where I want to.
The resulting animation looked like this...
...or, to be precise, it looked like the first half of the video. I then decided it would be best if the video looped round, so after a bit of a web search I came across the 3ds max dope sheet. This allowed me to copy the animation, reverse it, then add it back to the end of the original. So now I had a complete looping video.
In the end it took longer to battle my way through the intricacies of linking/constraints/animation than it did to build the model, but I have added to my knowledge base and, hopefully, passed some of it on through this blog.
Saturday, 11 February 2012
Straddle Carrier
Those of you who follow my blog will know I can't resist a crane and I was recently tempted by a form of mobile crane - the straddle carrier.
As some interest was shown on UKTS for such a model I went ahead and created the following. The set is comprised of an empty carrier and 4 others carrying 20ft or 40ft containers in a choice of positions (low or high)
They generally appear in high viz yellow. but red and blue variants are also common, so I made the base texture a simple one colour diffuse, so users can quickly change the model to their colour of choice.
As some interest was shown on UKTS for such a model I went ahead and created the following. The set is comprised of an empty carrier and 4 others carrying 20ft or 40ft containers in a choice of positions (low or high)
They generally appear in high viz yellow. but red and blue variants are also common, so I made the base texture a simple one colour diffuse, so users can quickly change the model to their colour of choice.
Wednesday, 1 February 2012
Subscribe to:
Posts (Atom)