VDrift Graphical Upgrades

[zimluura]

ahh, got it, thanks!

that makes sense. after i got those fixes, i found that the indexes on triangles was a little off as well (noticeable mostly when you set the segments around to be like 8 or so). i'm going to take a few more stabs at righting texcoords before i check in the update.


[edit1] and i'll go through adjusting positions (and getting tire codes) on all the cars once the wheels are being draw proper.

[edit 2] texture coordinates fixed and checked in. i feel so accomplished. right now the tire rotation direction arrows only work for the tires on one side of the car. but the texture setup should allow it to just_work if the tire is transposed instead of mirrored. some odd lighting stuff is occurring. nowhere in mesh_gen_tire have i done any normal calculation, i'm guessing i should add that maybe?



before i execute the great wheel repositioning of 2010, i should make sure the tire is 100%, and also make a wheel edge. the reason being that we'll probably have to address a wheel's hub offset if we want to get these things _right_

[joevenzon]

The UVs look good now. Yeah, you need to add normals.

By "wheel edge" do you mean the interface between the wheel and the tire? Because yeah, that could use some work; right now you can just see through the tire there. Are you thinking that would be part of the tire autogen or the rim .joe files?

[zimluura]

i got some normals. at least semi-work-able ones. been sorta puzzling on how to get them all calculated correctly and quickly. i'll commit it today so they look pass-able for the time being.

the wheel_edge was going to fill that blank space. i think it will need to be another autogen mesh, that way it can use the wheel.joe texture (a strip at the bottom of the texture seems like a work-able idea). and always have the same number of segments as the tire. and hopefully tie them together nicely.

after i get the normal directions sorted out, should i bother the cpu to get them normalized? i haven't heard of a lighting model that uses their magnitude, but that doesn't mean it doesn't exist

and is, there any way to alter a shader to have it draw vertex normals extending like little hairs off the vertex?

[NaN]

should i bother the cpu to get them normalized

A lot of lighting models are using dot/cross products with the surface normal so normalizing it is a good idea. The speed shouldn't be an issue. We are not going to generate wheels per frame.

any way to alter a shader to have it draw vertex normals extending like little hairs off the vertex

Write your mesh into a file(you can use std::cerr) in obj file format and check it in blender. It's really simple.

obj file format (from wikipedia):

Code:

# this is a comment
# List of Vertices, with (x,y,z) coordinates.
v 0.123 0.234 0.345
v ...
...

#Texture coordinates, in (u,v) coordinates.
vt 0.500 -1.352
vt ...
...

#Normals in (x,y,z) form; normals might not be unit.
vn 0.707 0.000 0.707
vn ...
..

#Each face is given by a set of three indices each to the vertex/texture/normal
#coordinate array that precedes this.
#Hence f 1/1/1 2/2/2 3/3/3 is a triangle having texture coordinates and
#normals for those 3 vertices,
#and having for the vertex 1 (1/1/1) the vertex 1 from the "v" list, texture coordinate 1 from
#the "vt" list, and the normal 1 from the "vn" list; then for the 2nd vertex:
#the vertex 2 from the "v" list, texture coordinate 2 from
#the "vt" list, and the normal 2 from the "vn" list; for the 3rd vertex:
#vertex 3 from the "v" list, texture coordinate 3 from
#the "vt" list, and the normal 3 from the "vn" list
#NOTE: The list of vertices, etc. is one-based-indexing (meaning the first vertex in the file is v1).

f v1/vt1/vn1 v2/vt2/vn2 v3/vt3/vn3
f ...

[NaN]

Maybe we should add a PrintObj(std::ostream & out) function to the vertexarray class for debugging purposes.

[joevenzon]

There's support for this already, although it's not as straightforward as it could be. Create a MODEL_OBJ object, call MODEL_OBJ::SetVertexArray with your generated vertexarray as an argument (it will do a deep copy), then call MODEL_OBJ::Save.

[zimluura]

morphed my previous tire test app to use a vdrift style vertexarray.

