Porsche 911 (993) Turbo

Cars Porsche 911 (993) Turbo 1.1

Login or Register an account to download this content
I always thought there was sth off about the rear of the turbo. It turns out that the shape of the bumper is considerably different. Same is true for the base carrera, although the discprapency there is much less pronounced.
9934.jpg

Screenshot_a3dr_porsche_993_turbo_s1_magione_17-3-120-15-18-35.jpg

993 turbo rear bumper.jpg
 
There's a bunch of stuff a bit off, but oh well, I'm not gonna nitpick unless A3DR wants me to.

All cars in all sims have something off if you really push pennies. Except maybe GTS' scanned ones. ;)
 
There's a bunch of stuff a bit off, but oh well, I'm not gonna nitpick unless A3DR wants me to.

All cars in all sims have something off if you really push pennies. Except maybe GTS' scanned ones. ;)
Sure, there is always something if you really look for it. But A3DR’s cars are as perfect as they come imho. There is no reason to point out such differences in terrible forza’s models, as they are pretty casual in their overall form :D But here it’s another story.
Also I don’t just nitpick. I only try to highlight issues that change an overall feel of the car if you know what I mean. I would notice an incorrect stance but probably not a misplaced side blinker or wiper ;)
P.S. Even gts’ scanned supra has a wrong offset on the rear rim.
 
Last edited:
I don't mind getting corrected, in fact I appreciate when someone cares enough and takes the time to point out any mistakes, showing exactly where the issue is. Is not like receiving a 2 star rating saying "this model is way off".

So feel free to point out anything that might look wrong or out of place, as long as it is within reason I'll take care of it eventually. In this particular case I'm not looking forward to get back on it in the near future, since we had to deal with these 4 cars together (C2, C4, Turbo, S1) for quite a while, so it's not in my list of priorities for now.
 
if I ever decide to update it (and make LODs maybe)

Thank you for the nice car. For the issues with stopping diastance and turn-in understeer the cure is brake balance of 0.55 front.
I tried my hand at making lods B and C for both bodies and here's what came out:
 

Attachments

  • porsche_993_turbo_lodC.7z.txt
    872.2 KB · Views: 86
  • porsche_993_turbo_lodB.7z.txt
    1.8 MB · Views: 76
  • porsche_993_turbo_s2_lodC.7z.txt
    946.7 KB · Views: 74
  • porsche_993_turbo_s2_lodB.7z.txt
    1.7 MB · Views: 80
Last edited:
If anyone wants working check engine light, handbrake, ABS off and high beam dashboard lights, add this to ext_config.ini:

Code:
[INCLUDE: common/custom_emissive.ini]
[CustomEmissiveMulti]
Meshes = INT_gauges_lights
UseEmissive0AsFallback = 0
Resolution = 2048, 2048
@ = AlphaFromTxDiffuse
@ = DashHighlight
@ = MultiItem, Role = HIGHBEAM, Center = "1004.7, 522", Size = 70 
@ = MultiItem, Role = DashWarningABS, Center = "268.6, 702.2" , Size = 77   
@ = MultiItem, Role = HANDBRAKE, Center = "355.8, 701.7" , Size = 77 
@ = MultiItem, Role = DashWarningEngine, Center = "178.5, 718.8", Size = 77

This should work on all 993s (and doesn't require mesh splitting!)

Screenshot_a3dr_porsche_993_turbo_suzuka_circuit_14-6-120-21-52-10.jpg
 
If anyone wants working check engine light, handbrake, ABS off and high beam dashboard lights, add this to ext_config.ini:

Code:
[INCLUDE: common/custom_emissive.ini]
[CustomEmissiveMulti]
Meshes = INT_gauges_lights
UseEmissive0AsFallback = 0
Resolution = 2048, 2048
@ = AlphaFromTxDiffuse
@ = DashHighlight
@ = MultiItem, Role = HIGHBEAM, Center = "1004.7, 522", Size = 70
@ = MultiItem, Role = DashWarningABS, Center = "268.6, 702.2" , Size = 77  
@ = MultiItem, Role = HANDBRAKE, Center = "355.8, 701.7" , Size = 77
@ = MultiItem, Role = DashWarningEngine, Center = "178.5, 718.8", Size = 77

This should work on all 993s (and doesn't require mesh splitting!)

View attachment 388512
Nice, I see what you did there. Took coordinates from the texture to locate each light and map it to a function. Couple of questions:
Is it possible to change the color of each light or is it predetermined in custom_emissive.ini and it cannot be changed?
Where exactly did you get the values like "HIGHBEAM" or "DashWarningABS"? I figure there would be more options as well.

I see that you managed to make the digital display on the Turbo to actually work, that'll be cool to have too.
 
Meanwhile until you get proper answers, I'll try to help with a few as I've been trying to figure some of this lately:

1) color.png you'll just need to specify color to override the preset, if the masking works
2) Bottom of this page (link)

