Whats in your RIG?

[Slinger]

Ok I'm really tired right now, but I decided I should finally write on the forum. I was away over the weekend, but I had possibility to work a bit on the 0.06_cleanup branch. But the recent days, I've been playing with debian gnu/kfreebsd... and hl2. But I'll get back to coding in a day or so (currently got an half done version of "get_word_list" that uses c++ abstraction: less+cleaner code = win! and I'll do this with many other things as well )


Ok first of all:

WTH is with the makefile man O_o make -f Makefile.doze ? that's a pain in the neck to type out you know. It also created a bunch of .o files in the src directory.

Anyway, there's a "division by 0" somewhere in loaders.c, but it compiled and runs fine. Seems a bit laggy, but may be due to my laptop sucking.

That's the new makefile approach: instead of having both normal (that should work on "all" systems) and windows specific build solution in one makefile, use different files. but look at it this way: you don't have to type "win32-static" anymore (and if it really annoys you: just replace "Makefile" with "Makefile.doze"...

or simply add something like the following to your "~/.bashrc":

Code:

alias build='make -f Makefile.doze'

ans you will be able to compile rcx just by typing "build")

the object files (*.o) should be created (I'll change more things as the code change, perhaps use a specific build directory in which object files are moved?). and the division by 0 is intentional (it is used to describe the value "infinity", and have always been there, just the g++ is more angry when it come to these things).

I guess it might actually be a bit slower by the move to c++. But that's nothing that I think can be solved (c++ adds some highlevel features to the original c... which results in some minor performance penalties).



also, it sounds like it would be a good idea to change a lot of the current values... we really need to compile a list of all that should be changed (but not rescaling... yet), and make an official "retweaking" of rcx 0.06


update: I've just discovered the strtok (and strtok_r) standard functions... Do I feel stupid or what?! O_o  Ok, the new text file processing code will be much smaller than it used to be. Now I'll ahve to find the best way of reading the file line-by-line... I'm looking at both fgets and getline - the later is more flexible (no limit in how long a line can be), but it's a GNU extension (so windows and bsd users will have the fgets limitation).

[celestialdragoon]

I GOT 30 CHINESE PEOPLE IN MY BASEMENT JUST CONSTANTLY REMEBERING NUMBERS!!!>.......hi

[Mac]

.....lol o_O

also, it sounds like it would be a good idea to change a lot of the current values... we really need to compile a list of all that should be changed (but not rescaling... yet), and make an official "retweaking" of rcx 0.06

The problem is, without rescaling the suspension still acts weird. As I've already sussed what the overall problem with rescaling was, I know what to do and I'll be able to produce a car that's bloody amazing to drive, with what we already have coded and working.

But, if you don't want to rescale yet, I can still set up the car, internal settings and whatnot; I've still got the un-rescaled build up on my computer so I can do a bit of copying and pasting for now. :]

Anyways, Slinger, when you get round to working the .obj file loader into the game, you need to look at something I just remembered:

The game won't load if world cfm (softness) is set above 0.

I think the game tries to recalculate the sandbox's trimeshes (graphics) along with the collision stuff - since it takes like ten seconds for the game to load the sandbox in the first place, it basically results in the game never having time to draw any graphics. :/ this is why I never found out that world softness was required when the game values were rescaled - never worked. :<

So you need to stop the game from trying to do that. world softness IS required, and if the game simply won't load full world maps with it enabled, then we have a big problem.



yay coding and seriously, slinger, download the rescale build I uploaded last page and try it. the sandbox is a mess because I keep adding stuff in to drive around and hit, but the precision is nigh-on solid. I also want your reaction on the car :p maybe it doesn't turn as well as a proper rollcage car yet, but then again most cars driving at 200mph don't turn good XD so what I've gotten the car to do is pretty good.

eventually I might be able to tweak grip and side-slip and get more turning angle, but we'll see. :B

[Slinger]

I GOT 30 CHINESE PEOPLE IN MY BASEMENT JUST CONSTANTLY REMEBERING NUMBERS!!!>.......hi

And hi to you too!

But, if you don't want to rescale yet, I can still set up the car, internal settings and whatnot

Yeah, and hopefully the vales that are changed by rescaling can remain the same, but modified (internally) at load time (using some kind of rescaling constant, and specifications of how many times to use it on affected values).

The game won't load if world cfm (softness) is set above 0.

But that is only in the obj version, right? I might have made some error there...


