Whats in your RIG?

[Mac]

I was going to post this in the concept art thread, but decided against it because I don't want to spam codie's thread.

__

Anyway, this is probably random but a bit related in a sense. Since SDL_GetKeyState is tied to graphics (the game only rechecks to see what keys are being pressed when a new frame is drawn - standard on all video games, and not a problem) then when you get around to implementing ghost (or replay) viewing, there may be a problem.

For example, for replays, ODE will probably need to just replay the car's inputs (since the car reacting in the exact same way will always yield the same result in terms of movement, crashing, etc). A lot of video games do this, and Rollcage / Stage II does it. Replay files are nothing more than logs of input from player and AI. However, when playing a replay, what if it's played on a system that has a lower system spec and thus lower fps? or one with a higher fps? what if the system suddenly jumps because an OS process suddenly takes priority over the game and causes a moment where graphics aren't drawn (and thus inputs aren't read)?

The result will be a desynced replay (the car will receive an input too early or too late, even by the space of 1ms, which will cause it to hit something in a way it shouldn't and cause undesired reactions). It's happened to me on SSX, it's happened to be on Rollcage, even.


So there are two solutions. The first, is that when replays are played, input (SDL_GetKeyState) is handled by the physics rather than the graphics. Since the input would be tied to a precise step in physics, a sudden jump in processing performance that would drop or increase frame rate won't cause the input to be used before or after it's meant to. Thus, the car should drive a replay in the same manner on a system running at 10fps or at 60fps, because the input is being handled without waiting on graphics to update. And, assuming that the car crashing into the same place at the same time at the same speed and direction will always yield the same reaction to the car and any hit objects or cars, everything should be fine.

The second would be to just save the cars (and objects) locations at intervals (maybe 20 or 30 times a second) and simply move all objects between co-ordinates. This is what Trackmania does (although at a rate of 10 a second) and would guarantee that it's impossible to desync a replay. This would probably be best for ghosts too. However, with a lot of objects on the world, it might become a hassle for ODE to calculate all the movement.


I just thought of that in regards to the keystate thing because I wondered it.


Also, you know that when you get VBO working, you could theoretically add code to allow track/model designers to define surfaces with the properties of sand, ice, grass, tarmac, etc? You could just make the game assign certain properties to any object faces that match a certain material name (such as ice for ice .... duh) and have something in track.conf to allow quick modification of said values.

^
THAT is something I've been meaning to mention for a long time. If VBO works as well as I hope (by that I mean a nice fps even on my laptop) then we could probably start adding surface property stuff in. I'd want codie to checkerboard roads so I can judge speed too (damn, I want him to model a fully-playable harpoon island track ... the first one on rollcage, complete with checkerboard road and stuff) but trying to model that track off of pictures is a definite pain in the ass.

We need someone to decompile the damn rollcage.img file. I'm sure that's where all the car models and textures are kept ...... ironically, I have a program that disassembles vehicles.img in GTA4 (hint - model replacement) and I wonder if it'd work for rollcage's img thing too. If so, I could have a crack at ripping game models and pray they're in a ridiculously simple model formal (like something 3ds max can read) and maybe then we can start to get a grasp on some fundamentals... like how big the fucking maps actually are. =/

[Slinger]

I like the idea of having "physics" processing stored inputs. It does make sense: the real input will used to control the replay (pause, rewind, exit, etc...), the the recorded input could simply be stream from a file directly into physics simulation. This would be like simulating the race again, but having all inputs provided by a file.

But storing all positions of everything into a file (including creation/destruction of them) would make it possible to easily replay the race backwards. and compared to the input storing, it will have a few advantages (good for slow systems):
* no need for simulations (don't event set up ode and the event processing, just let the graphics thread render it all)
* no simulation will result in less cpu usage
* no simulation makes the risk of replay on different stepsize go away (higher stepsize would result in crappier friction simulation = car will crash where it in "reality" didn't)

Also, you know that when you get VBO working, you could theoretically add code to allow track/model designers to define surfaces with the properties of sand, ice, grass, tarmac, etc? You could just make the game assign certain properties to any object faces that match a certain material name (such as ice for ice .... duh) and have something in track.conf to allow quick modification of said values.

VBO will only really be usable for rendering stuff, but having different surface properties is a must have.

Apparently, there are possibilities in ODE for getting the specific triangles of a trimesh that something is colliding to... So I would suggest that the model of the world (which gets transformed to a collision trimesh), would use a set of textures (names defined in track.conf, or possibly world.conf if reusing textures in all track in a specific world - something that should be a good idea). At every time a geom (car wheel, car body, random thing) collides with the world trimesh, the specific triangles touched will be requested, their textures will be looked up, and each texture would have a specific friction property (even erp/cfm values).

so: "texture-specific-friction-property" or something...

I don't think the original rollcage tracks are that big really, and the textures probably rather crappy... But it would be interesting to actually see the models in a 3d editor (like that gigantic spaceship in that death-mode track... )

[Mac]

* no simulation makes the risk of replay on different stepsize go away (higher stepsize would result in crappier friction simulation = car will crash where it in "reality" didn't)

That's not really much of a good reason, because eventually we need to decide on a permanent stepsize, iterations and contact points setting and stick with it. Otherwise, playing online will be awkward (people with better physics simulation would have an advantage because of better handling simulation... and crash simulation.)


The one problem with doing it is, if there are a lot of objects on the map, it could result in a very large file. Also... validating replays with it would be impossible, because anyone could just manually change the locations the car is at and make it seem to go faster. for normal replays it'd be okay but for time-trial replays, providing once we get a fixed stepsize set and the physics simulation is exactly the same regardless of OS platform (i.e. OS won't affect simulation ... could be possible) then the input-log replay would probably be best.

If I recall, the textures were probably about 16x16 or 32x32 (the car was 32x64 I think. lol) and the game requirements were a graphics card with 2MB memory, so the models and stuff were probably only 100KB each at the most - worlds probably 300/400KB depending on size. Still, I meant size in the scope of visible size (i.e. length). Also getting one of the tracks to work in RCX would definitely help find out exactly how big the game cars were (and gravity for that matter).

I just need to find my external HDD and install rollcage.... blah.

Apparently, there are possibilities in ODE for getting the specific triangles of a trimesh that something is colliding to... So I would suggest that the model of the world (which gets transformed to a collision trimesh), would use a set of textures (names defined in track.conf, or possibly world.conf if reusing textures in all track in a specific world - something that should be a good idea). At every time a geom (car wheel, car body, random thing) collides with the world trimesh, the specific triangles touched will be requested, their textures will be looked up, and each texture would have a specific friction property (even erp/cfm values).

Well, since ODE has to check each triangle for collision anyway, I can see how that's possible.

I was suggesting you do it along with the VBO because the (hopefully) increased performance in rendering should mean that having extra physics calculations to check for surface type wouldn't affect the game too much - I'm guessing even on my system surface checking would trash CPU usage at the present moment.

Either way, it would have to be implemented at some point anyway, whether using materials to check, or textures to check. I don't know how large games do it (maybe they hard-code specific friction/surface properties to specific triangles?) but either way you'd have to do it eventually.

[Slinger]

As you said, using either materials or textures to specify surface properties should be implemented. So it's definitely a future feature (just like menus, scripting, textures... )

About ghost validation, you have a point there. The only thing I can come up with to defend the non-input solution would be that rcx could store both inputs and body/geom positions... But that seems like a strange idea (if doing both, why not using the one of them that works for everything instead)... So you are right: if we can decide on some official values (although they can be changed if just playing locally), just storing inputs seems more possible.

[Mac]

Once I know how much the game is affected by the VBO graphics (with low and high-resolution cars and objects, low and high-resolution world map mesh ((will always need high-res collision map for the world lol.)), and other such things such as graphics effects (textures, shadows (ZOMG NEED SHADOWS), lighting effects/glows) and stuff, I'll be able to work out a good setup for the game.

My current guess is that considering the current OBJ works fairly decent as it is on the same settings I use on the good_drag build, stepsize should end up something between 0.005 and 0.002 (200 / 500fps). Since most current games use something between those values, it's a good base to start at.

I think aiming for a stepsize of 0.005 to start with is perfectly fine imo, and if the VBO works as well as we hope, then maybe 0.004 could be used instead.


I guess until we finalize it, having the game just run back a log of object/geom locations is best. It will need looking at though eventually, especially when it comes to online (I don't know which will be best for online really)

[Slinger]

It will need looking at though eventually, especially when it comes to online

That's a good point. I had simply assumed there would be a single system (the race host) performing all simulation (receiving inputs from other players), sending all coordinates to all other players. But having a more compressed solution (only share inputs and events, and let each computer simulate the race) could be necessary to prevent problems on slow connections.

0.005 sounds nice (might even work on slower systems). I know "maniadrive" uses 0.01 by default. It's an interesting trackmania clone (I think it uses Pacejka for wheel simulation ).


Since graphics effects are mentioned, I just gotta write some thoughts I've had: I should start playing with the "accumulation buffer" - after rendering a frame, it's stored in that buffer, and can then manipulated to provide anti-aliasing and motion blur. There's also another feature for manipulating frames: FBO ("frame buffer object") which could be used to create bloom and blur effects. I'll have to see if they should be combined, or if just one of them is needed. Also I'll have to look at some kind of "iris light adaptation" tone mapping effect. I think there's some hardware acceleration solution to rendering shadows... Will have to look it up...

(update: "tone mapping"...)

[Mac]

Yes, you should start playing. Personally, I'd say "get shadows working", even if it's just shadows the car casts on the world (I guess OpenGL will spaz with lots of shadows, especially if they're pixel-perfect like in Trackmania and don't get coded in to have LOD effects on them (to lower shadow resolution at distance (again, like in Trackmania)...)

I swear I remember that on an image of the 0.02 proof of concept you once posted, the world floor had both some sort of bump-mapped lego texture, and the car projected a shadow. You probably dropped it upon being unable to get it to work in Windows, but I thought it looked pretty spiffy ... made it look like a lego game ^^ but it looked like a nice lego game.

still pissed spont's shadow test doesn't work in windows. "shadow_gen_cube is defined but not used" nonsense and stuff. -_- but I'm sure you'd get some decent shadow (or possibly even RC1-style car reflection) working if you put your mind to it.

Want transparency. Do want water. rofl. maybe the multithreading branch will be able to handle the water and stuff now.

.....I just thought of something for the water. I'm an idiot. If you can't get transparency to work yet, why not just make the surface of the water have geoms that don't actually match the full size of the geometry but have gaps between them?

This doesn't make sense ... but let's just say that the surface of the water is a mesh consisting of 16 2m squares in a 4x4 formation. Normally, you would render the mesh with something that would completely cover the surface and would dynamically change to match the water's collision mesh. What if instead, you just rendered some smaller, 1m boxes in the centre of each mesh, or render one at each point where separate triangles meet? It would probably look strange in a way, but on the other hand you'd be able to see the surface of the water and see beneath it.


Random. I know. I randomly pick up thoughts.

(the alternative could be to just put quadstrips along the triangles themselves of a decent enough thickness ... would work just as well ... could probably let us see how the water reacts to contact with bodies too, actually)


ARGH. PEOPLE LEAVING THE DOOR OPEN. =-=


edit

maniadrive? Screenshots or compiled win32 binary plox. o.o

[Slinger]

lol, yeah the good ol' 0.02!

I just cheated back then, and used a rendering library called "drawstuff" - it was created just for rendering ODE demos
I then decided I wanted a custom (more professional) solution... And well, once it was working, I didn't put more work into it. But it's a perfect base for continuing adding more graphics eye-candy, as I chose to call it.

But I'm starting to want some graphics features too, so I guess that will be some of the higher priority stuff after 0.06 - which will be done once obj rendering is rewritten (and once I've created some homepage to post all old archives ).

ARGH. PEOPLE LEAVING THE DOOR OPEN. =-=

Hm? Well, my dad always forget to lock the outer door... Dam annoying (I almost instinctively walks away to check if it's locked time to time )



http://maniadrive.raydium.org/

[Mac]

Interesting-looking game. Since it's OpenGL, you think that it will help you to code texture support?

-gonna go play it- might give me some ideas. the track editor looks interesting too.


GO ADD GRAPHICS EYECANDY. Or get back to work on the VBO. I can't wait for when that works good (and world_cfm doesn't crash the game. ) VBO + good_camera + good_drag + whenever I work out how to add my own geoms to the world obj (hardcoded) = win. I will so totally build a scramble track and send the sourcecode.

edit

I think a stepsize of 0.005 will be more than sufficient for RCX. Since you say Maniatrack uses 0.01 (how would I change that if it's possible?) and the only problem I can see physics-wise is the car's suspension being WAY TOO HARD (>_>).



I like the track editor, but primarily because there's no block limitations like on Trackmania (can dump blocks wherever you want lol). RCX could theoretically use a similar track editor but using that.... uh.... I forgot the name of the method spont used for creating curves and slopes in his track editor. you mentioned it before >< but basically creating a smooth curve between two points with some math calculations.

and I just found out that Maniadrive uses spheres (spheres!) for wheels. Hit T in-game and it brings up the collision boxes for the car, wheels and other game stuff. interestingly, there's a slow-motion toggle as well (z)




I could just archive all the stuff on my site somewhere and just link to it. O_o depends if you can get hold of a decent web url to stick the stuff on.

edit again

http://raydium.org/

Go watch the video on there. Some of them (such as the ODE ragdoll physics test on the slope and the KingHill2 demo) look amazing, as do the GLSL effects tests.

I just downloaded the Windows SDK (contains all the stuff - holy crap) and I'm fiddling with it. Try the KingHill2 demo - it's awfully close to RCX in a way, and it looks really nice.

edit again again

If you know how, can you compile the kinghill2 thing to NOT switch to fullscreen and send me it? On my laptop, fullscreen OpenGL apps cause a shitload of flickering, but in windowed they're fine. I want to go run this on a few computers and do some LANing with it (it's lol on LAN, lots of random ODE collision errors (pinging cars))

edit never mind. I found the sourcecode and found the fullscreen toggle. "raydium_window_create(640,480,RAYDIUM_RENDERING_FULLSCREEN,"King of the Hill 2");"
and recompiled. wootage. I can actually run the damn thing on my laptop now.

(personally I find this one game quite fun O_o)



and yet another edit >_> I just found out ... that the car has ballast. XD. I just spotted it in debug mode, but there's an intangible box about two metres underneath the car (called "balancier". I think it's there to a) stop the car wheelieing (stability) and b) as some sort of method to keep the car upright. I think. it's something to do with that "centre of gravity" nonsense that ODE won't do because the mass of an object has to be placed dead centre (so-called "feature" )

it's a little hint there I think in case we need fine-tuning on car balance.

[Slinger]

There was a time I seriously considered using an already existing engine for rcx (*cough* raydium *cough*), but my main reason for coding rcx is to learn how to do those things from scratch

Also, textures will be really easy to add. But it will require two new libraries (for reading png files): "zlib" and "libpng" (zlib is required by libpng), or maybe some other image library (DevIL?).
Most stuff will be quite easy once the image is loaded (I'm assuming we're just using one texture file for each model ), just select texture filters (defined in internal.conf), send it to graphics memory, and make sure all obj featuring textures got proper texture maps (must see if codie could add texture maps to my models).

it's something to do with that "centre of gravity" nonsense that ODE won't do because the mass of an object has to be placed dead centre (so-called "feature" Wink)

First time I read that in the ode docs, I didn't know if to laugh or cry!
(actually, that limitation in ode is not a problem anymore... But very few people seem to know it, since it's not actually mentioned anywhere! )
And yeah, having some kind of dynamic change of car weight for rcx would solve a lot (even the acceleration/breaking flipping problems) - but wouldn't that be cheating?



utterly completely off topic: the reason I wasn't so active last week was a scale model of an "enzo ferrari". I've not even started removing parts from the frames yet, since most things are still unpainted - I don't have all colours yet (the local store would get them in a few weeks or so - still nice of them to get the ones I need ). But now I've painted all colours I have, so I'll have no choice but to return to rcx.

[Mac]

They got past that centre of gravity "feature" bug? lol.

It would be weird to code into RCX anyway, because it would have to flip Z height when the car is flipped over. I guess that wouldn't be that hard really considering the flipper sensors do it .... lol.

I think codie wants to use like 6 texture files per car ... >_> but I know tga is supported on windows (maniadrive uses tga ... they're pretty good for textures) so if png won't work on windows, use tga. Plus they can save alpha layers (can't get pngs to do that .... crap) which would make things like specular textures easier to do >< (trackmania style).

For now I guess the game only needs one texture per object, although two (diffuse texture and a specular texture (for when sun hits the texture surface) would be nice too. My laptop also seems to be able to handle all the OpenGL shader crap that Raydium threw at it ... although I've discovered that my laptop despises running OpenGL apps in fullscreen (post above - had to hack KignHill2 to be able to play it ..... hey! guess what? it has input lag unless I resize the screen to 400x400! XD) so I will be forever stuck running RCX in windowed mode on it.

My desktop is rape though. (apparently will take textures through OpenGL up to 8192x8192 in resolution ... according to Raydium's console ( ... yes, I get the console up and working when I play their demos. IT'S POSSIBLE ON WINDOWS.))


Personally, I think the current build of RCX' game engine is better than Raydium's. Although the car in KingHill2 is really how the RCX cars should sort of drive, the car in maniadrive acts weird at high speed (handles way too well at high speed ... doesn't have any grip loss it seems).

I also like the fact the KingHill2 car accelerates and brakes properly. >_> you should see how it does that (and that car has a ballast too. lol.) in case it has a method of accelerating and braking that would be useful to add to RCX for low-speed stability.
I'm suggesting this because that jeep (it's a jeepthing. you wouldn't understand.) is somewhat akin to a rollcage car (monster truck wheels) so seeing how it accelerates and what grip values and method of grip it has is probably going to help us a lot if you find out they use pacejka (or whatever it's called) as a grip system.


Personally, it doesn't work for the clio. for the monster truck it does though. really well. it's got really good handling at speed.

Also, I want you to lol at ODE because of how much wheelspin actually affects car movement. I remember you saying it was realistic ... I still don't think it is even though Raydium's engine does it XD


model ferrari? woo O_O

And yeah, having some kind of dynamic change of car weight for rcx would solve a lot (even the acceleration/breaking flipping problems) - but wouldn't that be cheating?

Not really, because Rollcage's cars were as stable as rocks when they turned (stable as in they didn't lean outwards) and if we want the car's suspension to help keep the car's wheels on the ground when going down slopes, it means that unless you find some better method of suspension elevation, I have to make the suspension quite soft. Soft suspension = the car tilts out ridiculously when cornering. Shifting the car's weight sufficiently inside the cornering direction to keep the car balanced is a must for stability and probably will help cornering itself too.

And accelerating / braking for that matter.

Although, it depends on whether you decide to use thrusters to force stability instead of secretly shifting car mass left/right/forwards/backwards/up/down to keep it stable... and whether it'll work correctly on sloped/tilted surfaces and on ceilings.
it's all about the ceiling-driving.

I'll shut up now.

[Slinger]

can't get pngs to do that .... crap

hmm...

[...] Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. [...]

Having different textures for different things (parallax mapping, specular mapping, and similar) should be possible, the thing is, it would be nice to have only one file for each one. So that (when rendering the normal texture) only one texture needs to be selected, and sharing car skins only requires one single file (or one file for normal texture, one for specular, etc) would be slightly more convenient.

it depends on whether you decide to use thrusters to force stability instead of secretly shifting car mass left/right/forwards/backwards/up/down to keep it stable...

There is a third alternative: add forces without actually render thrusters. The car would be stable - like original games, and look the same (no sudden thruster flare igniting). I'm not a fan of this myself (I hate the idea of arbitrary "invisible" forces), but it is an option (instead of moving mass, which seems equally strange).

model ferrari? woo O_O

ok... seems like simple textures, Pacejka magic and spontificus road generation code should be the first priorities for 0.07...


update: I'll be away for a few days, see you later.
update2: nevermind.

[Mac]

Bah. I typed out a massive argument for why I was against having one file for all textures, and then realised I'd misread what you typed.

You mean having one file which contains several (four, maybe more) "normal" (diffuse) car skins for one single car model? and having a separate file for each texture's specular map and similarly one for bump/parallax maps?

If so ... well, theoretically it would work, but on low-end systems loading one rather large file that contains several skins for the same car is rather pointless unless it just so happens that the AI in the race all use the same car and those other skins. whilst for the sake of tidyness it would be better, resource-wise there's no point loading a skin unless it's being used - it saves space and thus helps performance.

Also, with LOD, you would get the effect of a blue car suddenly getting a red blemish on one side because the LOD drawing has scaled the texture file so low that the current car's skin has bled across to another car skin in the same file - this effect can be seen both on Trackmania and on Maniadrive (play Trackmania on bare minimum settings, you should see that at a reasonable distance, the rammstein (the black line that runs between the road and the green stuff, not the actual rubber barrier itself, the line on the ground) turns yellow at a distance - this is because the texture used for the rammstein and barriers also contains the yellow strip that lines the grid around pole blocks, and the texture's become so downscaled in resolution that the black of the rammstein had blended with the yellow of the pole grid.

this would happen on the cars in Rollcage if one car model had all its skins in one single file.


I would say having skins for the topside and downside of a car in one file is enough, with a separate file for the car's specular and one for bump/parallax, etc. Why do I say separate files for diffuse and specular? If you want to give a car a metallic or iridescent finish, the specular would have to be coloured instead of white. If the specular effect was generated by the diffuse file's alpha, it would be impossible to define a colour the texture changes to in light.


Maybe it's not so convenient for us to have to set them up, but it's far more convenient for the game to have to not load textures it doesn't need to load.

ok... seems like simple textures, Pacejka magic and spontificus road generation code should be the first priorities for 0.07...

woot.
I'm actually curious as to why Raydium chose spheres for wheels over cylinders. It tempts me to ask you to mock up a build where the wheels use spheres instead of cylinders (but still with the cylindrical wheels as visible geometry) so I can see how differently they act. It could be that they chose spheres because the car was deemed more stable.

Technically, spheres for wheels on the rollcage cars would GUARANTEE that they could not stay on their sides (as in the original games) but the collisions would be unrealistic... maybe. I just want to see if the car actually handles better with spheres instead of cylinders (it might do for all I know!)



Raydium must use a better friction simulation, because the KingHill2 jeep doesn't exhibit that weird front-wheel spin that the rollcage car does (both cars are 4WD). you said that the wheelspin was realistic but on KingHill2 it doesn't wheelspin and it's made me realise that the wheelspin on RCX is causing the car to handle incorrectly (too much front wheelspin when driving = too much front wheel griploss - it explains why the car won't straighten up after a drift, because the lack of wheel friction is making the game assume the car's still driving sideways) so ... if Raydium really does use pacejka .... ADD IT.

And seriously. Download their SDK and go through the kinghill2.c file. I'm sure it'll tell you in there what values the car has (I found that its suspension cfm/erp is 0.1/1.0 so it seems they have scaled the masses correctly, but I've yet to locate friction in the sourcecode). Since the car is rollcage-esque, if the game engine uses pacejka, we can use the jeep's friction values as an initial base for RCX with which we can then tweak as necessary to get the car to handle how it should.

Aren't I clever?

There is a third alternative: add forces without actually render thrusters. The car would be stable - like original games, and look the same (no sudden thruster flare igniting). I'm not a fan of this myself (I hate the idea of arbitrary "invisible" forces), but it is an option (instead of moving mass, which seems equally strange).

I was assuming you would add the forces without rendering them. xD I mean, having thrusters randomly appearing on the car would be strange. But the thing is, it's the only way (apparently) to allow the car to travel at Rollcage speeds with it acting Rollcage. Plus, something as big as a tank would never drive on a ceiling at 200mph so that in itself is unrealistic but it's a must.

I've spent the last week panicking about how the car would actually drive on the ceiling, because on the ceiling it would need twice the amount of gravitational force to drive the same as on the ground (one amount to nullify the actual gravitational pull of the world, the second to give the car a "full" gravitational pull upwards) but driving on the wall, it would need one equal force to the side of the car to nullify gravity, with one above it to push it against the wall (otherwise it would just fall off)

:/ makes me think that making the car drive on the ceiling is going to be a pain, as these forces would have to be dynamic to account for when the car changes direction, drives down from the ceiling to a wall, or if the ceiling slopes down (like on some stage II courses).

:/

WHY ARE YOU NOT AWAY FOR A FEW DAYS. D: lol

[Slinger]

you got much more knowledge with textures than I have (all I know, is that they are pictures put on polygons - I don't even know if a material colour affects the texture on the surface...).

I was in a bit of a hurry when I wrote that post: tried to determine if to stay home or go away - dad had to see if a resent power failure had caused the water in our holiday home (is that what it's called? ) had frozen (*imagine an exploding toilet chair*), but I eventually decided to stay home. So, anyway, I didn't explain my thought clearly.... But as you just said:

I would say having skins for the topside and downside of a car in one file is enough, with a separate file for the car's specular and one for bump/parallax, etc.

That's exactly the way I was looking at it too: one image file covers all parts of the car, accomplished by more files for extra features (lighting maps and whatnot). Having each "kind" of texture in only one file (and not spreading texture to different files for windows, pipes, front spoiler, rear spoiler, etc...), would make it easy on the coding: no need for multitexturing (I think it's called).

I'm actually curious as to why Raydium chose spheres for wheels over cylinders.

don't quote me on this, but I'm almost certain it has to do with ode collision detection for cylinders being crappy. I don't blame the developers (well, it's mainly just one person behind ODE): there is no simple math for cylinder collision detection (compared to boxes, spheres or even half-sphere-capped-cylinders - they are almost as simple as spheres! ). When I add support for several cars this will be noticeable: cylinders currently doesn't collide with other cylinders, so the wheels won't collide O_o

you said that the wheelspin was realistic but on KingHill2 it doesn't wheelspin

I don't want to be a smart-ass here, but the realism is that the high torque or the rollcage car causes it to lift (or at least put less weight on) the front, giving the front wheels less ground friction, resulting in them being able to accelerate to higher speed. I'm not sure KingHill2 uses pacejka magics, I think it has more to do with the cars being similar to real cars (no overkill motor torque causing them to flip over).
But maniadrive does (I think). So we could probably steal their values (and probably parts of their pacejka implementation too)...

I was assuming you would add the forces without rendering them.

ODE is very friendly, it allows one to add arbitrary forces/torques in any way imaginable (with just a single command!), so just adding forces would be a laugh! But I've always wanted to explain all forces... For example: the wheels on the car gets torque from the motor. But adding invisible thrusters would add give a situation where most players will think: "that's strange, why does the car handle so good?" instead of "ok, so those thrusters must be what's keeping the car in control!".

But this so perfectly leads me into an idea I had just after I wrote the last post... Forget all about thrusters and dynamic change of mass!!! Well, not thrusters, since they will be added at some point: we will need them for missiles and floating adds anyway... Ok where was I?... You remember I previously mentioning the cars must be equipped with "inertial dampers" ("Inertia negation") to prevent collisions forces from killing the drivers?
Then it struck me: if the (sci-fi) cars are equipped with inertial dampers, they probably got even more advanced stuff! So why not a "torque damper"? or "opposing wheel torque compensator"? My idea is that when the motor add torque to the wheels (or breaks the wheels), the torque is not reflected back on the car body (thanks to the magic "torque compensator"). Meaning the car doesn't flip anymore.

As I might have said before, the problem is not to simulate forces (that's what ODE is meant for), but to explain the forces in a realistic way. I'm thinking about adding a boolean toggle to car.conf ("torque_compensator true", or similar), to enable/disable this feature, so it can be introduced as a real invention or something (or maybe a float value specifying it's efficiency? hmm... the better the car is, the better torque compensator it's equipped with! )

makes me think that making the car drive on the ceiling is going to be a pain

From my point of view, the hard part will be to explain it! I guess some people will create vacuum tracks (~moon), in which case air flow based downforce can't explain it - leaving either thrusters or an onboard "artificial gravity generator" (yay for new imaginary inventions!).

[Mac]

You took an hour posting that! (I watched. )

I'm not sure KingHill2 uses pacejka magics, I think it has more to do with the cars being similar to real cars (no overkill motor torque causing them to flip over).
But maniadrive does (I think). So we could probably steal their values (and probably parts of their pacejka implementation too)...

and I don't want to be a smartass, but you're overlooking that Maniadrive and kinghill2 are driven by the same game engine so if maniadrive uses pacejka, kinghill does. Both games use spheres for wheel collision and both have ballast. in fact, both cars drive very similarly, only the kinghill2 car has larger wheels and a lower centre of gravity (due to the wheels being either side of the car) so it handles more predictably than the maniadrive car ... but prove me wrong. Go through their sourcecode! I guarantee they both use the same friction codes, just different values.

Then it struck me: if the (sci-fi) cars are equipped with inertial dampers, they probably got even more advanced stuff! So why not a "torque damper"? or "opposing wheel torque compensator"? My idea is that when the motor add torque to the wheels (or breaks the wheels), the torque is not reflected back on the car body (thanks to the magic "torque compensator"). Meaning the car doesn't flip anymore.

So what you mean is that wheel rotation will not affect the car? if I read it right, then LOL YES. but how will that balance the car during cornering? will the car still tilt? I suspect it will due to kinetic forces trying to pull the car sideways when it turns ... so maybe some thrusters will be needed for cornering stability anyway. :/

But on the idea of it cancelling body roll from acceleration/braking, then it's great. I was quick to notice that the Rollcage cars actually drive exactly the same under low gravity as they do on normal gravity (just the lower gravity lowers their ability to take downhill slopes)

Go try it out on rollcage (I forgot the gravity codes for stage II, though they might be the same).

I'm thinking about adding a boolean toggle to car.conf ("torque_compensator true", or similar), to enable/disable this feature, so it can be introduced as a real invention or something (or maybe a float value specifying it's efficiency? hmm... the better the car is, the better torque compensator it's equipped with!

lol. So tier 1 cars are more prone to acting strange under acceleration/braking, whilst tier 2 cars are perfectly efficient? xD. Considering tier1 cars won't go much faster than 300km/h (what my current RCX car gets to, albeit they will probably have slightly better acceleration/handling) they probably won't need to be so efficient, but tier3 cars (Genesis!) are going to need it to stay stable, since they accelerate to 450km/h in under a second :<

Also all cars will need it for being able to cope with the changes in acceleration under turbo power. my car suddenly under full turbo pad power will just suicide, that isn't a joke.

From my point of view, the hard part will be to explain it! I guess some people will create vacuum tracks (~moon), in which case air flow based downforce can't explain it - leaving either thrusters or an onboard "artificial gravity generator" (yay for new imaginary inventions!).

Yeah, that's what worries me. Although on Stage II, the moon tracks had the same gravity as all other tracks, I was planning on having some stages (moon / space tracks) have lower gravity all-round or parts with lower gravity - maybe half or a third of normal gravity?

My other thought on how to best implement downforce was the following:

* at standstill, the car has a full world gravity pulling it straight down, and likely no other forces.
** as the car accelerates, invisible thruster/downforce forces will begin to increase, whilst at the same time the car's 'world' gravity will decrease. If the car's on the ground, the two forces should exactly equal normal gravity when added together.
*** at a certain point, the pull of gravity will become equal with the pull of downforce and then become weaker as speed increases, at which point the car SHOULD be able to drive on the ceilings - probably around 250/300km/h or 370 if we go by stage II standards - without falling off.
**** at a greater speed, the car will in fact have negligible or no 'world' gravity and will rely on the pull of downforce to stick to the ground, or walls, or ceiling (by this point, the forces should be exactly equal to the force of gravity - 9.82). Since the car has no absolute gravity, it won't get affected by the direction it's actually going or the surface it's driving on.

***** the moment the car loses contact with the surface it's driving on (even as simple as one wheel coming off) world gravity will kick back in - if the car is quick enough to recover from the bump, then that force should disappear again and the car will resume driving, otherwise, it will be pulled off and downwards


This is why I earlier suggested that the car has individual sensors for the wheels, so the car has better options for determining whether it is stable on the road, or in the case of driving on a ceiling, whether it's lost downforce. This idea probably sounds a pain to implement because it involves dynamically modifying absolute world gravity for the car as an INDIVIDUAL CAR (not affecting other cars or objects), but then it would mean that there would need to be less directional forces on the car and it would be easier to keep the same level of downforce on the car (hence it should drive predictably rather than its handling being erratic due to changes in downforce affecting grip)


(on another thought, maybe having a small absolute gravity even at high speed should be used ... so the car doesn't keep its speed up if it starts to travel straight upwards on a surface .... maybe.)


it was just a thought, because this one would work with whatever gravity is set. less gravity = less force required to keep the car on the ceiling. Theoretically, it means the car should be drivable on ceilings at lower speed (that's the case in rollcage with low grav anyway)



come to think of it, this idea sounds like your "anti grav generator" idea (I'm guessing it's to add forces to push a car against the surface it's touching?). If so, then I think we are going to get a lot of complaints about how weapons and crashes effectively ruin a race on moon tracks because the cars take forever to recover (unless the car's antigrav simply pushes it down in the direction it was last driving against until it touches something else, and sets in that direction instead).
xD wow. I've got an F-zero GX thing going through my head now, with the tube tracks and stuff.



yum. rockstar soda and donuts. :]