Synide

The short'ish answer is that most of the female models already present you'd need to physically edit the models in one way or another as many have abbreviated Skeleton definitions embedded. The attempts by various people to muck about with female characters have been based generally around manipulating the standard BIS released male models to 'look' more feminine mainly because there is not a large stock of female sized animation .rtm's available and so you need to use the male sized .rtm's. The upshot is there are alot of cavets, gotcha's and eula infringements envolved. So, while not impossible it's just not really practical or legitimate to do. -Sy. PS. Oh, and to answer your question specifically... No, you could not do that because the proxy's for weapons, launcher's etc. do not exist in those models.

Can you provide a picture of what 'not showing correctly' means?

In a given LoD... say 1.0... have the Windows>Animations window open... right-click in this window and select 'From Matrices'... a Browse to file dialog will open... navigate to any of the ArmA1 .rtm's... note must be ArmA1 .rtm's... or any non-binarized .rtm. The ones in A2/OA are binarized so can't be used... Then just scrub through the loaded frames in the Animations window... this will deform the mesh in the O2 viewport... You'll quickly 'see' if any points/verts in your mesh have inappropriate 'selection' definitions... and/or are poorly 'weighted'... -Sy.

Yes, As Bink mentioned... 'Disable Model Config' should always be ON when dealing with characters. OFF, when you're mucking about with User Anims for structures, vehicles etc. But, one thing you should ALWAYS do when mucking about with characters in O2 is intermittently apply a .rtm to the LoD's so you can visually confirm that the points/verts selections are being moved by the appropriate transforms in the .rtm. - Sy.

This is a bit quick and nasty... but should get you heading down the right'ish sorta track... glowy eggish... maybe. -Sy.

Ahhh, I think I understand now... So I take it then your only desire to have 'skeleton' of bones/joints over in 3DSMax is so you can 'see' if you're weighting your new character model correctly so that when it eventually does make it over into the game side of things that when a anim gets applied it'll deform as expected. I'm not aware of any plugin (at least currently available to the public) that exports anims directly over to the game format from 3DSMax. There is a tool that's part of the VBS2 product that can transfer the info. Yeah, you could do that... it's better than using .3ds at least... and the .bitxt format is easy to understand... But, have a look at Soul_Assassin's 3DSMax Tools that should get you there. The A1 .rtm's can be read and applied to characters in O2. If you wanted to bring that animation data into 3DSMax you'd have to make your own process to do so. The A2 and A2/OA .rtm's are not in a readable format. As Thromp said. You can create your own skeleton based on the location of the point that resides at the 'right-angle' of the triangles in the Edit 2.0 LoD from the male.p3d, which you should be able to get over to 3DSMax fairly easily. Initially I wouldn't worry about the rotation of the locators (or whatever they are called in 3DSMax) for your 'skeleton' the more import aspect is each ones relative position to it's parent. I suppose I could post a .fbx of the 'skeleton' of joint locators from one of my earlier modo scene files it might get you a ways to your end goal... FBX format OFP2_ManSkeleton. You'll note that all of the locators in this version are in their default rotation at the time of creation. Why, because various anim apps. have differing ways they want to orient things when you start applying IK/FK solvers etc. The main thing is their relative location & heirarhcy. Also, there is a 'weighted' proxy mesh in there. I'm not sure in the mesh influence deformers from modo will carry over to the .fbx file but if not the weightmaps should. You'd ofcourse be attaching/binding the locators to whatever equivalent 3DSMax uses for your own 'new meshes'... dunno. You'll also note there's all the 'facial' locators there as well... generally you'll probably never need to use those and you could quite easily get away with removing all of them. They're all the ones that are parented to the 'Head' locator. Anyhoo, hopefully that'll help. - Sy.

Hi, The more relevant question is... even if you get you're 'skeleton' setup etc. over in 3DSMax how were you planning on getting the animation over to A2/OA? - Sy.

