Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
tyre/tire selection
05-31-2010, 04:42 AM
Post: #1
tyre/tire selection
Pool of tyre files for all cars and a list of the tyres that can be used in the .car file for each car.
Find all posts by this user
Quote this message in a reply
05-31-2010, 01:20 PM
Post: #2
 
I think there are tire files in the carparts folder. I don't know why they are separated in front and rear though. Are the coefficients dependent on tire dimensions? What about joining them, having a tire folder containing tire files?

As current vdrift-data is incompatible to the previous release anyway. I propose the following tire description instead of the current one:
Code:
[ tire-front ]
radius = 0.29
rolling-resistance = 1.3e-2, 6.5e-6
rotational-inertia = 3.0
tread = 0.0
type = touring
Find all posts by this user
Quote this message in a reply
05-31-2010, 07:23 PM
Post: #3
 
just made a few tire textures today. rain, slick, and ye_olde (which will look more medieval).

as soon as someone who knows more than me integrates the wheel edge, i'll go through all the .car files and size the tires with the vehicle default tire codes.

i think after that the wheel section in the .car file will get super small

[ tire-front ]

size = 225/50r16

tire_type = rain
pressure = 35.0
wheel = 5_spoke_m

wheel_material = magnesium
rotor = 360
rotor_type = ceramic_slotted


provided each wheel gets some default steel masses associated with them, the radius, contact patch, and inertia should be able to be figured out with equations.
Visit this user's website Find all posts by this user
Quote this message in a reply
05-31-2010, 10:14 PM
Post: #4
 
The carparts folder was an old unused scratch pad (from car customization setting implementation ideas from long ago) until the wheel mesh generation data got put there. Feel free to restructure and remove as is warranted; nothing that's there is there for any reason (except the wheel meshes and textures).
Find all posts by this user
Quote this message in a reply
06-01-2010, 04:19 AM
Post: #5
 
Quote:as soon as someone who knows more than me integrates the wheel edge
r2774

Quote:rotor = 360
rotor_type = ceramic_slotted
Rotor is brake disk diameter? If so can we can use brake parameters.

Code:
[ brakes-front ]
max-pressure = 2.5e6
bias = 0.65
area = 0.000688 # 21.5mm x 32mm
radius = 0.355 # 355mm
type = ceramic_slotted #friction = 15.0
Find all posts by this user
Quote this message in a reply
06-01-2010, 04:23 AM
Post: #6
 
Wow, the 360 has 355mm brake disk radius(we should rename it to diameter).
Find all posts by this user
Quote this message in a reply
06-01-2010, 05:25 AM
Post: #7
 
Quote:355mm brake disk radius
lol
Quote:Rotor is brake disk diameter?
Yep, one and the same.
Quick note while thats getting some lovin', a disk temp variable would be usefull for both disk glow and brake fade and is simple to calculate.
Find all posts by this user
Quote this message in a reply
06-01-2010, 05:44 PM
Post: #8
 
wow, awesome!

i'd been updating the source dir frequently, even had r2774 compiled. but it was crashing. then i tried to run it from a console and saw an error that prompted me to update the data dir.

silly me.

i think sometime in the next 2-4 days i should be able to do lots of car data updating. and finish building the brake rotor code.

[edit] on the brake rotor: yeah, it probably should be in the brake section. was just thinking that we'd need to know some details on the rotor to calculate the wheel's inertia. hmm the wheel hub and axle weights as well. or some approximation of them.
Visit this user's website Find all posts by this user
Quote this message in a reply
06-02-2010, 02:36 AM
Post: #9
 
all the shared wheel meshes should be updated in the data and art svns.

i fit the 350z with the its shared wheel mesh and it doesn't quite look right. i was going to move it's wheels outward a little, that will be easy, but it's something else. the mesh for the pentagonal_hub is very thin so how to handle the offset of the wheels is what needs to be considered.

