only thing that comes to mind that i haven't mentioned is some kind of detail flag for parts that could be applied to internal or difficult to notice parts. just for some intelligent lod type of stuff on things like the: engine, differential, suspension, seats, stereo, gauges, steering wheel, etc.
basically for stuff that doesn't need to be drawn on other cars unless you're really really close.
[engine]
model = ls1.joe
texture = ls1.png
options = detail
edit:
also maybe a flag that signifies the model has transparency and must be drawn after the others maybe??? so perhaps:
[gauge cluster glass]
render_options = detail, transparency
not really sure if this would be useful, my knowledge of the programmable pipeline is still very rudimentary.
zimluura Wrote: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.
My original intention when I wrote the GUI was to make a tabbed view widget to accomplish just that. However, it was difficult to make a tabbed view navigable by keyboard/mouse/joystick, which was one of my goals for the GUI (since Joe rewrote it a long time ago, only mouse works now).
But anyway, I think the best way to solve that would be to implement a tabbed view widget in the GUI, and put all the controls in the different tabs. A scrollable view widget might also be useful (although should probably be used sparingly to keep things simple).
tabs could be pretty cool.
maybe something like
[car] [transmission] [camera] [game] [all controls]
i experimented the gui skins a while ago. when additional skins worked.
i was going to post or svn my skin, but support for other skins died. since then the skin has been formatted over i think. i still remember that it was fairly easy to get into though. so if skin support returns i'll take another crack at it.
it seems like skin support is still somewhat there, but in game.cpp:2094 it is basically turned off by:
Code:
valuelists["skins"].push_back(pair<string,string>("simple","simple"));
the most likely reason i can guess is that nobody was maintaining the x1 or any other skins so there was no point in loading the data/skins directory to see what was available.
Yeah, skin support could easily be added back in.
I've hit some issues during car config implementation:
Moving wheel components are brake-calipers and wheel-fenders. Are you OK with the naming?
The driver is kinda misplaced, should be moved into carparts, meshes and textures renamed accordingly. I'd like to have car sounds there too.
The carparts directory should be renamed to "shared" maybe? What about moving the carparts directory into cars?
Car components in carparts directory have distinct directories. Parts could be moved into a single directory or the directories replicated in each car directory(having carparts as a template for cars) to make the loading code more uniform. What do you think?
The current light setup:
Code:
[light-brake]
texture = brake.png
mesh = body.joe
[light-reverse]
texture = reverse.png
mesh = body.joe
# optional lights
[light-brake-0]
position = -0.6, -1.9, 0.0
color = 0.8, 0.1, 0.1
radius = 1.5
[light-brake-1]
position = 0.6, -1.9, 0.0
color = 0.8, 0.1, 0.1
radius = 1.5
I'd prefer to have separate meshes/textures for lights:
Code:
[light-brake-0]
texture = brake_light.png
mesh = brake_light.joe
position = -0.6, -1.9, 0.0
color = 0.8, 0.1, 0.1
radius = 1.5
This means someone has to extract/create them.
Quote:Moving wheel components are brake-calipers and wheel-fenders. Are you OK with the naming?
wheel-fenders? those shouldn't move, should they?? or am i mis-understanding you?
i think, in the long run, drivers will want to be seperate of the car. so we can have more drivers to chose from, then you can stay as the driver you like maybe i make some more skins, or maybe people make custom skins. and multiplayer will be more colorful. eventually drivers should probably have a sub model for their head or helmet.
i like carparts being a separate directory. it makes sense to me when i look at the file-system. renaming it to be "shared" might be good. but there will probably be a "shared" for track objects (road-cones, trees, grass-tufts) and i would think it good to keep them separate.
but after all of that i'm not much of a programmer for vdrift. and programming is more difficult than art. so if it makes allot of sense to the programmers to do it that way then that should have some weight.
the thing i'd really like to see is that the parts be somewhat arbitrary. so the car creator, if he's modeling a delorean or something, has an option to put in separate gull-wing doors and flux-capacitor meshes. without the car loading function having to change to support just visual loading of those nodes. granted, of course there would be code needed to get the 88mph effect, but we'd at least see the part show up, and be able to rip it off during weight reduction without any new functions being written.
i think separating the lights is a good idea. i'll put in some work on the light extraction and rebuilding. note that if we can use the same mesh with a flip-x coordinates option, it will save some disk-space and effort.
Quote:wheel-fenders? those shouldn't move, should they?
With fenders I mean cycle type fenders like the ones on the caterham. Maybe they should be called cycle-fenders.
Quote:so we can have more drivers to chose from
I want to allow the user to choose the driver. Right now all driver meshes are called body.joe. And the driver path has to be passed as parameter.
Code:
[driver]
texture = driver2.png
mesh = driver2.joe
position = -0.38, 0.023, 0.1
mass = 90.0
Quote:the thing i'd really like to see is that the parts be somewhat arbitrary
That is what I've planned too(have an incomplete implementation lying around), being able to assemble any number of components together to create a car. But I've got the impression it would be too complex for the user. Thus, I've decided to switch back to predefined components.
To be honest. I'd prefer to have mesh, textures, sound directories and share all data. A car would be defined by a config file only.
Quote:if we can use the same mesh with a flip-x coordinates option
Let's pretend it is available.
Quote:so if it makes allot of sense to the programmers to do it that way
The problem is that I am biased towards the implementation. What looks great to me might be unusable for the user/artist. I wish I had a requirements spec to implement.
Quote:But I've got the impression it would be too complex for the user. Thus, I've decided to switch back to predefined components.
i think this will be ok for the average car creator. so long as the wiki documents which parts are required.
i like having a shared data folder, but most cars would want 100% custom meshes for that car, and it give's the car some semblance of being self contained. at least in what they don't use from the carparts directory.
with it this way will be nicer if the number of cars increases allot. because making the limited install with only 4 cars available, won't be tons of work.
Yeah, it's fine to share as many assets as possible but I'd want the user/car creator to have the option to supply additional assets that aren't shared in a self-container folder so someone could make a unique car and then distribute just the folder to others.
NaN Wrote:The carparts directory should be renamed to "shared" maybe? What about moving the carparts directory into cars?
Maybe named it "_shared" to help it stand out as a special directory, both to users and to code (easy to ignore "_*" when getting a list of available cars), and also to make it sort at the top when viewing an alphabetically-sorted directory list of data/cars/.
Does support for data in ~/.vdrift/ still exist? Just wondering, not sure if people developing cars use this or not - I didn't when I was. I just made sure VDrift used the data directory I have in my $HOME, and worked out of that.
Skin support is back in R2888.
cool, started to try to remake the skin i was working on 2 years ago. but a few things have changed that will make it not-possible.
setting button sizes to anything other than auto seems to leave them as auto. which won't look so hot with anything not center justified.
also, a few widgets of the key binds seem to always be in the center of the screen, which means i won't be able to stack 3 columns of controls.
don't know how easy this will be to fix though. so if it's a no-go, i'll still try to put together something that will work for when/if we get a visible garaged car in the menu screen.
Quote:self-container folder
One way would be to replicate the data folder structure.
xs.zip
--meshes
----xs_body.joe
----xs_wheel.joe
--textures
----xs_body.png
--sounds
----f20c.wav
--cars
----xs.car
The user would have to extract it into the data folder. This is not a proposal, just fooling around.