Forums

Full Version: tire idea
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
so, for a while now i've had this idea for a general purpose tire model. one that could be used on all cars and modified in code. to fit the bill for any tire from a tricycle to a monster-truck.

been working on a little concept model for it.
http://picasaweb.google.com/zimluura/VDr...6677463890

so this one is 448 faces. 32 segments around and 7 segments inside to out. the walls of it are unwrapped so the texture can be written on with regular straight-line text and the skin mapping handles all the text-warping.

as for geometric deformations. ideally it'll look sorta strange in blender. basically i'd have each ring be a set distance from the hub (ring 1 is 1 unit, ring 2 is 2 units, etc.). and have each ring's in/out set at 1 or negative 1. then when the game loads the tire model for the first time it could calculate distances from the center. and then cache a little list to for which vertex numbers belong to what ring.

after all of that you have a tire that should be easily deformed (scaled and translated) with parameters in code. couple that with a custom texture (which is easy to make with the skin mapping how it is. and you should be able to get nearly any tire.
zimluura Wrote:as for geometric deformations. ideally it'll look sorta strange in blender. basically i'd have each ring be a set distance from the hub (ring 1 is 1 unit, ring 2 is 2 units, etc.). and have each ring's in/out set at 1 or negative 1. then when the game loads the tire model for the first time it could calculate distances from the center. and then cache a little list to for which vertex numbers belong to what ring.

I didn't quite follow this. Is the idea that this would help the game resize the tire for different sizes?
sorta. but more to make the mesh as simple as possible for the code to understand. i guess it's not *really* needed because if you crunch distances from origin to vertex each ring should have roughly the same distance. which, in most cases won't be the same as any other ring (barring inside wall vs. outside wall, which is easy to figure out by +/- of the x value).

but once the game has identified which vertices belong to which rings it should be pretty easy to scale them (for y & z) and translate them (for x). and from there only slightly more complex to type in the code found on the side of each tire. and have the appropriate tire generated.

as with all 3d space discussion it's sorta difficult to understand one person's written description. was that better?
So the game would resize the tire from the radius, width, and ratio information, right?
yeah, as far as i can see those are all that's needed for defining a tire's physical structure.

does it sound like a good idea? or not so much?
It sounds like a good idea to me, although it almost makes me wonder if the geometry could be generated completely by the code.

Interchangeable wheels would be cool, too.
yeah, it could be done all in code for sure. i mean, blender does tht kind of thing when you request a torus. which it seems is called "add_mesh_torus.py" in the scripts directory. i'd guess it's allot like that but figuring out where to not generate vertexes on the inner doughnut*.

most i've done with building meshes in code is getting a heightmap mesh from a gray-scale image. and once me and a friend built a non-smooth sub-divide routine that worked on a quad. both of these were pretty grisly to work on, but ultimately rewarding.

doing the texture coordinates sounds more complicated than doing the geometry, but it shouldn't be that bad.



i was trying to think of some ways to do a rim system where you'd get to select your visual style and then select how many spokes you wanted and then rim diameter. and while it's all do-able the only way i could think to do it *right* would want the mesh exporter recognizing vertex groups so certain patches around the hub (like the lug-nuts) wouldn't be scaled when you went from 13" to 18". also welding together the hub vertexes of spokes doesn't sound fun, and i don't think it could be done in such a way that scaling the spoke count wouldn't create bulges or kinks where the vertexes were welded.

yeah, change-able wheels would be sweet. if you do the tire idea i can try to re-make all the other car's wheels to just have the non-tire part. of course if the original .blend files are around that would be nicest.


and speaking of tedium! i did all the driver re-positioning a while back. but then began the discussion of the coordinate system inconsistencies. and then came the re-factoring of top level code. then i made the dudes head bigger to be more realistic, meaning i'll have to do re-check the positioning for each vehicle.

and i'm wondering: should wait to re-check driver positioning until the coordinate systems are all consistent (which i'm guessing will happen in the re-factor branch)?
For the wheels I was just thinking a simpler system like give a few preset wheel styles and then scale them up/down depending on the radius.

If I were you I'd wait for the refactor to re-do the positioning... although it might be a bit until I get there. :-)
yeah, something simpler is probably better. though, correct me if i'm wrong, but the lug pattern shouldn't scale. maybe assign vertex groups for those? and then export that from blender too?? only problem i see is different cars maybe having different patterns.

brake rotors and calipers are something that should, in some ways, be generalized as well. mostly because the rotors need to spin with the wheels and the calipers need to to turn with the steering and travel with the suspension but not be constantly spinning.

each car could have it's own stock wheel set and maybe even rotors and calipers. and then also have an aftermarket pool of every other wheel style.

i'm plenty fine on waiting for the refactor. big projects just take time Wink