Macser

And you have access to the same resources as Al. Namely the A2 sample files. Just find something you like in those and apply what you see in the video. The mesh layout is fairly consistent between A2 characters, because they have to suit the default animation sets. :)

Aah. Yes. That would normalise the weights to 1. As in a hard surface mesh where you don't want blends between weights. :)

This isn't meant to sound cranky, but if there's one thing that drives people crazy it's seeing an apparently resolved problem with absolutely no explanation. It doesn't matter whether you think the answer was incredibly simple or a mistake on your part. Consider posting what you did to sort the issue so the thread has a definite resolution, and doesn't leave a new member wondering if they're missing something important. :)

Yeah. That's exactly how my rig was done. Using the sample character unedited. The weights used for the rig are from the mesh itself. The existing vertex groups are simply assigned to the appropriate bones in the rig. Rather than binding the mesh to the armature by bone heat or envelopes. I created my rig to accommodate the toolbox. But other than that, there's no connection between them. Any model or rig, properly set up, will work with it. Al's video goes through the process of making the adjustments for a ported asset. An alternative is to just import the res lods for your A2 mesh into the Armarig blend file and put an armature modifier on it. This should work fine for the res lods. And will give you an automatic way of testing the mesh deformation on the parts you need. From there you can sort out any "clipping" as Al does in the video. And also make any necessary changes to the weights.

Thanks for the mirror JDB. Much appreciated. :)

It's optional. But it's still a good idea The ofpec tag page is a handy way to check if someone else has registered a similar choice to yours. A tag gives you a simple identifier for your work. It also helps prevent conflicts where authors have named some of their classes the same. Which has happened from time to time. :) Looks like the tag system is having issues. If you're actively modding, it's still a good idea to have one though.

It's always great to see more projects that wander off the beaten track. :)

There may have been some changes to the exe when the newer tools arrived on the scene. I'm still using the older versions. I don't bother with it either unless I get the odd edge that's not turned correctly. But that doesn't happen very often. Maybe it was just to facilitate the edge split mod to begin with. And they just kept it in there. It certainly would be more intuitive to mark sharp edges on a smooth shaded model and have them display regardless. Although It doesn't bother me too much now as I'm used to it, it's a valid point. :)

In case anyone else is reading this and wondering, autosmooth can replace the edge split modifier. But if you mark edges without it on, and you don't use an edge split modifier, your sharp edges won't display in the viewport. Essentially,setting the angle to 180 tells blender you want the object smooth shaded, except where you have defined sharp edges. One of the first things I do with any mesh is set autosmooth on and specify an angle of 180. I also remove any existing edge split modifiers. Which will appear when you import a P3d with the toolbox. The exporter will process the sharpened edges without the need for an edge split modifier.

There's a really good resemblance to the original. Excellent job. I always loved Ghost recon 1, and still break it out now and then. :)

The normals I always have to recalculate. But I don't have any issues with sharp/smooth edges. I get what I see in the viewport. The importer adds an edge split modifier to P3ds. So that might interfere with edges if you also switch on autosmooth while you work. I don't know. Since autosmooth was added, I've stopped using the edge split modifier, and remove it from anything I'm working on. So all I have in the mesh are the edges marked as sharp, and autosmooth on and set to 180 degrees. This works reliably for me. As for triangulation. The only way to be sure, is to triangulate the mesh before you export with CTRL-T in edit mode. That's the only reliable way to do it. The triangulate modifier would be really handy here, for a non-destructive process. But that modifier and others aren't applied by the toolbox on export. I'm not a coder by any means but I assume the target format would need some support for certain modifiers to be applied by an exporter. :)

Actually the titan cockpit turned out a bit brighter than I intended. But I wanted to get something ready. It was sitting on the shelf long enough. :)

It's getting fairly consistent. I imagine it's quite a pain in the arse to manage the forums and keep the cockroaches out though. You can literally follow when the bots get in, rack up replies, and then start generating new threads. I'm not the one trying to keep up with the little buggers though.

That'd be in an ideal situation though. Unfortunately it doesn't always work out that way. @Morthon I think getting them working to a functional level is the thing to aim for. There's always a possibility that scenarios can be created, with assets to suit, later on down the road. But you need something to work with first. :)

Script command "animchanged". It was added as an experiment to remove the demo pack from a unit model when a charge was placed without having to use scripting. The command is only available in 1.99. That could be removed easily enough.

Looks great so far. The material gives it new lease of life. If you're trying to unwrap using smart projection it's going to break it up. The best results will come from manually placed seams and then using the standard LSCM unwrap from there. Smart projection has it's uses. But I've found it's not always the best choice for a complex mesh. If you need any help with that side of things, I could offer some assistance.

I wouldn't say it was that good, considering a lot of the stuff I did is only partially finished. Spad had to compensate for that by making a lot of edits. So it wouldn't be even released at this point unless he'd picked it up and carried it. I'm trying to get those things corrected, for inclusion in a later release. But thank you all the same. :)

Glad to see there's still some interest guys. And thanks for the mention Zulu. Spad's been pretty busy trying to bring all the various contributions together. Although I kinda left the poor guy with a lot to do when I gave him what I had. I'm still working on some elements that didn't make into this release. Other events called a halt to them at the time. They should show up in a future update though. So try to be a little forgiving when you see things that look a bit "odd" or unfinished. You'll know 'em when you see 'em. :)

I'm not going to waffle on about the config side of things, as I lack solid knowledge in regards to the newer titles. But it looks like the system is the same. Actions calling states from within the relevant CFGMoves sections. They could be redirected to your custom animations, instead of redirecting using the state definitions themselves. Badbenson and McRuppert may have a more elegant solution for their raptors though. For the skeleton I think you're best to simply use the default set up for any memory points. Handily you're dealing with an upright biped. Obviously arranged to suit the mesh. I don't believe they're strictly linked to keyframed animations. Not that they aren't used. As far as I'm aware the points in the elbows, knees wrists and so on serve as pivots for procedural animations. So the engine knows how to offset the "skeleton" bones in what ever rtm is running at the time. As in when the character leans or looks up and down.The other points serve like nodes in other engines. Where they represent locations that spawn entities like particles or objects like grenades. Or leave footprints on the ground. Or tell the AI where to aim at the unit. Some official documentation would really be helpful there. Guess-work is no substitute for solid info. :) A single image with short descriptions on what each point does, exactly, would be enough.

That's the downside of course. They might look a bit strange in motion using the defaults. With current tools it'd still be a laborious task though. Even if you could set up a macro to semi-automate the process. But I guess you wouldn't need to do the whole set. Just the most commonly used ones would at least give you a functional unit. Creating a custom set would definitely give you the most freedom. And again you could get a functional unit with a reasonable number of commonly used actions.

There's only two ways to deal with it. Scale default animations if you intend to use them. RTMs override scale. Or, create a completely new set suited to the mesh.

Step moves your character forward and back. xstep moves them left and right. A mix of the two gives you any angle in between.

Yep. The spammers have been pretty busy lately. They've been all over the boards.

http://www.fantastic-plastic.com/decal-sheet.jpg Any use? I know some of the lettering is still fairly small. But I think you could get away with some "interpretation" on the fine print. :)

That's a great concept sketch on the previous page. Looking forward to seeing where it goes. :)