scotg

LOL I get what you're saying... it can shift from 4x2 to 4x4 to 4x4 locked. I've got it set up more of a 4x4 limited... for now. I don't know how it should perform, but I figure a BMW-ish SUV is a better starting point than a weird Audi-looking pickup truck. Have a gander:

Here's something interesting: the SUV and Offroad (maybe others) have mismatch for damper_land_axis. The selection is actually named posun wheel_x_y, whereas in model.cfg it's trying to find wheel_x_y_damper_land_axis. How it's managing to work is one of those little annoying inconsistent mysteries. The Test_car model.cfg has it right, calling for posun*. SO... Thank You, UrbanizedGamerz!! Although I have looked at that page several times, one more look allowed me to focus on that one section that was different from my own. I wouldn't have looked again so closely if you hadn't resurfaced it for me. Now, my model is working much better!!

I'm a little out of the loop, but while reading through the recent posts - just to see why I am getting so many alerts - the topic of P: drive caught my attention. Can somebody summarize the current discussion? I have been unable to use Buldozer for a while now, and in the process of trying to remedy that, I can no longer use Arma3Tools as a one-stop hub. I can use most of the individual components, such as Object Builder, Addon Builder (don't hate), TexView2. I cannot, however, use the mass image converter tool (forget the name) or reestablish my P: drive. After reading toady, I'm not sure I want to or even need to.

Some updates of progress, but still not resolved. See first post edit. Side note: 8 Random paint jobs are now working: Gray, Red, Blue, Yellow, White, Black, and 2 special designs. YAY!

I've almost solved all the initial problems, except the visual suspension. - The instruments are working, but they need adjustments. - I used the animation from the SUV for seating; it helps a lot. - Texture placement in RVMATs were scaled up because I started from the Offroad RVMATs, so the solution was to set them all to a 1 in scale. - I also borrowed the performance parameters from the SUV, in place of the test_car parameters. The vehicle performs better on and off road, now. - I even managed to get 8 paint jobs to choose at random. The only thing still wrong is the visual suspension matching the performance. One thing that I fixed to get animations working was in the model.cfg, under class CfgModels: after class Default section there should be class "whatever your p3d's filename is":Default - minus the quotes. Then your skeletonName WITH quotes should match whatever you named it at the top of the file, where the bone definitions are. Only other thing I can think of is to check your non-visible LODs for consistency. Make sure your memory LOD has boneName_axis for rotational pieces. Make sure you have a land contact LOD with for points under the wheels, labled wheel_x_y_damper_land. The wheels in the geometry LOD should be wheel_x_y_damper, and give them each a mass of about 20-100 (I'd say about 70 for the Tumbler rear wheels, or 35 per tire x 4 tires).

Sorry to dig this thread up, but it was best match I found relating to my questions. I think I might need to move my Arma3 from my secondary drive (HDD) to my primary (SSD). P: Drive and Arma Tools no longer work for some reason, and they haven't been working for months. Consequently, neither does buldozer. It all happened after one of the updates. So, am I correct to try reinstalling to the primary drive (C:), or is there some other reason why this is happening? My HDD (secondary) is ~1tb with about 600gb free space, and my SSD (primary) is only 93gb, which has about 25gb free, total after upgrading to Windows 10. So, the other concern is will there be enough room to hold a few mods? All the work models and textures for my own mods will remain on the HDD.

