VDrift Graphical Upgrades

[zimluura]

the segments around the tire are adjustable. i've done 3 segment tri-angular wheels, and the highest was like 1024 segment super smooth.

the segments for the sidewalls and treads are not adjustable. i'm sure this would be do-able. but i think the function will need to have an arbitrary amount of 2d vectors to define the sidewall bulge.

i was thinking we'd (i'd) have to rebuild all the existing rim meshes. make them all have a 1meter radius (maybe a 1m depth as well for simplicities sake) and then get scaled. if the importer can get the wheel back into blender, than this should be just a little tedious. i envision each car having its own default rim-style(s). and then a whole bunch of after-market styles. and yeah, all would be done by hand.

do you think i should build a similar mesh construction function for the outer edge of the rim? and how about the brake rotor.

also, been pondering lod. because the tire is the tough one and is out of the way. it should be fairly easy to write low-lod functions for all of these too. the tire lod would have an outside wall, and a tread. the rim edge the same. and the brake-rotor-lod could even use an alpha-blended textured quad (with the same texture as the regular rotor.

here's the app with source if you want to look it over
http://sites.google.com/site/zimluuraprojects/code

edit - that code is a little bit messy - mostly 'cause of some half-written uncalled functions and that don't do anything yet. and it includes GLee (which isn't used at all).

[joevenzon]

The plan to make wheels by hand that are normalized to a standard width and radius so they can be scaled sounds good. I'll look at the code, but if you want to play around with making your function output into a VERTEXARRAY class from VDrift, feel free. :-)

[zimluura]

ok.

i guess i'll give it a try.

i put a sketch up on other circular things that should be not-to-bad to generate in code.

the sketch is here too. the direct url looked nasty
http://sites.google.com/site/zimluuraprojects/vdrift

[zimluura]

oh, this conversation has been posted, cool. i was just now wishing i had posted instead of pmed.

i now understand how vbos work allot better. i'm certain the tire mesh code is a little off. in the app it is written for immediate mode rendering where face indexes have their own texture coordinates rather than each tex coord having to be sent to the graphics card with the vertex. but when i see, exactly in what way it's off, i'll be able to make it work exactly how vdrift wants it. i'm thinking i'll be able to get rid of 30% of the lines.

what i need to talk about right now is the rims. i've been doing a few of them. and sizing them at 1.0x1.0x1.0 is probably not such a great idea. it means scaling the rim to be all super thick and bulgey in blender. which means it won't look anything like it would in the game. so i'm thinking we make the rims in blender so that they fit inside a 1.0m radius(or maybe diameter??) circle just as if that circle were the edge of the rim (the to_be_generated rim edge that will have the same number of circular segments as the tire). then the artist makes the thickness of the rim whatever looks correct. finally (in code) we scale the whole thing (xyz) by a single scalar so it fits in the rim edge just as it did in the circle. and the thickness of the spokes (and vertex normals for that matter) get don't need to be recalculated.


i've been making rim.blend files in the car's directory. since i'm re-importing the .joe files anyway i'm wondering if it would be good to leave the .blend files in the directory so people could modify them more easily. or should there be another data resource maybe for blend files? is there an easy way to add them to the regular data repo with a flag that says they're not downloaded unless specifically requested. so the bandwidth cost doesn't go up for people who just want to play the game?? would there be any legal/ethical reasons for not posting the .blends for the cars??

anybody have any ideas on the many questions i'm posing?

[nomoo]

Idea about repo: cars.vdrift.net

[joevenzon]

You should put the .blend files into the VDrift-art repo:
http://svn.vdrift.net/repos/vdrift-art/trunk

Feel free to create a new folder for rims or organize however you want.

I think I gave you access to it when I gave you access to the other repos, but send me a PM if not.

I think modeling the rim at a standard size that looks good and can be resized in code sounds great.

[zimluura]

i'm thinking maybe under each car we have a /blend directory.

and the cars.vdrift.net will be just to download the cars without the .blend files. in the interest of saving a little bandwidth.

there could be some usage license ramifications with have rim and car .blend files around for the taking. really the .joe files offer the same thing, but it's a little more of a process to use them.

does anyone have any thoughts on this? or is it mostly a "if a car author tells us to stop, we will"


on a more technical note:
most cars will be able to do just fine with a rim.joe and a rim.png in their directories. 'cause the game engine will be able to resize them just fine. but the tyrell will probably need a special case for the front rims to look pass-able. not really sure, most cars don't have anywhere near that kind of size difference.

[joevenzon]

most cars will be able to do just fine with a rim.joe and a rim.png in their directories. 'cause the game engine will be able to resize them just fine. but the tyrell will probably need a special case for the front rims to look pass-able. not really sure, most cars don't have anywhere near that kind of size difference.

Maybe an optional rim-rear.joe and rim-rear.png?

[zimluura]

i've been doing most of the importing on the wheel-rear.joe. i think it's probably best to start with that one as a base and then maybe an optional rim-front.joe, 'cause the rear wheels are usually bigger.

but if it's still in the plans to have a more freeform .car file and mesh loading setup at some point in the future. we could get by without a special case until that happens. actually, it was probably foolish for me to worry about the front wheels looking like they've been shrunk too far. most people will notice first that there aren't enough of them.

right now i've imported the rear meshes into blender files for cars 360-tyrell. been trying to do this assembly line style. some of them i've removed the tire from. then i think i'll put the hollow cylinder in each .blend file as a not_to_be_exported guideline mesh. since we'll have a rim diameter number coming in (from the tire code) i guess it should be a 1.0 diameter circle.

[zimluura]

progress report:
all the way up to the MI on importing and resizing. the importer brings them in with their normals flipped, so i've been flipping them back. not really a bother, just wanted to mention it in case it means i'm doing something wrong.

wikipedia says the term "rims" is a misnomer for "alloy wheels" so i've been doing my best to change the way i say it and the way i name the files.

here's a list of cars i've encountered with shared rim...er, _wheels_
360, 350z = pentagonal_hub
g4, gt, gtr = 10_spoke
m3, m3d = 5_spoke_magwheels
3s, m7, m8 = 5_spoke
fe, tl = snowflake

when there's a shared wheel, i'm putting it in the carparts/wheels/blender_files directory
when the wheel is not shared i'm putting it in cardir/blender_files/oem_wheel.blend. with the hope that we get each car eventually having a true oem style in its own directory and then aftermarket wheels which can be put on any car.


i've got lots of design questions relating to texturing, and mesh positioning,, they'll have to be answered at some point. but thinking about all of them is a little daunting 'cause there are so many. maybe best to wrestle with them after integration.



edit: can't get the RS2's wheels to import:
Traceback (most recent call last):
File "/home/zimluura/.blender/scripts/import-joe.py", line 64, in bevent
joe.to_mesh(Blender.sys.basename(g_joe_filename.val), image)
File "/home/zimluura/.blender/scripts/vdrift.py", line 318, in to_mesh
self.frames[i].to_mesh(name, image)
File "/home/zimluura/.blender/scripts/vdrift.py", line 266, in to_mesh
uv = [Vector(self.texcoords[ti[0]].uv()), Vector(self.texcoords[ti[1]].uv()), Vector(self.texcoords[ti[2]].uv())]

if it's not a big deal we can just point it to one of the shared wheels.

[zimluura]

done with all importing and resizing.

need to set the x-position of the wheel to be where exactly?
the very center of the hub maybe? should be better for physics, but might require inserting certain offset parameters to get it to mate with the generated wheel_edge, and generated tire.


also there are lots of duplicate vertexes after an import (guessing it has to do with vertexes that have more than 1 texture coordinate). i feel like i should remove them in the .blend files. any reason not to?

[NaN]

there are lots of duplicate vertexes after an import

"Remove Doubles" in Edit Mode should be fine. Could you try to export a wheel without double vertices and reimport it again. Just to check if the exporter/importer is the problem.

can't get the RS2's wheels to import

I'll look into it asap.

[zimluura]

opened the z06 wheel and removed doubles, 90 of them. then imported it again. no doubles and the normals are facing the correct direction.

this sorta reminds me of a thread where joe told me the tc6's wheels had their normals flipped, it was due to blender diong a -1 scale when you tell it to mirror. and how you have to ctrl+a -> apply scale and rotation. to get things to pan out. maybe all the wheels had their normals flipped? but i remember sorting out the problem with the tc6 wheels and correcting them. when i imported them this time their normals were flipped. strange.

does vdrift modify the .joe file the first time it loads one to be easier to open quickly? could it have been edge split? does the joe importer import normals?

[NaN]

can't get the RS2's wheels to import

This was because the wheel mesh doesn't have texture coordinates. When I rewrote the exporter/importer I assumed that all joe meshes would have texture coordinates. I updated vdrift.py to support joe files without texture coordinates.

had their normals flipped

This happened due to a bug in the old exporter.

does vdrift modify the .joe file

No.

does the joe importer import normals?

It will import vertices, normals and texture coordinates.

[zimluura]

groovy, that did the trick. now got the rs2 imported, de-tired, and scaled as well.

now for some texture design questions:
the wheel_edge mesh, which will have to be dynamically generated so it can fit the tire we generate. how do we do texture coords for that.

distinct possibilities i see are
1) have a strip at the bottom of the wheel texture that is for use by the wheel_edge.
2) it has it's own texture(s). in which case there is a chance of mis-matched colors until there is an in-game colorization option.

i'm a little more in favor of option 2. since in-game paint selection is in the plan. but what does everyone else think?