should be useful for the rest of the mesh_gen stuff too 'cause it works easily in codeblocks and has a quick compile/link time.

just got it drawing vertex normal "hairs".

[zimluura]

adapted the test app to use a 3d only skeleton that looks like vdrift's mathvector.
tire normals should be good now. updated visual demo here
http://sites.google.com/site/zimluuraprojects/code

will start on the wheel_edge soon.

[zimluura]

got a few questions that you guys might be able to help me out on.

first one is artistic vs. performance: pondering 4 different designs for wheel edges.
first image here
http://sites.google.com/site/zimluuraprojects/vdrift
A will look ok from common view angles
B will look ok from all angles
C will look good from common angles
D will look the best from all angles
poly and vertex counts mostly go up proportionally as the letter approaches D. lots of vertexes will need doubles because we'll likely want somewhat hard angled lighting. i think B and C might have the same vert/poly load.
with 32 segments the tire is 264 verts and 448 triangles. so i'm guessing option D will be somewhere around that number.

second is artistic vs. complexity. since the wheel edge is mostly a sort of lip. should i include tweak-able parameters for making it bevel inwards and another parameter for how thick a wheel is? i think i'm in favor of this, but if it makes wheels too difficult to define then maybe not.

third question is a technical one about tires. does the measurement of the wheel_width equal the tire's section width?

[NaN]

A and C will be a problem with open-wheel cars(f1,...). I would go for B or D. We could fake the lip(flange) thickness using a normal map if we had some.

third question is a technical one about tires. does the measurement of the wheel_width equal the tire's section width?

I found this one:

A P205/60R15 has an approved rim width range from 5.5" to 7.5". http://www.tirerack.com/tires/tiretech/t...widthrange

[joevenzon]

I vote for B.

[zimluura]

thanks nan, that diagram is a better explanation than i could google up. hadn't considered the open-wheel cars, just really super low angles.

that makes 2 votes for B, so i'll start doing that. if something else comes up that makes it the wrong path, well it'll still be some mesh gen progress.

might have to alter the tire geometry a little bit since a little of a tire's inner radius is covered by the wheel's flange.

[edit] got b mostly set up now. anyone know how much the average wheel flange hangs over the tire? maybe 5% or 10% of the tire's sidewall height?


[edit2] since most of the harder stuff on the wheel edge is done i was thinking about getting a brake rotor together.
of course we want an outside circle. and i was thinking i'd make a cylindrical strip to wrap around it. at first i wasn't thinking about doing an inside circle to cap the cylinder. but the open wheel car models might need one.

normally can a driver of one of those see the brake rotor from the driver's seat? and should there maybe be a hand-modeled hub assembly for the open-wheel cars?

on the lower poly side of things it could just be a textured quad with an alpha texture.

any thoughts?

[zimluura]

hmm, didn't get any replys on the previous edits. figured that might save bandwidth, but maybe people can't see em.

anyways, the wheel_edge is up. not integrated though. this time i built it inside a vdrift style vertex array which loads the same tire function correctly so it shoudl work as soon as it's added. there may be varous tweaks to apply to these two functions up near the top under the "if (true)" statement that could make them better proportioned.

to update the 5_spoke with the new texture (i think i need to put a back on the rim as well maybe) i'll need to check out the art repo. do i have commit access to that one?

still not quite sure on the favored way to build rotors. any thoughts?

[NaN]

i wasn't thinking about doing an inside circle to cap the cylinder

I would go for a capped cylinder. I don't think we are going to lose fps because of this.

Maybe the brake disks should go in a separate mesh/drawable to be able to let them glow?


Cars with drum brakes or other stuff will have to provide custom meshes that override the default disc brakes.

[NaN]

Forget about the separate mesh the glow could be done using an additive texture.

I think we should workout what materials we want to support in which way.

Right now we have a material texture(surface properties), a diffuse texture with transparency. Object color with alpha to adjust whole object transparency (and color?). There is the diffuse color, vertex color blending hack. And then there are up to two additive maps that are not influenced by lighting.