Using the patch Object Inspector app while in session, you can directly select a mesh (alt click) and then on the texture tab click on the small square to open it. I'll then be displayed in a way that you can click or drag to copy to clipboard coords or areas to help setting those emissives.
coord.png

Two examples of configs of this kind made by x4fab are the ruf_yellowbird and bmw_e30_m3 (note the hazard color code cluster). Those two cars are usually the first to be updated with latest features. :)
Both were previously using an external kn5 for new dash and outside lights mesh cutouts, but recently they have been converted to config-only.

Edit: If it interests you, you can also now have DI_ stuff where you can manipulate an indexed item on digital_instruments (like a properly positioned placeholder), and then make it output anything else like new patch only stuff, and/or reformat within certain constraints (pe, I've sent aphidgod a trick to convert the existing Cº into Fº by manipulating the output (x1.8 +30, iirc), so as setting the clock to show 12h instead 24h). DI_ usage (link), DI_ input types (link).

Analog odometers aren't set in a much different way than the above, but instead you set the area to draw (relative to the texture coord on assigned mesh), instead of assigning it to an existing/formated digital instrument.
This is a quickish example for this car, which I've tried to overlap to the existing texture font.The small part of the old dials texture still showing at the top unfortunately is in another mesh, so it won't be covered. Hopefully it should be easy to figure:
[ODOMETER_MAIN]
ACTIVE = 1
NAME = INT_gauges_numbers
FONT = odometer_font
BLEND_MODE = 0
POSITION= 1659, 1702 ;top left pixel coord for placing on the main texture, not on the smaller current object mapping
COUNT = 6
SCALE = 1.01,1.28
SIZE = 330, 60
DIGIT_WIDTH = 28
BACKGROUND = 0.05, 0.04, 0.05
COLOR = 1, 1, 1
JITTER = 0.015 ; how misaligned dials look (vertically)
MOVEMENT_INTERVAL = 5 ; this sets the last digit to advance in whole units, w/ 1 it would rotate freely; you'd add OUTPUT_MULT=10|MOVEMENT_INTERVAL = 1 if it also had a 100m digit like trip odos do.
odo.pngodo2.png
For all other formatting stuff, you can check on the car configs doc, so you can add a different background color to the 100m dial on a trip counter with LAST_DIGIT_ parameters , etc. The above overlayed odometer will also be rendered over the texture mapped on that mesh under the Objects Inspector app, which helps a lot.
*To add a note here, I think the proper way to do it would be to just have the "size" fitting the texture area it replaces (with untouched 1,1 scale, and position pointing to exact top left point), which maintains the same resolution look, or maybe with just a bit of bleed, because it also suffers from Z flicker on big maps, then just adjust number_width and play with FONT_OFFSET and FONT_SCALE to align digits (*note: these are undocumented on the car configs doc, but found on the yellowbird config).
On the example above, for I maintained the original font, I resorted to stretching stuff vertically with scale to have a better font overlap over the original numbers instead, as just manipulating digit width wasn't enough to approach the original lighter font look and kerning. I hope there are more elegant ways to do this, but it's not usually a concern other than getting just formatting/colors right.

To add a digital trip one where 170.7 is on a texture, you'd have to set at least a placeholder index=# via digital_instruments afaik, then remove those numbers (on the texture) and leave just the "km" if you don't wish to format another placeholder for two chars. Then if aligned to the right without leading zeros (to add you'd use 03.1), it'd go as:
[ODOMETER_TRIP]
DIGITAL_ITEM=#
DIGITAL_ITEM_NUMBER_FORMAT=3.1
UPPER_BOUND=999.9
If aligned to the left, it'd be like the subaru one on public release.
*To add a note here, it's better to have the placeholders for odometers aligned to the right, so you can have the option of using leading 0s or not, while if to the left you'll be forced to use them.
I hope I'm wrong, and there's a new fancy way to add it without a pre-existing guide index on the digital_instruments.ini. :unsure:

edit: removed an extra count line in the code above
 
Last edited:
Wow, thanks for the detailed explanation! I have no idea how to keep up with all this other than asking, so I'll be saving all this info for future reference. Don't have the time right now to mess with all this but surely will be worth checking for any future update.
 
Nice, I see what you did there. Took coordinates from the texture to locate each light and map it to a function. Couple of questions:
Is it possible to change the color of each light or is it predetermined in custom_emissive.ini and it cannot be changed?
Where exactly did you get the values like "HIGHBEAM" or "DashWarningABS"? I figure there would be more options as well.

I see that you managed to make the digital display on the Turbo to actually work, that'll be cool to have too.
HIGHBEAM, DashWarningABS and others are all input values supported by CSP, all supported ones are listed here: https://github.com/ac-custom-shaders-patch/acc-extension-config/wiki/Cars-–-Instruments-inputs

The digital display can't be made to work with a simple config sadly, I had to remove the 170.7 km texture from your model, add a dummy and use digital_instruments.ini to add a speedometer.

A protip I wish I knew sooner: if you ever find yourself creating config files for these functions, use CSP's object inspector app. Getting texture coordinates, sizes, names, resolutions etc. is an insanely quick process with that.
 
Wow, thanks for the detailed explanation! I have no idea how to keep up with all this other than asking, so I'll be saving all this info for future reference. Don't have the time right now to mess with all this but surely will be worth checking for any future update.
Np, glad to be of help. I've just added a few notes and a missing spoiler image to the previous post. :thumbsup:
 
OT: I'd have to sort my own workflow properly as even posts like the previous are a mess to read, and can't even reach tutorial status.
Stuff like the above, being directed to A3DR (also as a thanks for all he's given to the community), is just meant for someone with solid knowledge to quickly pick on the example and (mostly) to improve upon.
As with everything csp related, I'm not even sure if I'm sharing the best practices, so ATM I prefer to refrain from sharing a-z tutorials/streams as I'm by no means an authority on the matter, specially for how much base/pipeline knowledge+practice I'm lacking.
 
A3DR updated Porsche 911 (993) Turbo with a new update entry:

New tires + physics improvements, visual stuff too

Changelog v1.0

Visual

  • Adjusted paints for CSP 1.60
  • Fixed driver animation
  • Working odometers, thanks to @AlleyViper
  • Adjusted blurred rims settings
  • Fixed see-through backside of rims on stock

Physics
  • changed all tires over to custom load sensitivity curves
  • homogenized and properly scaled some tire values
  • reduced available tires to 90s/modern streets (90s default) on stock
  • reduced available tires to modern...

Read the rest of this update entry...
 
These things are a pain :laugh: , thanks for bothing to include them. It looks like there's a small issue with the main odometers in the last update :
For what I've seen on 993 TT pictures the "LAST_DIGIT_BACKGROUND_" lines should be removed (so all digits become black, as there's no 0.1km dial), then set MOVEMENT_INTERVAL = 5 (instead of 1), so it jumps digits for whole kms in the last number (this is usual for a main odometer when there's a separate trip for smaller units).
like this:
Code:
[ODOMETER_MAIN]
ACTIVE = 1
NAME = INT_gauges_numbers
FONT = odometer_font
BLEND_MODE = 0
POSITION= 1659, 1702
SCALE = 1.01,1.28
SIZE = 330, 60
DIGIT_WIDTH = 28
COUNT = 6
BACKGROUND = 0.05, 0.04, 0.05
COLOR = 1, 1, 1
JITTER = 0.015
MOVEMENT_INTERVAL = 5

On cars (usually) without a trip counter that use something like 6+1 on the main_odometer, which then have the last one for every 100m rotating freely with different color, then you'd add (and change count= + width adjustments if needed):
Code:
LAST_DIGIT_BACKGROUND = 1, 1, 1
LAST_DIGIT_COLOR = 0, 0, 0
MOVEMENT_INTERVAL = 1
OUTPUT_MULT=10 ; because main_odometer expects it ending in km, not 0.1km like _trip at = 1

If a km>miles conversion is required, you'd then use OUTPUT_MULT = 0.6213712 (instead of default 1) or OUTPUT_MULT = 6.213712 instead of 10 when applicable in examples like the spoiler above. Fortunately these Turbos are Euro spec!


I hope it's more clear, and not too much of a bother :)

All good with the new digital trip! :thumbsup: I'll have now a blast with a Signal Green S2 in the Canyons uphill on Iroha :sneaky:
 
Last edited:

Latest News

To join the OverTake Racing Club races I want them to be: (multiple choice)

  • Free to access

    Votes: 98 91.6%
  • Better structured events

    Votes: 17 15.9%
  • Better structured racing club forum

    Votes: 16 15.0%
  • More use of default game content

    Votes: 13 12.1%
  • More use of fixed setups

    Votes: 30 28.0%
  • No 3rd party registration pages

    Votes: 38 35.5%
  • Less casual events

    Votes: 9 8.4%
  • More casual events

    Votes: 35 32.7%
  • Other, specify in thread

    Votes: 5 4.7%
Back
Top