Cars Help with model component mates and orientation

[bikerbob951]

I'm attempting to port a car that I've designed in Solidworks. The issue I'm having is the front suspension components showing up in 3DsimED and KSEditor with incorrect orientation, as if they were never mated in the parent file, although they definitely were. "Fixing" the components in the SW model seems to help, but it makes the SW file tree VERY unhappy (see first pic).

My questions are:

1. How do the suspension components know where to fix in the .fbx and .kn5 models? Do I mate them in blender or something? For example, how does the control arm know to pivot around the inner bushings? Or how does the suspension upright know to pivot around the kingpin inclination axis?

2. Does the precise location of the car's origin matter as it relates to game data? For example, the CoG of my model is not exactly between the front and rear wheels, but it looks like a lot of kunos cars are set up so the origin is equidistant between the front and rear axles.

For the curious, my workflow is as follows:
- Model exported from Solidworks as .STEP (AP214) file. All susp. still looks correct.
- Model imported into CAD Exchanger and exported as an .fbx file. All susp. still looks correct.
- Model imported into 3DsimED 3.2c Some susp. components lose their constraints.
- Model exported into KSEditor as .kn5
- FWIW, I haven't edited the suspension.ini files yet, they still reflect the stock Kunos formula example

I hope I was clear with my questions! I included a few screenshots for reference.

 

[Stereo]

1 is accomplished a few ways. Either you bake some animation files (sweep suspension from bottom to top and save ksanim using kseditor) or you create specially named objects that the game knows how to move.
2. no, car.ini has an offset line that can move the mesh to match the physics regardless where it started. From this offset's point of view, the car's origin is its CoG, so you also set everything else relative to that (wheel positions)

kseditor reads fbx files so I'm not sure why 3dsimed is involved. But neither of the two can do anything with constraints, if animations are in the fbx,l it's baked out to the position/rotation matrix at each frame.

 

[bikerbob951]

1 is accomplished a few ways. Either you bake some animation files (sweep suspension from bottom to top and save ksanim using kseditor) or you create specially named objects that the game knows how to move.
2. no, car.ini has an offset line that can move the mesh to match the physics regardless where it started. From this offset's point of view, the car's origin is its CoG, so you also set everything else relative to that (wheel positions)

kseditor reads fbx files so I'm not sure why 3dsimed is involved. But neither of the two can do anything with constraints, if animations are in the fbx,l it's baked out to the position/rotation matrix at each frame.

First of all, thanks for the quick reply Stereo!

1a. Baking the animation files, would I do that with blender or KSEditor?
1b. The "Specifically named objects" thing you mention, is that the DIR_ script? I'm trying to learn how to use that but I'm struggling.

2. So if I'm understanding, I can place the car anywhere along the Z axis, but in the car.ini the offset should put the origin on the car's real world CoG? So the front and rear axles will be different distances from the CoG on the z-axis, right?

 

[Stereo]

The car's CoG ingame is always 0,0,0, there's no way to move that. Everything else moves. So in suspensions.ini you set CG_LOCATION to set the front-rear split of sprung weight, which moves both axles front to back, and BASEY to set how high the axles are relative to the CoG. (after which of course springrates and stuff determine the actual ride height)

If the visual model is exported with 0 halfway between the axles and at ground level, then it's a simple matter of x=0, y=-cg height, z=(0.5-CG_LOCATION) * wheelbase. Other visual stuff is set after this so you can use 3d modeler coordinates (remembering that it uses Y up, Z forward)

I don't know what the DIR_ script does, the only part that actually matters to AC is if you have an object named Whatever, and an object named DIR_Whatever, then it'll rotate Whatever to point at DIR_Whatever ingame. So you can either make the suspension arms part of the body and the DIR_suspension arms part of the wheels, or the other way around, and as the game moves the wheels they'll rotate to match. It gets more complicated if you want something like an anti-roll bar that's connected by a linkage, cause there's kind of an implied self reference (the link is pointing at the bar, and the bar is pointing at the link) for that sort of thing the easiest option is just baked animations.

 

[bikerbob951]

The car's CoG ingame is always 0,0,0, there's no way to move that. Everything else moves. So in suspensions.ini you set CG_LOCATION to set the front-rear split of sprung weight, which moves both axles front to back, and BASEY to set how high the axles are relative to the CoG. (after which of course springrates and stuff determine the actual ride height)

If the visual model is exported with 0 halfway between the axles and at ground level, then it's a simple matter of x=0, y=-cg height, z=(0.5-CG_LOCATION) * wheelbase. Other visual stuff is set after this so you can use 3d modeler coordinates (remembering that it uses Y up, Z forward)

I don't know what the DIR_ script does, the only part that actually matters to AC is if you have an object named Whatever, and an object named DIR_Whatever, then it'll rotate Whatever to point at DIR_Whatever ingame. So you can either make the suspension arms part of the body and the DIR_suspension arms part of the wheels, or the other way around, and as the game moves the wheels they'll rotate to match. It gets more complicated if you want something like an anti-roll bar that's connected by a linkage, cause there's kind of an implied self reference (the link is pointing at the bar, and the bar is pointing at the link) for that sort of thing the easiest option is just baked animations.

You mentioned "after which of course springrates and stuff determine the actual ride height" and I was going to ask about this as well. In solidworks, I've designed the car sitting at ride height, which is about 4" from the bottom to the ground. should the CoG represent the car at ride height?

Thanks for the explanations, I'm new at creating cars, although I'm sure that's obvious by now. I'm well-versed with engineering 3D design programs, but this is a whole different universe.

I'll tinker with some of this tonight and see if I can make sense of it. I'll probably be spamming this forum quite a bit, there's so much I don't understand yet.

 

[Stereo]

You mentioned "after which of course springrates and stuff determine the actual ride height" and I was going to ask about this as well. In solidworks, I've designed the car sitting at ride height, which is about 4" from the bottom to the ground. should the CoG represent the car at ride height?

Usually you'd set the CoG, suspension geometry etc. at "design height" and then adjust the springs to get "ride height", if they happen to be the same then it's just an easy matter of checking that the telemetry ingame zeroes out the actual ride height.