anyway... *downloads, compiles and tries the rescaled version*
OH... MY... GOD!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I really should start coding more now that I've got the time (damn hl2 distracting me!)... There are so many little tweaks to do! I have gotten the new "Text_File" class to work as it should (only one thing left: it currently uses "vector" and "string" from standard libraries to copy and keep track of read words, I'm going to replace that with some more custom solution). I should also put more priority on reading up on wheel friction simulation... I keep on forgetting all the time

[Mac]

Yeah, and hopefully the vales that are changed by rescaling can remain the same, but modified (internally) at load time (using some kind of rescaling constant, and specifications of how many times to use it on affected values).

Or you could just change the "apparent" value of masses to "tonnes" instead of KG. I don't really see the point in adding code to rescaling something in car.conf when if you just change the comment next to it, it does the same thing.

body_mass 6 #in tonnes. example: 6 = 6,000KG

^ like that.

But that is only in the obj version, right? I might have made some error there...

Only in the obj version. good_drag is perfectly fine.

I should also put more priority on reading up on wheel friction simulation... I keep on forgetting all the time

You should. I've just noticed that on the rescale build, the front wheels of the car spin a lot faster than the rear wheels when accelerating (even though motor_tweak is on 50, suggesting equal drive distribution)

It also does the same thing when reversing but with the rear wheels spinning faster.

...I also don't think it's due to the side_slip, because I tried it with side_slip on 0 and it still did it. the front wheels shouldn't be spinning up like that. :s so maybe there's something wrong with the coulomb (mu) grip simulation as well as the side_slip simulation.........

(you're better off trying it with the camera at the side of the car to see what I'm saying here. :s)



And ... I got thrashed at the tournament. ._. but to be fair I got a bad pool. two really good players, and someone I know who ALWAYS ONLY JUST BEATS ME. >< oh well. I need to practice more :?

OH... MY... GOD!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

....is that a reaction to the objects or the messy sandbox? :s

[Slinger]

Completely unrelated: I've been thinking about the syntax for scripting. The following is my current suggestion:

Code:

#declare some files to load and variable names
declare
{
variable body geom x #three variables
trimesh box box.obj #load box.obj as box
trimesh_3d box_3d box #copy box to gpu
#trimesh_geom box_geom box #copy box to collision detection (not used)
}

#run when creating object of this type
spawn
{
create_body:box body 1 1 1 4 #box with 1m sides, and 4kg mass
create_geom:box geom 1 1 1 #box for collision detection
connect_geom_to_body geom box #can be done with several geoms
set_body_render body box_3d
#set_geom_render geom box_3d #alternative (not used)

x = 1 #completely pointless
}

The "declare" block is processed before the race, one time (to load and set up values), and the "spawn" block is executed when spawning the object. note that each spawned object will have its own private "variable table", so they can work completely independent (even when sharing the same graphics and script file).

I don't really see the point in adding code to rescaling something in car.conf when if you just change the comment next to it

Well, imagine we decide to try rescaling mass by "*0.001", only to realize that "*0.0005" gives a slightly better simulation precision, then all other values (that are rescaled) will have to be changed manually. Another thing is that I'm trying to keep the simulation realistic: is one specifies a mass of "100kg" it should still be simulated in the same way (collision impulses and gravity forces) no matter what rescaling is used (which should only change/improve the simulation precision).


ok, anyway... don't worry about the obj loader: I will completely rewrite it (when I'm done with 0.06 cleaning).

the front wheels shouldn't be spinning up like that

I know exactly what you mean. It's annoying. Unfortunately, they should spin like that. The reason is that the acceleration lifts the front wheels (or at least moves the pressure to the rear wheels), which gives lower friction, which make them rotate with less friction, requiring less power to get higher rotation. I hope that's what you meant


And the reaction that made me write in red text... Well, just guess. The total impression is mind-blowing good.

