Car graphics config

[NaN]

Now:

Code:

[wheel-rr]
orientation = right
wheel-model = oem_wheel
tire-texture = touring
size = 245/40r17
tire = tire-touring
brake = brake-rear
coilover = coilover-rear
position = 0.755, -1.28, -0.48
hinge = 0,-0.85,0
camber = 0.45
caster = 0.28
toe = 0.0

Proposed:

Code:

[wheel-rr]
drawable-wheel = drawable-wheel-rr, drawable-tire-rr, drawable-brake-rr
drawable-floating = drawable-caliper-rr
size = 245/40r17
tire = tire-touring
brake = brake-rear
coilover = coilover-rear
position = 0.755, -1.28, -0.48
hinge = 0,-0.85,0
camber = 0.45
caster = 0.28
toe = 0.0

[drawable-wheel-rr]
model = cars/XS/oem_wheel.joe
texture-0 = cars/XS/textures/oem_wheel.png
texture-1 = cars/XS/textures/oem_wheel-misc1.png
#texture-2 = ...
#position = 0, 0, 0
#rotation = 0, 0, 0
#color = 1, 1, 1, 1
#type = noblend

[drawable-tire-rr]
model = 245/40r17
texture-0 = carparts/tire/textures/touring.png

[drawable-brake-rr]
model = brake-disk-0.14
texture-0 = carparts/brake/textures/rotor_shiny_slotted_drilled.png

[drawable-caliper-rr]
model = carparts/brake/caliper_worn.joe
texture-0 = carparts/brake/textures/caliper_worn.png

An option could be to have the textures as a list:

Code:

[drawable-wheel-rr]
model = cars/XS/oem_wheel.joe
texture = cars/XS/textures/oem_wheel.png, cars/XS/textures/oem_wheel-misc1.png

The tire and brake disk are generated and have predefined names to be able to identify them as the models are going to be shared between cars. All paths are relative to data directory for the same reason.

I'd like to implement this in a timely manner. Feedback is greatly appreciated.

[NaN]

I am also fine with avoiding named references for the drawables:

Code:

[wheel-rr]
size = 245/40r17
tire = tire-touring
brake = brake-rear
coilover = coilover-rear
position = 0.755, -1.28, -0.48
hinge = 0,-0.85,0
camber = 0.45
caster = 0.28
toe = 0.0

[drawable-wheel-rr]
model = cars/XS/oem_wheel.joe
texture-0 = cars/XS/textures/oem_wheel.png
texture-1 = cars/XS/textures/oem_wheel-misc1.png

...

The drawable names would have to be hard coded. But there would be optional drawables like:

Code:

[drawable-glass]
model = cars/XS/glass.joe.joe
texture-0 = cars/XS/textures/glass.png
texture-1 = cars/XS/textures/glass-misc1.png

[zimluura]

i've always thought it sounded more logical to have all sections of the car include options for mass, position, mesh, and texture.

would be good for doing upgrades and weight reduction in the game interface. take out a seat and you see it disappear. swap a rear differential and you see what part on the car is getting replaced.

so maybe



[wheel-rr]
mesh: oem_wheel.joe
textures: oem_wheel.png, oem_wheel-misc1.png
mass: 3 // hub-assembly mass only, tyre/wheel gen. mass added in code
position = 0.755, -1.28, -0.48
size = 245/40r17
tire = tire-touring
brake = brake-rear
coilover = coilover-rear
hinge = 0,-0.85,0
camber = 0.45
caster = 0.28
toe = 0.0


that being said, it seems like it would be much more complicated to link the rotor and caliper meshes... hmm, not sure now. :\



i like the textures in a comma delimited list. i think it should search filenames by: defaulting to the cars directory, then try the carparts directory and then try the data directory. first match it finds, it uses. mostly good for brevity. plus easier to change a car's directory location, or base a new .car on an old one. also, if there are somehow, branded rotors or some such it would allow for them to be attached to the single car.

[NaN]

first match it finds, it uses. mostly good for brevity. plus easier to change a car's directory location, or base a new .car on an old one

OK.

have all sections of the car include options for mass, position, mesh, and texture.

To be more complete:
mass, position, mesh, texture, inertia, rotation, mirror axis, color, draw type(emissive, blend, ...). All of them being optional maybe.

No named references, but optional components:

Code:

[brake-caliper-fl]
mass
position    // relative to wheel
mesh
texture

[brake-fl]
friction = 0.4
max-pressure = 4.0e6
bias = 0.65
radius = 0.14
area = 0.015
#mesh =
texture = rotor_shiny_slotted_drilled.png
position =
mass = 3
#inertia =

[tire-fl]
size = 245/40r17
type = slick
#mesh =
texture = touring.png
mass = 4

