car components, damage, a new windows build

[zimluura]

now that i'm getting to the point with blender that i can contribute, i'd like to make a few feature requests. most of these i've mentioned before, but i figured it would be post them in the correct forum.

1) a new release (with a newer windows build) would rock.

2) ability to load several different meshes for one car so we can give different trim levels and body kits. absolutely needed for feature request 3

3) i'd really like to build a custom car out of 20 - 40 seperate objects (monocoque frame, bumpers, hood, fender, mirrors, doors, windows, engine, drive-shaft, differential, axles, etc), then it could be used for a damage test car. so then it could be slammed into a wall at insane speeds and really get broken to bits and catch on fire.

4) sorta think it could be good to do a universal tire model, maybe with different skins and parameters for each modeled brand. like inner radius, outer radius, tread width, psi. each car would just get it's own stock rim, and then of course there could be aftermarket rims.

5) have a car's diffuse map be white and then have a color wheel for paint selection.

[cotharyus]

Your request for number 4 is interesting. It's worth noting that the tires being used on each car are different. We don't have any hard specs for any real brands, so what's there is ....well, it's an educated shot in the dark, honestly. If we got to a point where we could, for whatever reason, make multiple tire types available for each car, I think the two main types would be standard and drift tires.

[zimluura]

the main reason i was thinking a tire model independent of the car would be good is because: when tire pressure becomes tune-able you could get an accurate visual representation of a deflated tire with a single unified tire model. and only one piece of code to control how the tire is deformed.

if each car has it's own tire, then each one needs to be rigged independently, and a change in how the game takes in data would mean every car has to get updated to conform to the new paradigm.

[joevenzon]

I think it'd be cool to have an independent tire model just because you could pick out rim designs you like, and then the game could scale them to the proper size.

Release time is very soon. The dev code is pretty danged stable.

[Kricor]

yeah, that would be cool.
an addition to that idea would be things like spoilers or body kits or other stuff that you could add on.

[zimluura]

i think adapting the .car file so you can have it load several different .joe models would be really good because modelers could start building cars out of sub-parts right now.

then later on the code could be added to provide:
* doors and hoods that open up (and get replaced with carbon fiber, then get ripped off in a crash)