So, finally... Sorry to hear about the tournament. What kind of game was it? (I can believe I didn't aske that before)

[Mac]

Another thing is that I'm trying to keep the simulation realistic: is one specifies a mass of "100kg" it should still be simulated in the same way (collision impulses and gravity forces) no matter what rescaling is used (which should only change/improve the simulation precision).

Well ultimately, ODE works best with values between 0.1 and 1 so that's what I went for. And, I'm 100% sure I have all the values rescaled correctly, as all the objects move the same (and react the same) as they did before, only things which acted weird with low precision (such as the wheel axes) act how they should.

Things such as boxes being hit by the car should act identical to the same box being hit by the same car on the non-rescaled version - at least, I haven't noticed a difference in anything. it's not acting any less realistic.

If what you mean is applying individual rescaling to different bodies (i.e. the wheels, being 500KG, being rescaled to 0.5KG, but the body, with a mass of 6,000KG, being rescaled one step further to make it 0.6KG, but making ODE still act like they're both 500KG and 6,000KG respectively) then I'm not sure. Wouldn't that just require more processing time on ODE's behalf for something which could just be reproduced by having the two values left on 0.5 and 6? :s

And the reaction that made me write in red text... Well, just guess. Wink The total impression is mind-blowing good. Shocked

So, finally... Sorry to hear about the tournament. What kind of game was it? (I can believe I didn't aske that before)

Just don't change the gravity, because it'll completely mess the car up. (gravity on 19.64 ... effectively simulating a 1.5m car instead of a 3m, but I found increasing gravity to be easier to work with compared to making the car itself smaller.) otherwise, go ahead and trash everything. Those little black-and-white boxes were a pain to code though. that ramp up to the higher platform will be redone to be smoother, as well. The two smaller ramps (the one on the raised bit and the one on the platform) are amazing jumps.

It runs fine, right? I had to set iterations to 10, because on 20 and above it wouldn't draw the graphics. I still don't understand what iterations do, because I don't notice much different unless I set it to 1 .... in which case the car slides like mad xD

And it was a Super Smash Bros tournament. (Yes, I play Smash Bros >_>)

The "declare" block is processed before the race, one time (to load and set up values), and the "spawn" block is executed when spawning the object. note that each spawned object will have its own private "variable table", so they can work completely independent (even when sharing the same graphics and script file).

You'll have to explain to me what some of the lines do, since I don't know directly from that how certain (more complicated) things (say.... the oddbox as an example) would be created, especially if a single 3D model of the oddbox (i.e. codie's oddbox model, which I based mine off of) is used instead of creating one central body box and six boxes on the sides (as what I did).


You know, for objects with complicated geometry (such as strange-shaped objects) would it be possible to have the game load the object as the model, but load a different, lower-resolution model as its collision mesh?

a good example could be the iridescent blue box codie made, which has smoothed edges and has at least four meshes per face. having that box mapped with a box that is the same size, but has only one mesh per face and the rounded edges toned done to be one or two faces instead of seveal curved faces would be a lot easier on ODE to calculate collisions, but would look and act almost identical. Obviously if the box lands diagonal (in which case it would land on a curved part of the model) it's going to act different, but otherwise it should act the same.

I was wondering that, because complicated objects (like loose tyres) could then be simulated by something much simpler in geometrical shape (a loose tyre could just be a capped cylinder generated by ODE's code instead of a trimesh based on the tyre.obj model) which would be easier for the physics. obviously this solution would be unrealistic, but from a game perspective, the only people that are going to know are a) us and b) nolifes who spend ten hours hitting them to see how they fall over and realise that the collision mesh doesn't match the graphics.

Your unrelated suggestion has a suggestion in reply.

[Codie Morgan]

I GOT 30 CHINESE PEOPLE IN MY BASEMENT JUST CONSTANTLY REMEBERING NUMBERS!!!>.......hi

 Kidnapped them?

[Slinger]

Sorry for not posting yesterday. But I didn't play hl2 at least.

Ok some bad and good news: google hates me. but I'm not so found of google either, so I guess the feelings are mutual.

anyway, after a lot of searching, I've finally found what I was looking for: "Pacejka's Magic Formula"...
(You're gonna love this!) quote from "http://www.racer.nl/reference/pacejka.htm":

Pacejka curves are used in Racer as a big part of the tire models. They model the forces that are generated by the tire as a result of the tire not following the road precisely. Steer the tire a little, and you get a slip angle, and this is input into the Pacejka Fy formula, giving a sideways force. Press the throttle, and the wheel starts spinning a bit; this gives a different ratio of wheel spin speed vs. ground speed, and this gives a forward (longitudinal) force.

Pacejka's Magic Formula is a standard in a lot of today's racing simulations applications (not necessarily games; it's mostly professional applications that use it).

Sounds interesting, yeah? This is probably one of the most interesting approaches for simulating wheels. And guess what else appeared: http://blogs.wefrag.com/Xfennec/2009/11/12/pacejka-magic-formula-and-ode-open-dynamics-engine/
Which contains a lot of clues for how to using pacejka formula with ode.

There is a catch, though: I think it will need around 10 values to tweak. And since I doubt "monstertruck wheel" manufacturers have released any data for handling (there seem to be some values for normal wheels floating around the web), we will have to put quite some work into finding some good default values.

Anyway, this will have to be implemented in a new branch (it will take some time to code, test and probably debug). And I'm not sure if this should be done before 0.06, or after (still got the optimized obj loader/rendering code to write, and code to clean up ).


Ok, some other good news: because I'm so stupid, I didn't realize how easy it would be to only apply wheel rotation limits on wheels in air (I remember you complaining about the wheels on ground not needing rotation speed limits). I just remembered that I made the engine keep track of whether a geom is colliding or not. So the change in the code will be extremely simple (I'll do it once I've gotten the "Text_File" class done):

Code:

if (!wheel_geom[i].colliding && wheel_rotation > rotation_limit)
torque[i]=0;

(yes, I know it's not the correct variable names, but I didn't bother looking them up while writing).

---

ok, some quick "quoting and replying" to what You wrote earlier:

If what you mean is applying individual rescaling to different bodies

I agree with you , it would require way too much work (I probably explained my idea badly). What I meant is that the parameters in conf files should still be the same, and have the same units. But, internally, rcx would rescale them (without the player/coder/configurer people even notifing). This done by a rescaling constant (like "0.1") applied a specific number of times to different values: mass would be affected three times (multiply with 0.001), lengths (although that idea might be pointless) would be affected one time (multiply 0.1). but how many times friction (mu and slip), and other collision values (erp,cfm) should be changed, I don't know. But that's what I'm hoping you have found out (I'll have to take a look at the values in your version, and see how much thay are changed).

and yeah, the scripting look a bit strange (when looking another time at what I've written)... I'll probably make some kind of "scripting tutorial" or something at some poiint.

oh and:

You know, for objects with complicated geometry (such as strange-shaped objects) would it be possible to have the game load the object as the model, but load a different, lower-resolution model as its collision mesh?

Yes. A new version of the last code, which uses another obj file for collision trimesh, instead of using a proper ode generated geom.

Code:

#declare some files to load and variable names
declare
{
variable body geom
trimesh box_fancy box.obj #load box.obj as box_fancy
trimesh box_simple box_collision.obj #load low-poly version of box (box_collision.obj) as "box_simple"
trimesh_3d box_3d box_fancy #copy the high-poly model into gpu
trimesh_geom box_geom box_simple #copy low-poly box to collision detection
}

#run when creating object of this type
spawn
{
create_body:box body 1 1 1 4 #box with 1m sides, and 4kg mass
create_geom:trimesh geom box_geom #use box_geom to create collision trimesh (instead of specifying a shape here)
connect_geom_to_body geom box #can be done with several geoms
set_body_render body box_3d
}

But it will be possible to generate "trimesh" data using built-in functions, instead of loading from external files (no need for 3d editor for simpler shapes). And most of the time, une will be using built-in geom creation function instead of using trimeshes (since then it's possible to use optimized math for: sphere vs. sphere only needs a single calculation to perform, where the same with trimeshes would require possibly hundreds of calculations ).

I still don't understand what iterations do

They increase ammount of simulation steps inside each step (between each collision detection). If you are already using a low stepsize, then the "iteration" value does not need to be high (as you have found out).

[Mac]

There is a catch, though: I think it will need around 10 values to tweak. And since I doubt "monstertruck wheel" manufacturers have released any data for handling (there seem to be some values for normal wheels floating around the web), we will have to put quite some work into finding some good default values.

zomg. you are a genius in finding that.

For now, the car handles pretty well with the current friction, so you can take your time and compile a build to test this after doing all the really important things (like improved obj rendering, cleanup, etc, etc) and getting that weird "world softness on obj loader = game freeze" thing fixed so the car can handle correctly on that.

For the thing regarding the tweak values - GTA4 has a LOT of values for just one car:

Code: (GTA4 Handling.dat file)

> UNITS <
; ---------
; vehicle identifier 14 characters max
; dimensions in metres
; mass in Kg
; velocity in Km/h
; acceleration/deceleration in ms-2
; multipliers x1.0 is default
; angles in degrees
; Levels :- (L)ow, (M)edium, (H)igh
; buoyancy = percent submerged (> 100% vehicle sinks)
; engine type :- (P)etrol, (D)iesel, (E)lectric
; engine drive :- (F)ront, (R)ear, (4)-wheel drive
;
; > FIELD DESCRIPTIONS <
; ----------------------
; (A) vehicle identifier [14 characters max]
; (B) fMass
; (C) fDragMult
; (D) nPercentSubmerged [10 to 120]
; (E) CentreOfMass.x [-10.0 > x > 10.0]
; (F) CentreOfMass.y [-10.0 > x > 10.0]
; (G) CentreOfMass.z [-10.0 > x > 10.0]
;
; TRANSMISSION
; (Tt) m_nDriveBias 1.0 = front wheel drive, 0.0 = rear wheel drive
; (Tg) m_nDriveGears
; (Tf) m_fDriveForce
; (Ti) m_fDriveInertia
; (Tv) m_fV
; (Tb) m_fBrakeForce
; (Tbb) m_fBrakeBias
; (Ts) m_fSteeringLock
;
; WHEEL TRACTION
; (Wc+) m_fTractionCurveMax (formerly fTractionMult)
; (Wc-) m_fTractionCurveMin (formerly fTractionLoss)
; (Wc-) m_fTractionCurveLateral (shape of lateral traction curve (peak traction position in degrees)
; (Wc|) m_fTractionCurveLongitudinal (shape of longituduinal traction curve (peak traction position in degrees)
; (Ws+) m_fTractionSpringDeltaMax (max dist for traction spring)
; (Wh) m_fTractionBias
;
; SUSPENSION
; (Sf) m_fSuspensionForce (1 / (Force * NumWheels) = Lower limit for zero force at full extension
; (Scd) m_fSuspensionCompDamp
; (Srd) m_fSuspensionReboundDamp
; (Su) m_fSuspensionUpperLimit
; (Sl) m_fSuspensionLowerLimit
; (Sr) m_fSuspensionRaise
; (Sb) m_fSuspensionBias
;
; DAMAGE
; (Dc) m_fCollisionDamageMult
; (Dw) m_fWeaponDamageMult
; (Dd) m_fDeformationDamageMult
; (De) m_fEngineDamageMult
;
; MISC
; (Ms) m_fSeatOffsetDist
; (Mv) m_nMonetaryValue
; (Mmf) mFlags (model flags - see below)
; (Mhf) hFlags (handling flags - see below)
; (Ma) m_nAnimGroup (anim group type - see below below)
;
; MODEL FLAGS - written HEX for easier reading of flags
; 1st digit 1: IS_VAN 2: IS_BUS 4: IS_LOW 8: IS_BIG
; 2nd digit 1: ABS_STD 2: ABS_OPTION 4: ABS_ALT_STD 8: ABS_ALT_OPTION
; 3rd digit 1: NO_DOORS 2: TANDEM_SEATS 4: SIT_IN_BOAT 8: N/A
; 4th digit 1: NO_EXHAUST 2: DOUBLE_EXHAUST 4: NO1FPS_LOOK_BEHIND 8: CAN_ENTER_IF_NO_DOOR
; 5th digit 1: AXLE_F_NOTILT 2: AXLE_F_SOLID 4: AXLE_F_MCPHERSON 8: AXLE_F_REVERSE
; 6th digit 1: AXLE_R_NOTILT 2: AXLE_R_SOLID 4: AXLE_R_MCPHERSON 8: AXLE_R_REVERSE
; 7th digit 1: IS_BIKE 2: IS_HELI 4: IS_PLANE 8: IS_BOAT
; 8th digit 1: BOUNCE_PANELS 2: DOUBLE_RWHEELS 4: FORCE_GROUND_CLEARANCE 8: IS_HATCHBACK
;
; HANDLING FLAGS - written HEX for easier reading of flags
; 1st digit 1: SMOOTH_COMPRESN 2: N/A 4: NPC_ANTI_ROLL 8: NPC_NEUTRAL_HANDL
; 2nd digit 1: NO_HANDBRAKE 2: STEER_REARWHEELS 4: HB_REARWHEEL_STEER 8: ALT_STEER_OPT
; 3rd digit 1: WHEEL_F_NARROW2 2: WHEEL_F_NARROW 4: WHEEL_F_WIDE 8: WHEEL_F_WIDE2
; 4th digit 1: WHEEL_R_NARROW2 2: WHEEL_R_NARROW 4: WHEEL_R_WIDE 8: WHEEL_R_WIDE2
; 5th digit 1: HYDRAULIC_GEOM 2: HYDRAULIC_INST 4: HYDRAULIC_NONE 8: NOS_INST
; 6th digit 1: OFFROAD_ABILITY 2: OFFROAD_ABILITY2 4: HALOGEN_LIGHTS 8: PROC_REARWHEEL_1ST
; 7th digit 1: USE_MAXSP_LIMIT 2: LOW_RIDER 4: STREET_RACER
; 8th digit 1: SWINGING_CHASSIS 2: OLD_PHYSICS
;
; > THE DATA <
; name       mass    drag  boy  centreofmass  transmission brakes         steer wheel-traction            suspension damage    seat val      mflags      hflags anim
; A          B       C     D    E   F    G    Tt   Tg Tf   Ti  Tv Tb   Tbb  Thb  Ts    Wc+  Wc-  Wc-  Ws+  Wbias Sf   Scd  Srd  Su    Sl   Sr   Sb    Dc  Dw  Dd  De Ms   Mv Mmf Mhf Ma
;
ADMIRAL      1700.0  6.0   85 0.0 0.0 -0.2    0.0  5  0.17  1.0 140.0 0.22 0.65 0.7  35.0 1.2  0.95 14.0 0.13 0.47 1.6  1.0  1.0  0.15 -0.16 0.0  0.5  1.0 1.0 0.7 1.5 0.0  25000 440080 0 0

So, I'm used to having to playtest a lot of different values to see what they do.

My guess is, since we know for a fact that RCX uses a wheel diameter of 3m, if you can find the code for a "default" wheel and find out what the diameter (and also width and mass, maybe) of that wheel is, I could probably use that to guesstimate some values that should work with the larger and heavier wheels. it's just a guess anyway, but since most games use this stuff, we will have to do as they do

(btw don't get confused about the code above, either. xD but you might be most interested in the transmission, traction and suspension parts of that code, since GTA4 has values for everything to do with them - including how far up and down the wheels can move when the suspension is un/loaded and stuff about the car's grip. the car has normal traction of 1.2 (this is probably coulomb friction as well) and the car in the rescale build has traction of 1.3. anything above 1.3 really doesn't act much different in terms of grip levels, and 1.2 seemed a bit too.... slidy. but that's why I made the value on the car so low -

Ok, some other good news: because I'm so stupid, I didn't realize how easy it would be to only apply wheel rotation limits on wheels in air

I suggest that in the future, you should change the side-detection geoms to be on the wheels, rather than the car. (that would probably mean there would be 8 detectors per car - 2 per wheel). I say this because a smarter side-detection code is going to be needed - too many times the car goes mental midair because a box or something taps the roof of the car - also plenty of times the camera has flipped upside down when driving into a building, because the top detector was activated by the building boxes before the bottom one was activated by the car landing after the crash = game thinks the car is upside down and "corrects" camera and drive. lol.

With the geoms on the wheels, you would be able to use a better algorithm to determine whether the car is on the ground and you'd be able to tell it to ignore collisions from movable objects (such as boxes)

This could also be used with the wheel-rotation thing above (so that any wheel not in contact with the ground or whatever is assumed to be in the air) and then it'll be less likely the car will flip over or wheelie as airborne wheels will have limited rotation (and thus limited influence on car movement)

you should still use wheel rotation limits on the ground, because then we can force a maximum velocity for all cars. on Rollcage it was about 540/550 km/h and they would only go faster if you shot them into the air . but just use two different values for air and ground.




..... I wonder if all of that made sense. basically - airborne car + box collision = epic failure. xD

What I meant is that the parameters in conf files should still be the same, and have the same units. But, internally, rcx would rescale them (without the player/coder/configurer people even notifing). This done by a rescaling constant (like "0.1") applied a specific number of times to different values: mass would be affected three times (multiply with 0.001), lengths (although that idea might be pointless) would be affected one time (multiply 0.1). but how many times friction (mu and slip), and other collision values (erp,cfm) should be changed, I don't know.

Ah. well, if you haven't looked at the car already:

- Grip and erp don't need changing.
- softness needs multiplying by three steps (0.001) as does mass, torque, brake, side_slip and drag.
- lengths can remain the same.
- buffer and threshold values (i.e. building) also need to be multiplied by three steps.

This includes objects and the world itself as well as the car. All other values can stay the same. (including wind - hey, you said there would be no need for tweak values! )

Out of all the values in car.conf, the only ones that look out of place is side_slip and the drag, as they are both very small values. since you now plan on trying to implement better friction simulation, I don't see the point in adding a rescale value for side_slip. As for drag, you probably will have to, but I'm not sure whether they need changing or not yet as the car still isn't close to being "rollcagey" yet.


end of big post now I go comment on codie's awesome pictures.

[Mac]

OK, ignore my last crap edit (if you read it)

C++ compiling doesn't seem to work on my desktop. I may have to actually properly install MinGW (I just copied it off my laptop and pasted it into the same dir on my desktop. Up until now it worked fine, i guess there's something odd with the new changes.

Anyway, I get this on my laptop when trying to compile:

$ make -f makefile.doze
g++ -c -o loaders.o loaders/loaders.cpp -O2 -pipe -Wall -march=i686 -mtune=i686 `sdl-config --cflags` `ode-config --cflags` -Dwindows
In file included from loaders/loaders.cpp:9:
loaders/text_file.cpp: In member function `bool Text_File::Buffer_To_Words()':
loaders/text_file.cpp:141: error: `strtok_r' was not declared in this scope
make: *** [loaders.o] Error 1

:/

[Slinger]

Man, some random firefox add-on installation and update later, and I can seem to start with my normal firefox profile anymore... O_o

And for some time this morning I could not push any data to github (server problem)... seems like everything is breaking down.

Oh well.



Those values for gta4 seems interesting... I wonder what wheel friction simulation is used in that game. Maybe it's Pacejka, or maybe something much different? O_O

The whole "false detect" thing where the car think the wrong side is against ground... Well, thats something that will not be a problem when I finally bother to add "collision bitfield" support, which will make it possible to clasify a geom and specify what other kind of geoms it should collide with (for example: target sensors should only collide with parts of buildings that are clasified as "target", and the car's 2 upside sensors should only collide with the geom classified as "track", so it will not be false-triggered by other things). it's  already supported inside ode, but we'll just have to figure out some names to clasify things...

and for now, I'll just make the "wheel rotation limit" affect wheels in air (the whole point was to prevent too high rotation, resulting in strange axis bending problems). but you are right, some kind of "motor friction" or "efficiency loss" should be implemented (at some point) to make it possible to set a max speed.

- Grip and erp don't need changing.
- softness needs multiplying by three steps (0.001) as does mass, torque, brake, side_slip and drag.
- lengths can remain the same.
- buffer and threshold values (i.e. building) also need to be multiplied by three steps.

Perfect! I'll have to take a look at the old "slinger/rescale" branch and see if I should just modify that (the values are changed when loaded), or just make these changes inside the "spawning" functions. I'll probably focus on this after completing the 0.06 cleanups, though.

---

That compilation error seems worrying. According to the strtok manpage, "strtok_r" confirms to "POSIX.1-2001.", so I just assumed it would be available on windows... (since it often tries to provide most unix standard functions). After searching a bit, I think I've found a solution: http://www.mail-archive.com/gnome-db-list@gnome.org/msg01345.html
Basically:

* Issue:       strtok_r (reentrant version of strtok) does not exist on
win32
* Solution:    define it as an alias for strtok (supposed to be
reentrant safe on win32):

The reason I used strtok_r instead of strtok, was that strtok isn't defined to be reentrant safe (could cause problems with multireading). but since the windows version should be safe, I'll make an exception for compiling on windows. I'm not sure if it will work correctly, though. You will have to test it and see...

[Mac]

Perfect! I'll have to take a look at the old "slinger/rescale" branch and see if I should just modify that (the values are changed when loaded), or just make these changes inside the "spawning" functions. I'll probably focus on this after completing the 0.06 cleanups, though.

Or just change them in car.conf like I did. less hassle. just take a look at my car.conf in the rescale build and do comparisons. Really, the only values that look out of place are, like I said, drag and side-slip, which are 0.000x values rather than something between 0.1 and 1. those could use a rescaler function so that in car.conf you could put 0.1 and in-game it would actually be 0.0001 (correct drag for the simulation).

maybe for mass too, so it would make more sense in car.conf to define a mass by KG rather than tonnes. :/


Anyway, bump this when you've got it sorted and unless I've already spotted it on GitHub and started toying with it, I'll do it them. Unfortunately I'm having problems compiling with g++ on my desktop ... at all.

make: *** No rule to make target 'shared/shared.h', needed by 'main.o'. Stop.

Which is odd, because I'm typing the same makefile line as on my laptop, which produces the strtok_r error instead.

Does it make any sense to you?

edit

I'm a douchebag. I saw it in the latest commit and facepalmed. shared/shared.h was being declared in the MAKEFILE....lol. g++ works on my desktop, it was just stupidly trying to find shared.h not shared.hpp ... x_X

lol. worry over.


edit

current version compiles. didn't get the "division by 0" warning either... I was expecting that, since you said it was intentionally there to define "infinity"... hm

but either way it compiles. stability? no idea, but it does play.

[Slinger]

Yeah, a nice feature by switching to "strtof" instad of using the ugly sscanf, is that even the windows version can load "inf". Earlier this was aproblem: when the windows version of sscanf read the word "inf", it would not be able to translate it to (variable=infinity;), while it would work on other systems. That is the reason I added a windows specific piece of code to check if the word was "inf", and then set the (variable=infinity;)   This was done by typing 1.0/0.0 (causing the error message). Anyway, I think the windows version of strtof understands if the value should be infinity. Try by setting some friction setting (like wheel_mu) to "inf" or "infinity" or "InFiNiTy" or similar (without the quotes), and the friction should be infinity (easily tested using drifting_breaks).

Ok, I now have crossed out a few things from the list of things todo. But there are more things left. At some point I will add a file in the car directory called something like "parts.lst" (or geoms.lst or components.lst), in which it will be possible to specify arbitrary geometrical shapes (and their offset, rotation, and sizes) to describe the car collision detection shape. This will also be used to specify placement of thrusters in the future (position, strength, colour and similar).

Something I'm going to add next is the concept of "templates". My idea is that things are loaded as a "template", which is then used as the base when spawning objects of this kind. Two good examples: the current object and car.
* The car is loaded as a single block of data, and is used as the base when spawning the car (in other words: in order to spawn two identical cars, one will have to load it twice).
* The object(s) are loaded to dummy scripts, which contains info for rendering.
Both of these will instead be loaded as templates (Car_Template and Ojbect_Template... And Weapon_Template in the future). In order to spawn them, you use a template and some other data (for the car it's position, rotation, and profile/player to control the car. for object, it's just position and rotation), to create the object (how many times you want).

The "Object_Template" will still point to a "spawn" script (but until scripting is in, it'll be empty), but it will contain info about loaded 3d models and variables (which will be allocated to each object spawned, so they all get their own set of variables).

As soon as this is done, there will be two (or more...) cars spawned by default. Although I'm  still not sure what ("debug") key to use to switch between them.

---

Or just change them in car.conf like I did. Tongue less hassle. just take a look at my car.conf in the rescale build and do comparisons.

Yes, less work needed, but it wouldn't be so much work to add a single "mass = mass*rescale" line to the parts of the code where bodies are created (I'd definitely not mind the extra work if it would make the conf files just a little bit less confusing).



I wrote a long and confusing post as usual... Oh well, bye!

[Mac]

As soon as this is done, there will be two (or more...) cars spawned by default. Although I'm  still not sure what ("debug") key to use to switch between them.

Two identical cars or two different cars loaded from different folders?

And for now... could you just not use the number keys? (1-9) to switch between cars? it'd be interesting to see separate keyboard controls for the second car too but that's just going to be weird.


Your post isn't confusing. It makes enough sense to me to understand what you mean. and thanks for clearing up the inf thing. sometime I'll try it and see if it works (interesting thing - on my rescale build, setting side_slip to inf crashes the game the moment the car touches the ground .... lol)


Maybe you should use a rescale on the mass and the drag, then. if it'll make the conf file make more sense.

Ok, I now have crossed out a few things from the list of things todo. But there are more things left. At some point I will add a file in the car directory called something like "parts.lst" (or geoms.lst or components.lst), in which it will be possible to specify arbitrary geometrical shapes (and their offset, rotation, and sizes) to describe the car collision detection shape. This will also be used to specify placement of thrusters in the future (position, strength, colour and similar).

components.lst probably sounds better considering that eventually, data for thruster placement will be placed in there as well.

I'm worrying about the fact that placing so many objects for the collision box will create some sort of "random bug bounce" instance with very small geoms penetrating objects/world (it used to happen a lot for me with stepsize on 0.02, the rear wing would get under the flipper and the car would go mental). I'm guessing that with correct knowledge such a thing won't happen (one long box could be used as a means to create a collision box for the upper and lower rear wings on the car rather than two very small ones).

would thrusters that would ultimately be used for car stability/air control need to be defined in this list or would they be hard-coded and their position dependant on other things (such as wheel location)? The thrusters for air control would be in the same place on every car since they would be tied to the wheels (to counteract wheel rotation in the air, and then to provide an additional force when keys are pressed to flip the car backwards/forwards or spin it ((for stunt mode )) and could just be coded to have their position defined entirely in relation to wheel size and placement in car.conf.

or something.

AIR CONTROL! :B