AC Modding Questions Thread

File>Save Persistence saved shader settings.

Utilities>Data Editor>Save Data should save weather etc.

Also if you haven't already, maximise the program and go to Layouts>Save Current, that should give you native resolution next time you load it.
Thanks a bunch. I'll try those next time. I tried some stuff but not exactly those.
 
Skimmed the documentation and couldn't find anything, so here goes:

20190116125046_1.jpg


susp in editor.JPG


Why does SUSP_X translate into the middle of WHEEL_X?

Do I need a HUB_X for it to understand where to translate to? What if my balljoint is offset from the hub center, as they usually are?

Right now this whole assembly is one SUSP_X, with the origin about where the strut ends. Control arms animate as well which is not my intention.
I understand that you'd want them to be a separate object and essentially part of the generic underbody mesh, correct? Track and wheelbase changes would not affect them and they'd be lined up with the strut. I understand if track is changed due to wheel offset for example, and you would wish to represent the strut accurately, you would have to re-model the angle to correspond with the new SAI and lower balljoint position relative to hub, correct?

My intention would be to animate the strut along it's correct SAI, so it turns in place around where the balljoint would be, with the controls arms static. Probably not gonna animate anything for this car even if it'd be perfect for it in stock form :rolleyes:.

The dilemma is simply: how does it know where to translate the origin to? In the KS editor and Blender the strut appears in the correct X, Y and Z location. In-game it translates to WHEEL_X center.
 
Without suspension animations, AC puts

- HUB at the wheel origin and hub rotation
- WHEEL at the wheel origin and wheel rotation
- SUSP at the wheel origin and hub rotation
- DISC at the wheel origin and wheel rotation

The answer is, put all these 4 objects in the same place, assume AC will keep them synced, and for any other objects, make them children of these.

With suspension animation, it picks the frame in the animation that matches the current height of the object best, and only uses wheel rotation around the X axis.
 
@garyjpaterson
@Stereo

So there's no way to just have the strut spin around the correct axis?

HUB and DISC are translated to the WHEEL origin? How does that work? What about offset hubs and discs? Doesn't the wheel origin have to be relative to the tire contact patch center, so that the physics can understand it correctly? In that case, how would you make a wheel hub that is offset to the inside of the car for example?

Wouldn't it make more sense for the parts to be where they are in the .FBX and for the SUSP to rotate from it's own origin, and for the HUB to rotate from the WHEEL origin, as the HUB is always attached to the WHEEL? And so on.
 
As long as your suspension physics match the model, the hub will rotate around the right axis anyway because the suspension constrains it to doing that. It's just turned into a translation+rotation, instead of only being a rotation around one of the hub model's axes. You could calculate the position/rotation with any point on the hub as the origin; making it the same point as the wheel's origin is just easy.

If your model in 3d editor has all 4 start in the same spot, then none of them has to move to match the WHEEL origin cause they're already there.

Originally AC had the origin of the wheel in the center of the contact patch but there's now a physics offset that can tweak that if you need to (I guess if you design a full suspension, then realize you used the wrong wheel/tire reference)
 
Last edited:
What I mean is the translation of the 3D mesh of the SUSP. The visual mesh. It translates itself in AC to the center of the wheel, as I have shown above.

Btw, wheel offset was added to AC so that you can easily change wheels of the car without having to go and redo the entire geometry. All you need to do is tweak the track to the new value according to the offset. Previously you had to go and tweak every offset in the pickups.
 
The 3d mesh's origin needs to already be at the center of the wheel, like this:
73fKIpT.png

light orange - SUSP_RR location
dark orange - 3d mesh (brake caliper/ducting)

Almost the entire mesh is to the right of its origin and it just stays there
 
Ahhh, now I understand. It makes sense now. I didn't consider it like this.

The reason my susp translates itself to the wrong place is because the origin is in the suspension, and the suspension mesh is offset from the WHEEL. So it then moves the origin to the WHEEL which in turn moves the mesh that is attached to the dummy.

I should have the origins lined up, and it will keep the mesh exactly where it is, and rotate it based on the physics? So if my strut translation and dimensions are correct, it'll work?

Yeah, it does. Thanks. If I match up the strut position with the real one, it looks like it'll rotate properly. A bit off now as it is, but the mechanics work how I want it to.

EDIT: Just realized in vertical movement the strut will translate itself through the car, because IRL it changes in length. So yeah, it should just be a static object, and the wheel hubs + balljoint can be animated. :(
 
Last edited:
Hi everyone, as a personal learn thing, i'm trying to make a driver animation on a car on 3dsmax.
I made the animation, then exported the fbx, but when i'm import it on kseditor it says

ERROR, FOUND SCALING ON NOME: RootNode

Anyone knows how to solve it? THanks in advance :)
 
How much do they not match? Some curve angles or something more serious?

My 240's blueprints don't even lined up 100% consistently with itself, and some angles are plain off, but I've been told they're still very nice to model from. Comes with the job?
 
How much do they not match? Some curve angles or something more serious?

My 240's blueprints don't even lined up 100% consistently with itself, and some angles are plain off, but I've been told they're still very nice to model from. Comes with the job?
In the sense that some features like lights arent on same place. Biggest issue is that rear bumper seems shorter on Classiccardrawings and on hum3d model than the blueprint. Also IRL its kinda like that. Or its just perspective issue?
03005-mid.jpg

aston-martin_db7_1999_photos_1_b.jpg

Aston_Martin-DB7_GT-2003-1280-09.jpg

aston_martin_db7_vantage_volante_1999-jpg.48628

astonm_db7vantagecoupe_2000-jpg.43902

It looks like photo matching and guessing from real life photos is the method. or other 3D model as BP lel.
 
Front and rear overhangs look much longer than is natural on real ortho drawings, perspective shortens them significantly.

Honestly just pick a blueprint, start modelling, you'll soon see if they are correct or not. If so, keep going, if not, you've got a solid base to start camera matching to IRL photos to perfect it.
 
You're pretty much guaranteed to never find blueprints for any car that are 100% accurate. Use them to get a base in order, but do not treat them as gospel.
 
Front and rear overhangs look much longer than is natural on real ortho drawings, perspective shortens them significantly.

Honestly just pick a blueprint, start modelling, you'll soon see if they are correct or not. If so, keep going, if not, you've got a solid base to start camera matching to IRL photos to perfect it.
You're pretty much guaranteed to never find blueprints for any car that are 100% accurate. Use them to get a base in order, but do not treat them as gospel.
You are both correct, actually. There is more to modelling than BPs. Thanks for advices!
 

Latest News

What's needed for simracing in 2024?

  • More games, period

  • Better graphics/visuals

  • Advanced physics and handling

  • More cars and tracks

  • AI improvements

  • AI engineering

  • Cross-platform play

  • New game Modes

  • Other, post your idea


Results are only viewable after voting.
Back
Top