* mirrors that fold (and then get removed for less drag, or possibly crack and break off if they weren't removed and you grind the wall)

* antennas that extend (or nixed during weight reduction)

* engine swaps that have a visual difference when you look under the hood (and look different when they're on fire)

but all that stuff will take lots of time to code and is probably far down the road. loading an arbitrary amount of .joe files for driving around the track is the first step and shouldn't be bad to code.

[thelusiv]

* loading multiple models - currently VDrift does load multiple models, they're just fairly narrowly defined (body, glass, wheel, interior).

* I like your idea about distortable tires and wheels, it would also be very nice to have changeable tire pressure, etc. and the ability to specify tires by their size codes instead of car authors having to convert that into physical dimensions. However, VDrift tire physics model is a complex one for which we do not have a lot of data, so it is not easy to adapt the system to changing sizes, inflation etc. There is a possibility of soliciting a sponsorship from a tire company to get real tire data but that's something that will have to wait for a better polished version of the game (which we may have soon!)...we'll have to see where that goes.

* Animated models - currently the model format does support animation afaik but VDrift does not use this functionality (we haven't needed it yet).

* lots of visual details: this is a common idea that only scales as well as the availability of artists who have time to make free models for the game. Maybe as the game gets more popular we will see more people willing to do this work; but for now most artists involved with the project are more focused on getting some cars made than filling in every detail including things that aren't usually seen during gameplay. While nearly everyone will agree that this stuff would be quite nice, the project's focus will probably remain accurate simulation of driving before perfect graphics.

* Destructible cars - this too would be very nice, but lots of work, see the last two points...

Generally in terms of game art, Joe tends to support whatever the artists ask for when they're creating things for the game. We'll have to see what happens when someone comes along with car modeling ideas that include things lie full frames, engines, transmissions, removable fenders, and animated antennas and mirrors.

[zimluura]

thelusiv:

most of the bullet points in my last post are things that will be possible with the code if a car's model is built in a very modular way. adding support for an arbitrary amount of .joe files (or at least a high amount) just means that cars can be built with an eye towards future features.

as for the strain on the art team i don't really see how it's increased - if you want to model all of the little parts, you can - if you don't the process doesn't change very much (perhaps at all).

i got allot of work done on the tc6 in truespace (just as a project unto itself) before i started moving it to blender, and from there to vdrift. but i built it with a bunch of seperate parts. so i killed a few hours in blender merging vertexes and deleting now un-see-able faces and useless edges. when i could have been fleshing out the engine bay and frame. all things considered i'm sorta glad i did go through all that because i now can model things pretty effectively in blender. but it would be really nice if, when i get the tc6 done and start on the next car, i could build the meshes in such a way that will allow the car to be expanded without a huge overhaul in blender. granted making models like that brings up the polycount, but it's probably still going to be pretty quick on hardware from two years ago.

as for the tires, again it's sortof a thought to adapt the art pipeline for future iterations of the code. whether there's a tire sponsorship for the game or just a large amount of fictional brands (and "imitations" created as community expansions for the game). at some point tire deformation & tuning of tires will likely be the *thing*, and at that time it would be nice not to have to take every car's wheels apart again and reduce it to a rim.

[Kricor]

also, before you guys get too far ahead, is it possible to disable damages? because I crash a lot when I go really fast :wink:

[zimluura]

i've been pondering this one a little bit more lately.

and i think the best way to do multiple meshes would be some kind of data inheritance system with the .car files.

say i was to model a c6 corvette, i could write/model all these files

cars/corvette_c6
engine_ls2.ini
engine_ls3.ini
engine_ls7.ini
engine_ls7r.ini
engine_ls9.ini
base.car - definition for c6 coupe, load LS2 engine - complex rotating objects (doors, hood, trunk)
base_2008.car - inherit base.car, load LS3 engine
convertible.car - inherit base.car, replace body, add functions for convertible top
convertible_2008.car - inherit convertible.car, reference LS3 engine
z06.car - inherit base.car, load ls7 engine, reduce weight, upgrade brakes, strengthen oil system, strengthen connecting rods, bigger wheels
zr1.car - inherit z06.car, load ls9 engine, reduce weight(more),strengthen body, replace fenders, replace hood, bigger wheels
c6r.car - inherit z06.car, load ls7r engine, add roll-cage, replace interior, add spoiler

cars/corvette_c6/models
body.joe
body_convertible.joe
convertible_top.joe (animated?)
fender_front.joe
fender_rear.joe
door_left.joe (mirror in code?)
trunk_hatch.joe
trunk_convertible.joe
hood.joe
hood_zr1.joe
fender_front_zr1.joe
fender_rear_zr1.joe
spoiler_c6r.joe
rim_base_5spoke.joe
rim_base_7spoke.joe
rim_base_15spoke.joe

and then there would be lots of 'vettes with a minimal amount of work being repeated or data duplicated for each one. but also, i could write the first engine.ini and then make a few meshes and we'd get the base model. then someone else could model a new hood and fenders and write up the latest and zr1.

and again, as an artist you could do it if you want, or you could keep them very simple, in which case it would still allow things like spoilers to be set for the higher trim levels.

cars that would be good candidates for something like this now are the gt/gtr, and the m3/m3d. mostly cause the meshes and textures would no longer have to be duplicated to get tweaked settings.

[joevenzon]

I like it. The way the CONFIGFILE format that the .car files use is set up, if you load in one file and then load another file, it'll keep settings from the original file and any duplicate settings in the new file will overwrite the ones from the original file. So what you're talking about with the .car file inheritance is very do-able.

Maybe the "higher level" .car files would have top-level parameters (not in a section) called include1, include2, etc that would specify other .car files to load first; so the vr1.car might have:
include1=base.car

Also, right now the names of the .joe files are always the same. It sounds like for this system to work we'd want the .car files to specify which .joe files to load, and do it in a way that the subsequent .car files could overwrite the names. So maybe there'd be a section in the .car file called [models] or something, and then the game would automatically load any values that are put in that section. So the base corvette might have:
[models]
body = body.joe
hood = hood.joe
...and so on

And then the zr1.car file would have the values that are overridden, like:
[models]
hood=hood_zr1.joe

There would probably need to be special logic to handle mirroring any models that have "wheel" in the name.

Anyway, just brainstorming, what do you think?

[zimluura]

sounds, cool!

i was also thinking to give each bracketted item [] the optional fields of: position, mass, and model.

so instead of even making a new field for a model list, you could just define more "particles" with meshes attached. though i'm not sure if arbitrary field options would be that easy to inherit-over.

something like

[door_right]
mass: 15
position: 0.6, -0.2, 0.1
model: mirror(door_left.joe, x)


now, at first glance this sounds un-necessary, and frankly it is

but it opens the way for allot of cool things in the future. with body panels you get easier damage implementations. and it would be very cool if, when in_game_upgrading comes around, and you decide to upgrade to a racing clutch, its position gets highlighted on the car. not that useful outside of edutainment, but pretty slick looking.

well for a clutch it could just use a generic cylinder mesh, shared between all cars, and not drawn unless you're at the hypothetical upgrade screen.

i'm not 100% sure but the mirror code should be to switch the +/- sign of all x coordinates. perhaps instead of defining it like this

model: mirror(door_left.joe, x)

it could be done like this
mirrorx_model: door_left.joe

that way, no tricky parsing of parenthesis