Kinda blows, huh? Alright... pooh. I foresee an issue with solid axle when you need the gear compartment modeled. would all those vertices in that part be weighted 50/50 (assuming it's in the very center)? I think the center is weighted to the root (i.e: not really weighted) in the A3 ground transports, which is why it looks so awful.

There's more than simple spring weighting being discussed. I'm sure we've got that figured out. One other member said that with a fully modeled spring you'd still have an unnatural squishing look, but I don't think that's true if you weight the vertices within a ring group the same. Example: if your coil had 24 sections, and was made from a 6-sided cylinder, then 6 vertices would be the same, and 25 groups of vertices would have weight assignments that gradually shift favor from the body to the damper_land. This would be handy if you had a spring that was larger than life, and would look just wrong as a cylinder. The original point of this thread was supposed to be how to use the spring weight trick combined with other suspension parts, that are not weighted but still move via skeletal system (or IK or advanced scripting). Whatever it takes, I'm sure it can be done. "So do it," said someone to me, but that's like asking an armless man to mow your lawn - it can be done, but do you really want to wait that long? This is how I've set up the left front wheel, and others are the same, except _1_2 for left rear, _2_1 for right front, and _2_2 for right rear: "wheel_1_1_damper_land", "", -- I have the actual wheel model named this "wheel_1_1_damper", "wheel_1_1_damper_land", -- no model, but linked to the damper_land. What's the difference between damper and damper_land? "wheel_1_1_steering", "wheel_1_1_damper", -- no model, linked to damper. Can a model piece go here if it exists? "wheel_1_1", "wheel_1_1_steering", -- no model, linked to steering. One would think this is where the wheel model should actually go. "wheel_1_1_unhide", "wheel_1_1", -- not sure what hide unhide do; I assume one is wheel & tire, the other is just wheel. So then maybe the actual model goes here? "wheel_1_1_hide", "wheel_1_1", -- see above, both are linked to wheel. I figured out the reference page has it backwards. I used the sample model of the test_car, but then started to implement some physX parameters of the Offroad into my current car project.

It's hard to know exactly which faces should be turned outwards, but if it's all faces then select them in OB and press 'W.' Otherwise, try using the selectObject tool to get only the pieces you want to flip. It should be the default tool, and its cursor looks like an arrow with a white box next to it and a selection area under that.

Ok. I put that link in the first post. Here's the overview of what it talks about: wheel contact performance on tarmac and terrain driver hand position dashboard instruments EDIT: I should have mentioned in the video that my memory points are in good position, although it might seem visibly otherwise. That goes for the wheel_x_x_bounds in the memory LOD and wheel_x_x_damper in the land contact LOD.

I'd say if you're using Oxygen 2 then you're using obsolete software, as opposed to the newer Object Builder. Others might object to that, and yet others might say, "'six' of one/'half-dozen' of the other," meaning that they're pretty much the same. I went through this stage before. You successfully import your cherished work into something that looked so daunting. Congrats on your first step! If you just want to see it in buldozer, then you'll have to jump through a series of fire hoops and laser-mounted shark pools. In other words, you have to set up a P: drive, which is finicky to say the least. It has worked and not worked on my very same computer set up, with the changes being due to updates in the game and engine. IF you're trying to eventually implement your model into a game setting, then there may be several other things you need to do before you can see it. Even when buldozer was working, I preferred to see my models under various lighting conditions, and in relation to other objects, in the game editor. The simulated sun can wash out your model's colors and make you rethink its texture setup. For a ground vehicle, you'll need several other LODs to get it to work right, but you can for now treat it as a static object and see how it looks under the sun.

For SMDI, I find it easier to work with each channel separately, in grayscale. In photoshop, I'll create a layer group specifically for specular, and another for gloss. Usually, I try to keep the gloss channel as low detail as possible, with broad areas of different shades of gray. In my experience, this helps to prevent texel clumping - a side effect of converting to DXT formats, which PAA is in this case. When I am satisfied with both images, I'll create a new FINAL layer filled with white. Ctrl+Shift+C each group then paste it into the appropriate channel of the FINAL (gloss goes in blue, spec goes in green, red channel is max). Saving for web, PNG-24, tends to cut down texel clumping a bit as well. You can save PNG files as PAAs in TexView2, and it will do the final conversion. I'm sure this will help since you are getting acquainted with texturing, even though it's more than what you asked about.

True it doesn't look quite right, but doesn't it look more weird to you when there is no movement at all? While examining a weight-defined spring animation, it's easy to see its flaws because it's the focus of your attention. When playing the game your focus is probably going to be on something else other than suspension. You might or might not notice something is off about the springs while following a vehicle on a mission, for example, but you're more likely to notice if they aren't doing anything at all. Perhaps it's a matter of perspective, but that's just my take on it. That sounds like it might work for a telescope or something. It'd still look a little off, but probably only if closely examining it during a game. Not to say that such a level of observation doesn't happen during a game - it does, but for regular gameplay, these tricks would work to some level.

I just might. I'll admit that I'm one of the least likely candidates for pulling off such a task, but if that's what has to happen to get it done...

I get that it's less taxing on the CPU to fake real suspension, but the visual should also work, or it's all crap. It's like going to a second rate magic show, where instead of smoke and mirrors to hide the illusion, they use curtains. Even though you already know it's not real magic, the curtains - even the classy, expensive kind - just cheapen the act. I would think that developers of a game featuring more terrain than road would have thought "gee, maybe we should make suspension look visually acceptable by allowing the use of a skeletal rig for vehicles." Getting back on topic, I think that there is a better way to create this illusion than what they've done with weights. After all, other modders have succeeded in creating more realistic towing, pilot-controlled turrets, and flexible antennae that bend when vehicles move. This is probably where scripting actually comes in - either in config or xml. I'm the artist with dangerously limited scripting knowledge type, so I wouldn't know. There might still remain a certain level of weighting necessary, eg: if you have a spring modeled from a cylinder with alpha and bump to imitate the coil. Then, you'd weight the end edges of the cylinder to different parts of the suspension, just like it's already done with the quadbike.

Pilot or driver controlled turrets +1 This is a real life thing guys. I see time and again this goes ignored. There's a legit demand for this, and the benefits far outweigh the negative effects. Vehicle suspension IK or faux IK +1 vehicle skeletons have been used in game engines since UT2004; that's 12 years to date. This would allow suspension arms to constantly adjust their rotation and give the illusion they are guiding the wheel up and down. If implemented, there should be upper and lower arm consideration. Better yet: allow any part of the vehicle the ability to aim at any other part while fixed on its axis.

Sorry to dig this up, but I am encountering the same problem with my vehicle, an SUV. If I move the proxy down to make contact with the drivewheel, then the character is sunk into the seat and feet hanging below floorboard. Using the Offroad animations is best for the seating position, but my vehicle just has a smaller steering wheel (drivewheel). In fact, the hands are the same distance from the wheel at all angles of its turn. Is there a scale or radius setting in the config files - something to fine-tune the hand positions? I imagine this would be a more wide-spread problem, since it's not real IK working here, according to BIS. If there's no parameter section for changing precise hand placement, that means for every different seat position/wheel size combination there would have to be a separate animation. Since we have to specify the ground wheel radius in config, then it stands to reason that this should be definable, too.

At this point, I have solved some of the issues mentioned above. It turns out the glass' RVMAT had unusual scale parameters for the different stages. Setting everything to '1' was the key there. For propelling the car and instruments, it was a matter of name mismatch between the model and the class in the model.cfg. I had forgotten to add a version number to the P3D file; i.e: LM002.p3d should have been LM002_01.p3d since that is how I defined it in the CFG file. The instruments are working, but they need to be corrected. The suspension is still not moving. I'm not sure if this is model.cfg or config.cpp editing, but it's sure not a modeling issue. Is there a way to adjust the driver's hands' positions to fit a smaller steering wheel (drivewheel)?

It looks like there might be updated samples, but I have referenced them before. I don't believe I am trying tricky stuff, but the test models are of very limited help. The last time I tried a tank it crashed my game. The car is of no help, and seems to have memory points that the Offroad doesn't. My SUV should work a lot more like the Offroad (BTW, I've made a Lambo LM002, one of quite a few vehicles I'm working on). I've actually got a lot of issues with this vehicle that I'm not sure how to fix... maybe I should start a new thread for that? At this point I would like to ask the admin if they could move this thread to a more appropriate section. I'll leave it to your better judgment.

I've worked with several game engines in the past 12 years. I'm no expert, though, since most of that has been on a non-professional level. I'm gonna have to call BS on "what PhysX can deliver," but I'm not pointing fingers at you x3kj. I don't think it's a condition of what PhysX can or cannot do; it's a matter of what the game engine programmers have or have not thought to include in their world. I've made mods for UT2004, Battlefield 2, Crysis, and lately ArmA 3. Here's what I don't get: Of all those engines, UT2004 (unreal engine 2.5) is the only one that had some kind of suspension realism. The tank treads flexing didn't always work, but the suspension arms could point to the wheel without relying on weighting/deforming. All the other titles on that list had only faked the suspension or none at all (but they also all supported tank tread flexing). How is it that the oldest game in my repertoire has better vehicle skeleton than the newest? Ok that was a bit of a rant, but it was due. Incidentally, Unreal Tournament 3 supported better tread flexing AND suspension rigging. I see what you mean about those rigid axles; it's strange how something so rudimentary would be so complex to make it look right. I can see other examples of the pseudo suspension at work in the Offroad and the Quadbike, as tested. It's probably the same for other vehicles, but I didn't happen to test any others. This is that faked suspension I mentioned above. It's not pretty, but it's not as ugly as no suspension animation at all, except in the case of rigid axles. The ground vehicle physics in ArmA 3 are sub-par, anyway, so I suppose this is tolerable. It just seems like, if they figure out how to make 2D surfaces look like 3D (parallax occlusion), rag doll, super-realistic helicopter physics, etc, then why can't they get a simple vehicle suspension setup working?

Thanks DH! This clears up a lot of things. The BIS page on model.cfg says that in wheel_x_y the x is the position from front to back, while y is the position from left to right. It's a little baffling when you have a bone called wheel_1_4, which by their logic would indicate 4 columns of wheels (like a pair of quad roller skates) instead of 4 rows (like a Stryker). They must have been sleep-deprived when writing that page, like I was when I picked the wrong section for this thread. I'd guess the steering hub must be wheel_x_y_steering. When looking at the bones in the model.cfg, there is a wheel_x_y_steering for ALL EIGHT wheels. I suppose a conventional 4-wheel vehicle might have 2 steered wheels, but specialized, unique vehicles might have steering on all wheels. The Nissan 300zx TT is an example of this; it has a system called HICAS in which the rear wheels turned opposite the front wheels to a smaller degree. The visible difference of its rear steering was negligible, but the effect was faster, tighter cornering. For a more effective visual usage, somebody may have designed their own vehicle with all-wheel steering. Front loaders and train cars have similar steering functions. This is one of the appeals to having a game we can edit and import our own stuff into - R&D. We'd get to see how it might look in a real setting, and how it could be utilized in certain situations. I'm getting off topic for the current vehicle I'm working on, but I'd hope to be able to tackle this easily if I ever need to. So what I want to know is: if I have wishbone suspension on a vehicle with exposed wheels and suspension, how would I rig the A-arms and springs? Are they already part of the skeleton, like wheel_x_y_damper perhaps, or would I have to create a special IK animation for them? I can weight the springs as long as I could have the A-arm pointing towards the wheel at all times while attached to the frame.

I meant to reply to this a while back, but it's been crazy busy in my household. As a point of fact I did get the chinstrap weighted to "jaw" or "jawbone" (can't exactly remember now since it's been months). It works perfectly, because when the soldiers talk/chew/yawn/etc. the helmet's chinstrap moves with the chin. Thankfully, my helmet's chinstrap is fairly simple, so there was no headache involved. Now that I've got that covered, I'll have more knowledge going in once I start to create the neck-gaiter. Kind of a cross between a bandanna and a balaclava, the neck-gaiter (raised over the mouth and nose) will require more weighting around the mouth area. Now THAT sounds like a headache, but it's achievable. Some might say, "Why not just use a bandanna?" The simple answer is the gaiter has a more defined jaw line, whereas a bandanna just kind of hangs down. Neck-gaiters are a standard issue item in many soldier uniforms, especially US Army, and for the purposes of this game they just add distinct customization. For anybody doing helmets and headgear, still reading this thread, and want to take it to the next level, then I suggest looking at the model.cfg file for a helmet and see what bones are available to weight to. You could be creative and add a band-aid or thick beard as if it were headgear, if you wanted. Anything attached to the skull should be left alone, but anything influenced by jaw and/or mouth movement can be given life with weights.

I'm getting some major pixel clustering when I convert tga files into paa, but it seems to be only with the _SMDI and _AS textures. Here's my process: 1. Create a 2048x2048 .psd file for my object with folders dividing diffuse, specular, normals, and ambient shadows. 2. Diffuse is always grayscale, and AS usually starts off with an inverted colors (negatives) version of the combined specular image. 3. Save out the Specular layers to a .tga file ending with _smdi, eg: myObject_ext_smdi.tga 4. Open that new .tga in TexViewer2, and save it as myObject_ext_smdi.paa 5. The new .paa file has lost a lot of information, forming large blocks (clusters) in the image. This has happened to EACH. AND. EVERY. *_smdi.paa and *_as.paa texture I've created. For diffuse it seems I can sometimes trick the compression to avoid clustering; I sometimes add what I call a "noise overlay" to the final diffuse image. This trick doesn't work for the textures smdi and as. Is it some kind of overactive compression? LOL But seriously, other people have non-blocky, "hi-res" DXT1 files out there, so why does it create these ugly ones for me?

I had a similar thought, but I wonder what your settings are, specifically? I've tried PNG-24, and the blocks were still there. PNG-8 creates a file unreadable to TexView2, and JPG seems to enhance the blocks. My textures are rather dark as well, especially the _smdi channels, but also the _co and _ca. It appears that contrasty is working the best. I played around with legacy brightness and contrast in the green channel of my _smdi image until it was not making blocks. Some parts got a little too bright as a result, but at least it gives me a new starting point to work with. This is all subject to theory for me at this point, because the method I used to quickly discover if it was blocky was to screen-cap TexView2 with my newly contrasted file open, paste it into a new .psd document, desatch, and again adjust the brightness. I figure if it can go through that much conversion and still remain unblocky, then it must be working.

So maybe it would help the overall map if empty space (non-UV mapped) had full range... i.e: add highlights where they are not needed for the sake of image integrity -- is that right? Strangely enough, I'm not having issues with texel blocks clustering in my normal maps. It could be due to the DXT5 format, or that the typical colors in a normal map are diverse enough to prevent the blocks. Since you said "small amount," I'm wondering if you could be more specific. On a related side note: adding noise to the diffuse (_co/_ca) map does indeed help prevent the clusters forming.