Oh, I've a 601 variant... it's still just the loader/saver, still no .rtm... I've included .html help files. So, it's a little more polished. And, as it's a code re-write I may or may not have introduce bugs... Probably the main thing to note is that by default pick-maps drive point/vertex selection. If you want weight-maps to drive point/vertex selection you have to add a locator to the mesh. See the help documentation under Help menu. Installation:- It's probably a good idea to 'blow away' your modo601.cfg and let the application create a 'new' one... thus clearing out any 'old' p3d plugin info. Most people have the 601 Content installed with their application. In the root folder of the Content is a new 'Kits' folder. Extract this .7z file into this folder and start modo. Done. modo 601 p3d file i/o plugin 2.2 Mbytes mirrored via kellys-heros.eu Cheers, Sy.

Hi M.Evans, The problem is that if you have the original source mlod then you do not need to 'redefine' all the selections in the p3dm mlod as they are already defined. You should already have the model.cfg too if you have the source. See when you save a p3dm mlod .p3d from O2PE if any of the selections are currently completely empty of faces & points then O2 removes that selection from the file. If you are having to redefine all the selections in this model because they are empty that says that the model is being looked at directly after being converted from odol to p3dm. Get the original p3dm & model.cfg then come back and post. Cheers, Sy.

I believe it basically just groups the polygons (and by inference the vertices, as best it can) into contiguous blocks based on they're sectional allocation... afk. All the polygons in your LoD have an 'index', zero -> N. It'll just be putting all the faces mapped to your glass, skin, hairdryer together as I understand it. All faces have a 'section'... that is a unique texture/rvmat assignment. It'll just run down all the faces and re-organize them by section. dunno, probably prior to packing would be a good bet... but, intermittently during your modelling process can't hurt either I'd imagine. Really? Huh, interesting... Still I don't think they'll be much you can do to alleviate that. --Sy.

A Section = unique texture/rvmat combinations mapped to faces in the given LoD. More sections = more drawcalls, less sections = less drawcalls. For example you may have a cube with six faces. All the faces are mapped to the texture... 'fat_dice_co.tga'. If you also mapped each individual face to a different .rvmat then there would be '6 Sections'. They're are 6 unique texture/rvmat combinations. However, if you condensed all the face texture/rvmat mappings down to 'fat_dice_co.tga' & 'fat_dice.rvmat' then you'd have 1 Section. How do you reduce sections? By merging textures. Usually, in doing so you increase the physical dimensions of your textures at the same time to keep some texel resolution. To many for a 'car' imo... should be aiming towards 1/3 or 1/4 of that or less if you can manage it.

Do you mean like a radar dish?

The DirectX in O2PE will allow .tga, .png & .jpg to be 'previewed'. The deafult, recommended format is to use '.tga' though. No, the DirectX feature doesn't allow for previewing .paa's within O2PE's viewport. The UV Editor will preview .paa's fine but not the O2 viewports. You 'should' always have 'textures' in you O2 pointing to .tga's. The reason buldozer will be autoconverting any .tga's to their .paa variant (which is annoying but logically quite a sound practice) when you are launching into buldozer is that it either found that the .paa did not exist OR it found that the timestamp on the .tga is LATER than the timestamp on the .paa so you must have edited the .tga and so it'll make a new .paa. It's thinking... you want to see the latest version of the .tga you have mapped to this 'face' (and have just edited) presented to you in buldozer. All .paa's are compressed. There are no non-compressed .paa's.

Nice stuff... Seeing as you're doing a .dll to get your data out to V3. Perhaps you could have spawned sqf threads that concentrate on interacting with additional .dll's that tear through some of the heavy data a bit quicker out in c++. Whether it'd actually end up giving you much of a boost when you have to manage the flow into and out of A2/OA I dunno. Just a arbitrary thought. Cheers, Sy.

Yeah, true my bad... with just the 'class Helicopter {' I'd end up updating the base class in my post wouldn't I... think I'll have to start sending my .cpp's to Germany for a bit of 'slap & tickle'.

Isn't the following the BIS prescribed method of sub-class inheritance? class CfgVehicles { class Helicopter { class Turrets { class MainTurret; }; }; class kyo_Bravo_November : Helicopter { ... ... ... class Turrets : Turrets { class MainTurret : MainTurret { gunnerOpticsModel = "\ca\weapons\optika_empty"; }; }; ... ... ... }; };