[coilover-fl]
mass
mesh = ?
texture
position
...

[wheel-fl]
mass =
mesh =
texture =
position = -0.736, 1.14, -0.47
hinge = 0, 0, 0
camber = -1.33
caster = 6.12
toe = 0.0
ackermann = 8.46    
steering = 30

I need a list of components(required and optional) we want to support. Any ideas?

[NaN]

It would be great if someone created a car template with all optional/required components. I'd make sure to implement it asap.

As for the >4 wheelers.

Code:

[wheel-fl]
...
# optional
[wheel-fl-1]
...

[NaN]

Dump your ideas here: http://typewith.me/q1VKrbBhYI

Edit: Added an initial incomplete config based on XS.car.

[zimluura]

made some changes with some brainstorming on how to do LHD ->RHD ingame


i mentioned a while ago that having a way to include the entirety of another .car file would be good for making alternate trim levels.

so the base.car would have most of the serious parameters in it. but then the gt_trim.car (or whatever) could just replace the engine, suspension, and spoiler.

perhaps inherit would be a better word than include (more c++ like). but it will help for data brevity - and allowing error corrections in 1 car file to propagate to any subspecies (trim levels).

a way to do interior colors would be nice. (and a list of stock colors for interior and exterior)

[NaN]

Looks good.

base.car would have most of the serious parameters in it

You could do this already using the include directive.

Code:

include base.car

The car selection routine would have to look for all available car files.

Any ideas about the GUI?
I think we should separate car and track selection first. Maybe move car selection into main screen.

Code:

Garage
Practice
Race
Replays
Options
Quit

Garage screen would contain a preview widget on the right and a number of selection widgets on the left. Currently we have the following options:

Code:

player = T73
player_color_blue = 0.950000
player_color_green = 0.200000
player_color_red = 0.172222
player_paint = 00

I think I should replace the color sliders by a color picker. Or should we offer a fixed palette only defined in the car file.

Code:

player_color = silver

PS: Be as creative as you can. I'll take care about the implementation.

[NaN]

What about having the car preview in the main screen too to make it a bit more appealing?

[zimluura]

didn't know the include parameter was there yet.


car selection in main screen sounds real nice. most games that have a career mode do something like that. i think it would be cool to see the car sitting in a garage (a small track) could start out with just a warehouse maybe. totally filling the background. with the buttons on the side.

maybe like top image here:
http://sites.google.com/site/zimluuraprojects/vdrift

a long time ago i made a skin for vdrift that had all the control bindings on one page, but still sortof categorized. wish i still had it. it was much quicker.

i think in each .car file there should be stock paint-jobs. but also you should be able to do the color picker.

could even list colors as rgb hex codes:
[colors]
exterior: 868686, F0F0F0, 070707, F00707
interior: 0F0F0F, 0A0905, 505050

or maybe a section to get the oem paint names
[exterior_colors]
mystic_blue=0020FF

[zimluura]

maybe a 256 color texture to indicate which parts of the gauge lights are visible at night. provided dynamic skies come back.

[NaN]

Having the car as the background of the GUI is so cool. I would go for transparent buttons with half-transparent text.

maybe a 256 color texture to indicate which parts of the gauge lights are visible at night

What about having an additional emissive texture like for the brake, reverse lights atm?

[zimluura]

that's probably better. it would be nice to have something that's in-game tune-able. (the first mod i did for my car was to change all the lights in the dash to blue): http://www.6gc.net/photo/member/3629/1

but there are all sorts of multi-light displays now, so it could be better to just have a true color texture. like this indiglo gauge from a google search:
http://home.comcast.net/~maxkool2/guages.jpg


afterall i could always modify gauges out of game to replicate my car.
would there be any shader produced glow/bloom? or should that be done in the texture?

here are the relevant pros/cons i can see:

texture (glowy texture)
pros: artist makes sure it's readable, less programmer work.
cons: more work for each car, no variation with ambient light.

bloom-shader on non-glowing texture.
pros: less artist work, variable glow as daylight changes (would look awesome as you drive into a tunnel!!!)
cons: more programmer work, artist will have to make sure each one is readable at highest glow level

i think the bloom shader sounds better. but i won't be the one having to write it.

[joevenzon]

Yes to the bloom shader. Author the emissive texture for the instruments without baked-in bloom. The way the bloom system works (or at least, *should* work, it's been a while since I've looked at it) is that the output of the lighting engine gets examined and very bright results get blurred and added back into the image. So if you supply an emissive texture, and if you had a way to specify a large multiplier for the emissive texture's contribution to the lighting model, it should get bloomed automatically.

[NaN]

If there are no further suggestions related to car config I will proceed with the implementation.