sorta want to know some of how you guys are planning on the offset before i go and put oem wheels for each car (just in case i'll need to go through each blend file again.)

got the z06 updated with properly sized mazda wheels (wheels moved outward and lowered a little). will get its original wheels put in its directory soon.

==
a few different tire textures in the carparts/tire/texture directory. left the single tire texture in the wheel directory so as not to break anything until the code gets changed a bit.

at the moment tires are being mirrored as well as the wheel_edge. is there any way to make the wheel edge mirrored and the tire non-mirrored? i ask because the tread pattern, and arrows aren't symmetrical right now. but i think, with regard to open-wheel cars we will want the outside rim_edge to maybe have some detail that the inside wouldn't.

the part i'd intended to be the outside of the wheel_edge is currently on the inside. should i fix that in the mesh_gen functions? or is it very easy to rotate after they are called?
Visit this user's website Find all posts by this user
Quote this message in a reply
06-02-2010, 03:18 AM
Post: #10
 
Quote:how to handle the offset of the wheels is what needs to be considered
It should depend on wheel rim width somehow. The outer spoke vertices should have the coordinate zero to keep them independent from scaling. The question is how to determine the offset d. maybe a parameter in car settings?
[Image: WheelsFAQ-4eoq.png]

Quote:at the moment tires are being mirrored as well as the wheel_edge. is there any way to make the wheel edge mirrored and the tire non-mirrored? i ask because the tread pattern, and arrows aren't symmetrical right now.
The tire and wheel are 180° rotated around up-axis(z-axis). I haven't changed this yet. There are two ways to deal with it. Having four meshes and mirror them accordingly on setup using negative scale. Or keep two meshes front and rear and mirror them at draw time(mirror the scenenode). I am undecided which is the better way to do it. Do we want to have four distinct wheels(meshes)?

How should we deal with flangeDisplacement_mm? I have it hardcoded atm.
Find all posts by this user
Quote this message in a reply
06-02-2010, 03:43 AM
Post: #11
 
There is a better idea. Create the spokes mesh assuming a rim width = 1.0. We will scale it using the real rim width to fit it to the tire.
[Image: WheelsFAQ-2flj.jpg]
Find all posts by this user
Quote this message in a reply
06-02-2010, 04:48 AM
Post: #12
 
Quote:sorta want to know some of how you guys are planning on the offset
Kind of obvious but width also needs to be handled.
Find all posts by this user
Quote this message in a reply
06-02-2010, 11:48 AM
Post: #13
 
Quote:The tire and wheel are 180° rotated around up-axis(z-axis). I haven't changed this yet. There are two ways to deal with it. Having four meshes and mirror them accordingly on setup using negative scale. Or keep two meshes front and rear and mirror them at draw time(mirror the scenenode). I am undecided which is the better way to do it. Do we want to have four distinct wheels(meshes)?
i had thought just two meshes (front, back) for tires (might be able to optimize that more, lots of cars have the same size tires f&r), and then two more meshes for front and back wheel, but alter the drawing routine depending on the content being rendered. would that mean a different scene node?


Quote:How should we deal with flangeDisplacement_mm? I have it hardcoded atm.
i had thought that each wheel style would have it's own definition file maybe. or maybe each style would be in one big definition file. and there the flangeDisplacement could be defined by the wheel artist, if they so desire.

Quote:There is a better idea. Create the spokes mesh assuming a rim width = 1.0. We will scale it using the real rim width to fit it to the tire.
this sounds like it will work. i think there might end be a problem when i get the brake rotor going...which i should go finish up now...maybe gotta get some caffeine first. i was leaning toward all the wheel vertexes being just barely on the + side of the x axis. thinking if we did it that way we might more easily be able to position the wheel_edge. but then we'll still run into problems with the rotors... i'm good for trying this, so long as none of these positional thoughts raise a red flag for you, i'll start doing more stuff after i get the rotor built.

Quote:Kind of obvious but width also needs to be handled.
i think width is handled for the time being. give it the tire size and it automatically spits out a perfectly sized wheel_edge. i'd like it to be more realistic, but i think there needs to be some kind of player parts inventory and part buying system before it can really be done the _right_ way. or am i misinterpreting you? Smile

musing: a while back i was trying to make a garage scene in blender, maybe to one day turn into a track where you could see the cars you had bought. when/if there is a parts inventory we could have all the spare parts stack up in the garage to give it clutter.
Visit this user's website Find all posts by this user
Quote this message in a reply
06-02-2010, 05:05 PM
Post: #14
 
Quote:i think width is handled for the time being
Not for the physics, nan hard coded it for the time being when the wheel mass was added to the physics.
Find all posts by this user
Quote this message in a reply
06-03-2010, 02:07 AM
Post: #15
 
The width has been hard coded for the experimental code path only which is not used by default. I was to lazy to write the code to handle this.

Quote:we'll still run into problems with the rotors...
What if we use a fixed offset for all wheel meshes, like 0.15 or something. The real offset would be known as 0.15*rim_width for brake positioning.

Quote:garage scene
A garage screen where you can select/setup your car, hehe.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)