mtpeak2

Thanks Nancy. I'm hoping to use this in the balloon bazaar set. Right now there are no trees, so I was thinking a few groups here and there, with clearings for the balloons to land, will do.

Thanks everyone. Here's a test render with 7 instances in the chor (91 trees), rendered in 29 sec. The model has 13 trees in it, so I'm still debating how many I should put in there, 20-25? What do you think?

Here's using decaled patches. I think this works pretty well.

I don't know, I never used props.

Ok, Nancy here's the run down. I created a model with multiple trees in it. Each tree has 2 bones, 1 geometry and 1 aim target. I then add a temporary bone to setup the surface constraint. Now I created a new ON/OFF pose and constrained each tree to the temp bone and the aim targets. Closed relationship, deleted the temp bone and saved model. Then I created a terrain model (named terrain). Dropped both models in the chor. At this point nothing works. With the chor window open, I dug into the relationship folder and opened each constraint and changed the target (the drop down menu will now show the models in the chor). Resaved model with the new target. Now, all ground planes will not have the same name, but.........the "model shortcut" in the chor can be renamed to "terrain" and the constraints will work. Now that the setup works, I can dropped the forest model in the chor, translate it so the model bone is below the terrain model. then from a top view or camera view I can drag the model around to position it and the trees will follow the terrain. I can place as many instances of the forest model in the chor and the setup works. The biggest challenge now is going to be the trees. I need to come up with a low patch tree that looks good for background and medium range. Trees with hair leaves or trees with individual patch leaves is not an option. So, what's going to be the best way? Card trees? Where a tree image is decalled to a patch. This would require additional constraints for the trees to aim at a target and the target constrained to the camera. This would work just like hair, but I would be able to move them around where needed. I don't know if the render times would be better as well. The next would be low patch trees with a dome decalled with leaves. The biggest advantage with a setup like this is, you can set them inactive when not seen by the camera or repositioned to a new location so less models are needed.

I want more control than a random effect. I want to be able to scale the base model small (bringing the trees closer together), but then scale the trees larger or the other way around. This way I can adjust how close the trees are together or spread out and still have control over the overall scale of the trees. Expressions may be in the mix, but it would be controlled with a slider.

Yes.

As some of you know, I'm working on the SO sets. Adding trees to the sets are very time consuming. Creating assembly actions for each set and positioning the trees takes alot of time. Using hair to create forests, in most cases is not an option. So I needed to come up with another plan. Here I created a model with multiple trees (trees are basic at the moment). I then constrained the trees to the ground plane in the chor in a pose. Now I can drop this model (multiple times if needed) to create a forest. I can translate and rotate the base model and the trees will follow the terrain. I also have plans to add poses to scale the model and the individual trees. Here's an example of what happens when I translate an rotate the model in the chor. forest.mov

LOL, that's looks good Mark. Needs more aliens standing around watching though.

Don't raise the arms up too much. Just raise them to the point where you want the shoulder to be when the arms are down at the sides. This way you won't need to adjust the shoulder as much when you are animating, only when the arms go above his head.

All TSM2 relationships. I don't know exactly how many constraints, I deleted the "error loading string" relationships, which hold the constraints.

As Robert said, you had duplicate relationships. I went through all TSM2 relationships and deleted all the "error loading string" relationships. Here' a fixed model. Skarab_v5_TSM_Fixed.zip

Here's what I have setup. Mark_Chor.mov

Sorry Steffen, but this is what I get when rendering your project. (see attached) Robert, a translate limit is not going to help from keeping it from rotating through the ground plane. If you mean an euler limit, that probably is not going to help either. The dynamic constraint, I think, will override the limit or the limit will cause issues with the dynamics. I don't even think turning ON collision will help. I have it working with path constraints, but it's not entirely accurate. To be accurate, you will multiple paths (actually, you would need a separate path for each tire), but you could get away with just 2 paths, one for the truck and one for the trailer (the trailer will not follow in the same path as the truck when turning, it will take the shortest route to the pivot point of the trailer hitch). Steffens_Chor.mov

A dynamic constraint is not going to work, the trailer will fall through the ground plane. I'll see if I can get something working for you.

Nice lightning. You should be able to use a gradient material and animate the translation. I'll play around with it and see what I can do.

I'm sure with some weighting adjustments you could get similar results with your setup, but I still don't think you need the setup that elaborate. I sent you the test model.

I understand why you have it setup this way, but for 99% of most models this is overkill. This would require 3 to 4 (or more) spline rings per segment, too many for an A:M IMO. In most models you will have 1 maybe 2 spline rings per segment and the second spline ring will most likely be between segments and weighted accordingly anyway. I have it setup in Sam's "Right Forearm" right now and I'm getting good results. I eliminated 12 geom bones and 2 roll targets for the forearm. I weighted Sam's right forearm according to how I wanted the arm to bow. Then adjusted the twist using the sliders I setup for each segment.

You would only need to weight to one bone per segment, rather than four bones per segment. Right now you have 16 geometry bones for the forearm (4 per segment). My way would be 4 geometry bones (1 per segment). I'll setup the right forearm to show you and send it to you.

As I said, multiple twist bones for the same location is going to be difficult for the average user to weight, most won't even know they're there and won't bother. I understand why you are doing it, but I don't think it's necessary if you set the "aim roll at" constraints in a pose slider with multiple targets for each segment. Then the user can just use a pose slider to adjust the amount of roll needed to look correctly.

It's something shiny.

The neck and spine don't have to be connected...they can be if it is installed that way though. The reason I did it as separate pieces is so that the squetching would look right. If I angle the spine, it will squetch at an angle. No, that's not what I meant. You have the spine bones towards the back of the model to give you a more realistic rotation, wouldn't the same go for the neck and head? Also, I still don't see a reason for the multiple geom bones for each segment of the arms. I'll keep looking to see if I can find out why.

Ok, I've been giving Sam a once over, still looking. Here are a few things I found so far, first is the placement of the neck/head bones. If you're placing the spine towards the back of the model, I would do the same for the neck and head. I guess this is adjustable in the installation? This is more of a preference than a rig problem. Also, I would add a switch null for the head and neck FK/IK pose. I didn't notice this in the previous version, but it was there. Why are there 4 geom bones per segment and 3 geom bones per segment for the forearm and bicep (the legs don't have these)? Is this for weighting purposes? This makes weighting for the users difficult. Couldn't a pose slider be used to adjust the roll that is targeted between different targets? Then the user could just set the slider for each segment for the twisting in the user properties. The wrist doesn't seem to work that well, but I think that is a weighting issue, not a rig issue. Other than that, everything seems to work so far.

Thanks David. Well, I didn't help with this update, did a little testing here and there. Maybe I'll give the installation rig a try this weekend. I was thinking about installing all the available rigs in the JD model, so people can compare them all.

I'm going to guess...onion skinning? Looks great, Mark! No, it's not onion skinning. It's multiple instances of the same model, constrained to the main object with different lag settings and transparency set to the trailing instances. It's probably not practical for complex scenes, but it's very controllable with how many instances, how much lag between instances and the amount of transparency. With this setup, you can also pick and choose what objects get blurred. I haven't tested if this is any faster or slower than the regular MB, though. It was just a quick experiment to see if it would work.