Cool. Nice to see different stuff. Most excellent. The BI version of Planetside2... :)

Perhaps if you try... Create a Geometry LoD in your 'STA2_Type2Zasleh.p3d' with nothing in it. Make a LoD Prop called 'sbsource' with a value of 'none' and a 'autocenter' with a value of '0' in this Geo LoD. In the 0.0 LoD make a LoD Prop of 'sbsource=none'. In your 'STA2_Type2.p3d', in your visual LoDs like 0.0 and ViewPilot make a LoD Property called 'lodnoshadow' with a value of '1'. Give it a blast... excuse the pun. Also, dunno how good it's going to be having such a long muzzleflash... but if it works go for it.

That's ArmA stuff mate... not ArmA2/OA.... 'ca\air\data\optika_heli_tl.paa' is from air.pbo for A1. Somewhere in your A2 stuff your pointing back at one of the optika_<blah>.p3d's from A1's air.pbo which in turn is pointing at this .paa. Then when you're in-game in A2/OA it doesn't have access to the old A1 air.pbo so can't find this .paa.

That's cool... I didn't do anything dude. It was all you. Btw, the reason I wanted the .pbo was to see if I too got the 'lag'... and I did. Was about 50%. s'good you got it sorted.

Can you send me the .pbo that is being loaded in-game or post it here so other's too could look at it too... many eyes make lighter/quicker resolution. synide at rocketmail dot com or if your on skype... also, what version of the game.exe are you using?

Ok, so we're starting to get confident that's the sections are looking cool (probably) it's good you looked at them even if it ends up not being the culprit. Tell us, when you are in the gunner or driver position are you in 1st person or 3rd person? And, what are you doing next? Are you just doing a 'Get Out' then looking back at your vehicle? Again, are you in 1st or 3rd person when doing this? What build of the game are you using? Are there any leads to problems in your build.log file?

Oh sure... it might be something else related to your model. That's the thing about modding A2/OA. There are alot of moving parts. Sometimes a problem is just the result of 1 issue, sometimes it's a combination of a lot of issues. As such, a common methodology is to work through a process of elimination. You slap & tickle a bit until it falls within BIS observed norms, then you move onto another bit and massage that. The only reason sections were mentioned was 'cause usually that's a good starting point with optimizing a model. If you go through the process of reducing your section count then at least you can feel confident that this area should in theory not be contributing to poor performance.

Does that mean yes, you do have some glass? If so, a glass texture will be a '_ca.paa' meaning it 'should' have an alpha channel. Alpha/Glass textures and high'ish section counts when you look at it in O2 can end up being much higher than you anticipate in the final ODOL. Whether this actually ends up being more drawcalls when you're in-game I'm not entirely sure but I'd imagine it probably does. I take it you know where to see the section count when you're looking at your model in O2 (Window>Resource Library). If you look closely it's essentially saying the combination of 'texture' and 'rvmat' equates to a 'section'. Eg. If you had a square cube and the cube had the exact same 'texture' on all 6 faces but each face pointed to a unique 'rvmat' then that LoD would have 6 sections. What you want to try and do is reduce this list of unique combinations of 'texture' & 'rvmat' to a minimum. However, this can sometimes be very difficult to do and still keep the quality you want. Hence I used the word 'try'. Sometimes to reduce your section count you have to combine or condense some of your textures (and there associated rvmat's) into one. Eg. You may have 4 faces each pointing at unique 1k textures and there respective unique rvmats. You might try mapping these 4 textures into 1 x 2k texture & it's single rvmat... Thus going from 4 sections to 1 section. Regarding 'sharp edges'... there should be alot of posts in the forums regarding this but using the 'cube' as an example. If it had no sharp edges then it'd be rendered with 8 verts and the normals averaged giving a smooth look. But, if all the edges were sharp then it'd be rendered with 24 verts and the edges would look hard & sharp. This shouldn't be a problem with your model though.