Whats in your RIG?

[Slinger]

I also like a more realistic building destruction, but maybe it would be possible to find something that would still be easy on the physics?

One thing I've been thinking about is to make a building similar to the original rollcage ones, but the building might not break by just destroying the pillars, it will just make it easier to knock it of the ground. In the same way, given enough power, it would be possbile to destroy a building by smashing directly into it. And (off course) when hitting the pillars, they don't just explode, but falls off and rolls on the ground.

Also: when one body is destroyd, it would be possible to replace it with smaller ones (similar to the gigantic rocks in original games, but this affecting every lose part of the building).

so we can actually specify a certain area with a certain density

Interesting... Maybe the possibility of placing boxes with different density? The problem still is to render the water and simulating contact with the surface, but it should be possible look at how other games do it, and make something based on it (maybe even spring physics for water waves?). I'm still convinsed there are other things to do first, but it's interesting to think about.


About the camera_physics_step: yeah, when I found out that I'd placed it at the top of physics_step... man I felt stupid! (move the camera _after_ simulating world! )
Anyway, it might not solve th eother cameras shaking a bit, but now it seems everything is working as one would... well, expect it to work.




btw: I have no idea why, but I suddenly realized I've made a serious design error in the event processing, which might vry well explain why you get segfaults when destroying buildings joints:

normally, "events_step" loops through all components (a term I chose to use for summarizing geoms, bodies, joints and spaces - simply the components that makes up "objects") tht are listed in linked lists (every one registered to one of my custom *_data things are).
In order to loop through them (and dynamically add and remove components) each one got a pointer called "next", pointing to the next component in the list. and there is a pointer called "head" which points at the first component in the list.
In order to loop through all members of the list, one simply create a pointer, sets it to the first member (pointed to by head), and then changes the pointer to the "next" value in the current member (until it reaches a member with "next" being null/zero, which means it has reached the end).
The problem is: what happens if a component is removed while the "loop pointer" is still pointing at it? At this point, it will try to read the value of "next" from a piece of memory that doesn't exist!

This is a serious problem, which should make the game crash if any component generates an event (from physics_step), which then results in events_step running an "event script" which decides to delete the component. The only reason I haven't had this problem is that my system seems to leave a ghost of the *_data in memory when it's destroyed (and indeed the reason I often make these errors without noticing them ).

Currently this only affects building joints (since they are the only hard-coded component to be destroyed on events), but this will change when scripting is in (and when objects are destroyed by falling of the world). I will solve it in the "0.06_cleanup" branch, somehow... I currently don't know what is the best solution to this(!). Just storing the "next" value in advance would help at first, but what if not only this but also the next component gets destroyed? Back to square one. What about jumping back to "head" at every detected event (restart the loop at every event until all events are dealt with)? I don't think the performance will be affected by this (at least not noticeable), but I'm not sure it's the cleanest solution...

Currently my best idea is to have the "physics_step" build a list of "events", which is then processed by "events_step". But I'll have to make sure it gets thread safe (so physics_step doesn't touch the event list while events_step reads it... maybe double_buffered? )

A bonus advantge of this would be that one can make several event lists for different kind of events: "health buffer = 0" (for joints and bodies), "out of world" (cars and bodies falling of world, of flying into the sky), "destroy object this component belongs to" (when having realtime track editing/simulation, make it easy to target something and flag it for on-the-fly destruction) or simply just "sensor triggered" (when using a geom as sensor).

*phew*, this post got long

was it in xp you got the crashes when destroying buildings? I'll see if this might be the reason (and solution) for those crashes...

[Mac]

Yeah, it was in XP only. I never got it on Vista and Windows 7. Specifically, I believe it's the joints connecting the pillars to the buildings as I can trash everything else in the building, but the moment the pillars get even a tiny nudge, the segfault happens. Also the pillars tend to be the only part of the building that -doesn't- collapse when its buffer runs out. (serious!)

That's what I believe but I may be wrong. I'm sure you'll be able to get it to happen on your laptop.


About rendering the water ... I don't know. I think creating the physics for the water will be easier than rendering it, especially since if the water will have a dynamic surface (waves) it's going to need a fairly dense geometry to accurately portray waves. A lot of games with water simply don't bother with actual waves and use bump mapping and some other effects to dynamically create the illusion of a moving surface (trackmania on PC2 or higher does this), but that would require texture support to work and would probably waste a lot of processing time. :/

Unless you can make the game create geoms or trimeshes with a transparent surface / material, it's probable that for the time being the water will simply have to be either a) invisible or b) a solid colour (pale blue?). The second would probably be better because then you would be able to see exactly where it is, but without transparency objects beneath the surface won't be visible. The first is vice versa. :/

that's all I can think of.

Also: when one body is destroyd, it would be possible to replace it with smaller ones (similar to the gigantic rocks in original games, but this affecting every lose part of the building).

You had a 'd'oh!' moment in this thread a moment ago and I just had a d'oh! moment right now. WHY DIDN'T I THINK OF THAT?! I've made a 2x2x2 cube out of big boxes (the 4m ones) in my world and every time I hit the cube I think "wouldn't it be nice if I hit one of the big boxes hard enough, it collapsed into smaller boxes?"

So maybe you have found something there. You could create a nice-looking (but simple in geom terms) building composing of maybe only 6-12ish movable geoms (one, two or four pillars, centre support, building floors, roof) and each geom would in turn be destroyed and replaced with smaller geoms when that geom is hit with enough force or enough times (or simply when it's hit away from its original location ). The initial building won't be taxing at all for ODE as it'll be comparitively simple, and the smaller pieces could probably be set to destroy themselves a certain time after being created (like in rollcage, the big rocks were on a timer and would automatically explode into smaller rocks or explode completely.) so all the little bits wouldn't be able to bog processing time down.

You make me wish I was smart enough to code properly, because I would seriously go ahead and make such a building right now. of course... I would probably need to be able to construct and spawn triangular blocks (pyramids) and stuff... for things like the roof, maybe. I think for now the building exploding into boxes and cuboids will probably be a good-enough demonstration.


btw, will good_drag solve the "problem" of spheres and cylinders (car wheels) rolling for an almost infinite time at low speed? a 7-ton car simply does not roll across a flat surface at such a low speed for such a length of time. lol.

And on other news, I believe I have a solution for the rescaling of world/object hardness and of the car's handling. I set world erp to 0.6 and left everything else the same (I suppose 0.7 for world and objects would produce the same effect, but requires more coding) and then changed the car's wheel slip from 0.01 (what it was at) to 0.005 and the car and world acts as identical as I can manage to produce as the non-rescaled one, except without the stupid axis bending on the car.

The stacks of boxes are still damned unstable though (they slowly shake to the left and eventually topple) so I'm thinking that lowering object erp will be in order too. world erp 0.7 and object erp 0.7 should be good, if not I'll set both to 0.6 and see.

Lastly, I observed a strange phenomenon with the building pieces last night. I've made a floating platform with a ramp up to it (I plan to add several higher platforms for some uphill/downhill jumping and plain "omfg let's jump into the building on the ground" stupidity .... going to have to mess with the world planes so I can spawn drivable platforms out the sandbox (u_u) and on the platform I decided to set a building, just to knock it off for fun. I then ended up watching the building pieces that I didn't knock off, as every five seconds or so a random building piece would "bounce" and occasionally one would just drop through the platform onto the ground. Ironically, I managed to hit a box up onto the platform and I didn't see the box bounce in the same way at all.

It must have something to do with the number of contact points per object - unless the world itself has infinite contact points... whereas I'm stumped as to why it was happening. anyway, end of rambling.

edit

On the subject of now being able to resize the game in windows, it's not the windows drivers that have enabled it. I found the original build of 0.05 on my memory stick, ran it, and tried to resize it. I lost the graphics. Unless you've updated your ODE and SDL files between then and now, something you've done in-between has caused it to work. I just tried the last build where the camera was graphics-driven, and it resizes on that... so I dunno.

[Slinger]

(man, I think I've managed to catch a cold or something, or at least beginning to get one.. )

Now that I've got xp installed, I will be easier to actually test the segfaults (and now got a theory for what might be causing it). In any way, I'll have to rework the whole "event" list processing thing to get out of the newly discovered design error (before it starts causing some serious problems).

Transparency and textures will be supported eventually (and probably before water at all), so it might be possible to render flat water soon. And I guess waves could be left until later. I'm not sure how to solve the whole collision stuff, though. After all, we don't want something like how trackmania solved it (the car just bounces of th surface... - sure I could buy that, but not without it starting to spin like crazy).

You make me wish I was smart enough to code properly, because I would seriously go ahead and make such a building right now.

And I hope you don't make any attempt, as implementing that with the current solution with hard-coded stuff will be a nightmare... Just wait (and bug me until ) scripting is in, since then all those strange "script" structs will finally begin to make sense. And many new features will appear (like timers).

will good_drag solve the "problem" of spheres and cylinders (car wheels) rolling for an almost infinite time at low speed?

They will probably not come to a halt, but will break down and roll really slow (after all, the surfaces and shapes are mathematically perfect, meaning they will roll forever without any drag... which they will have... and some of them already got).

---

and plain "omfg let's jump into the building on the ground" stupidity

Yay!

I then ended up watching the building pieces that I didn't knock off, as every five seconds or so a random building piece would "bounce" and occasionally one would just drop through the platform onto the ground. Ironically, I managed to hit a box up onto the platform and I didn't see the box bounce in the same way at all.

OMFG! or something... that sounds strange... was the platform really thin? I mean, maybe the building pieces are so heavy (compared to the boxes) that they in one step manage to through more than half of the platform (making them tunnel through)? And yes, this is not a problem with the ground plane, as it is... well, a plane, with an up direction. so even if something intersects it, it will still know which way to push it to make it go up on the surface again (instead of falling through).

I found the original build of 0.05 on my memory stick, ran it, and tried to resize it. I lost the graphics.

very interesting. did you compile it? The way I see it, it can either be two choices: something changed in the code (but I don't remember changing anything... ) or there's something with the sdl library that got updated (that we're using for windows compilation) that now supports resizing. I think I remember this being caused by an sdl bug in the first place (some windows-specific resizing function cleared the opengl memory), so the sdl theory seems more likely.


btw: I've now added linear_drag to the good_drag branch (I also tried changing wind to some inssanely high value... really amusing), I'l add the two other (dvanced_linear_drag and angular_drag) as soon as I'm done writing here.

update: ok, all drag simulations are in. It might need some tweaking (car wheels seems to spin too fast when in air?)

update 2a: I've been thinking about the whole wheels in air spinning too fast (resulting in ode simulation errors) thing: what about not adding any more torque to wheels already spinning over a certain value (specified in internal.conf)? After I've merged good_drag, I'll write this feature (should be piece of cake, since the wheel spin is already read, when used for calculating gearing "out-torque").
update 2b: I've also been thinking about the whole busines with the water surface. My first idea was to allow a certain area (in x and y coordinates) to define the placements of "fields of water", and then use a heightfield to define the surface. Each point in the heightfield would be allowed to move up and down, and would be connected to the others next to it using springs. so if something hits the surface, the points affected would be moved downwards, which would (for each step, more and more) pull the other points around them downwards (while themselves being pulled back upwards). The result would be a really flexible (and automatic ) simulation of waves in different shapes (including when they hit hard cornesrs and stuff). Unfortunately, having all water surfaces getting collision detection using heightfields would recuire a lot of processing... But the whole idea would still be poisslbe to implement for graphics (I'm not sure anyone will notice waves aren't actually simulated anyway).
So that takes care of rendering waves... The problem left would be to simulate things moving on the surface of the water... I've played with gmod to see how the "source" engine deals with this, to get some inspiration... Unfortunately, it turned out to not even implement some stuff (well, it's an fps engine, so I didn't really expect it to be that advanced).

The following is a conclusion of what (and how) I'm thinking of simulating:
* water depth: each body will have a "water_depth" value between 0 and 1 (with decimals) indicating how much into the water it currently is (0=over water, 1=completely under water).
* drag: this depth value will be used to change the (good_drag based) drag, by "drag=air_drag+water_depth*(water_drag-air_drag)"
* lifting force: if the depth value is between (0 - 0.5), the body can "bounce" on the surface... The velocity along the water surface multiplied with a value specific for the current body (and of course: the water density) is used to calculate an upwards force which might make the body bounce when flying against the surface (a sphere, or smoewhat smooth object should at least have some lifting tendency).
* rotation force: about the same as above, only the body will rotate when moving along the surface of the water (configured by a body-specific "edgyness" value). for example: a sphere doesn't have any edges, and thus will not (read: should be configured not to) start to rotate so much in contact with water surface, but your lates creation (the sphere with smaller spheres) would have many edges that should make it rotate quite a lot.
* floating force: a force upwards based on "force=water_density*water_depth*volume", which will be high enough to make certain objects float (but I can't think of many... dead pedestrians? ). btw: this seems to be the only thing simulated by "source"

[Mac]

Bah, I had no internet all weekend. stupid ISP gateway went down. :<

anyways. x.x glad you've been busy. XD. I'll have to go fiddle with the good_drag stuff (at long last) and see how it works (and most importantly how it affects the car's handling... I doubt it having an absolute positive affect on car handling, but better drag should mean it should handle nicer than before... I'll find out. I've gotten my car to handle quite nice. )

They will probably not come to a halt, but will break down and roll really slow (after all, the surfaces and shapes are mathematically perfect, meaning they will roll forever without any drag... which they will have... and some of them already got).

but are we not supposed to be simulating a realistic environment? Realistically a spherical object won't roll forever at a very slow speed because air density would bring it to a halt, as would gravity. Also, imperfections in both the sphere's surface as well as the surface it's rolling against would mean it would never be rolling perfectly straight.

Besides, I just find it annoying that the cylinders and spheres just don't stop rolling - especially on the car. The car should coast to a halt fairly quickly if it's at slow speed, but that's just my opinion. Maybe an "autobrake" can be added to the car to apply a small braking force when it's at low speed to bring it to a halt instead of leaving it rolling indefinitely at 1mph.

very interesting. did you compile it? The way I see it, it can either be two choices: something changed in the code (but I don't remember changing anything... Tongue) or there's something with the sdl library that got updated (that we're using for windows compilation) that now supports resizing. I think I remember this being caused by an sdl bug in the first place (some windows-specific resizing function cleared the opengl memory), so the sdl theory seems more likely.

It was your pre-compiled 0.05 and I need to get hold of the original 0.05 sourcecode to compile myself and see. I have a feeling SDL has subliminally updated its windows compiling files (to fix the resizing bug) but unless I try it, I won't know. I'll find out later.


@ wheels spinning too fast in air - yes, I've sure I complained about this before. the wheels shouldn't really be able to affect the car's motion too much (unfortunately for the present time, wheel rotation IS required to control the car midair - no wheel rotation and the car just frontflips .... lame). Also on Rollcage and Stage II, the wheels automatically lost all torque in the air (and eventually stopped rotating) to prevent the car flipping uncontrollably in the air, with some sort of air thrusters/fan implemented to force the car to level out.

Limiting the amount of torque the wheels have in the air would be a good start to give the car more air control (until direct air control using fans can be added). I approve it. it'll certainly make controlling the car in the air nicer - also it'll limit the speed the car can backflip / frontflip, which will also prove as a starting ground for stunt mode


On the subject of the water - let's try not to resort to trackmania if possible. their water simulation is nothing more than arcade. . I don't know how to simulate water surfaces or how to simulate water itself, but the things you're thinking of sound like good ideas or at least to me they sound interesting.

If you can work out how to get them to work, try them. maybe try them in a "water_test" branch and as you build it up I can test how it works on my desktop (power rig) and laptop (more moderate system). since you say rendering the water may require a lot of processing, it'll be interesting to see the differences on the two systems.

Also I'm trying to think of any other ways that water surfaces could be rendered - GTA4 has dynamic water surfaces (if you drive a car into the water, the water ripples) but that game uses all four of my processors to run so I don't know how resource-heavy it is.

Could object cfm not be used to simulate a "soft" surface for the water? that doesn't seem too taxing for ODE but I don't think it's an ultimate solution. Maybe it'll give you an idea.

And for floating force - you'd be surprised but some pretty heavy things are quite buoyant - most things in the game would float - the spheres, the boxes, some of the building constructs possibly - the car itself would probably float in a realistic situation (although for a few minutes, it would eventually sink if it does float). I'd pay to see that - ODE processing and rendering about fifty boxes floating on the surface of water.... slowly rising up and down amongst the waves. lol.


I go to try good_drag now.


edit

I'm liking the new drag - it's a major improvement over the old. The car feels a lot more predictable now, and the changes to the drag have let me mess around with the car's values so it goes pretty quick in a straight line and still has enough angular drag so that it straightens up after a corner.

wind = lol. Set it to 100. You can drive on the walls.

Also I've failed in breaking ODE with the buildings or the boxes - they slow down in the air now, which is fantastic and much more realistic. It means the boxes don't bounce so far now (nor do they fall as fast ... terminal velocity! lol) but the fact that they slow down is great. Also I've watched the spheres and stuff slow down as well. they really should just completely stop at such a low pace, but maybe I can force that on them through internal.conf

btw can you change the default sky colour to 0.5 0.7 0.8? it looks a lot nicer with that colour.

And, you might be interested in this code for the spheres. It makes the geometry on them much rounder (I think it could even be set in loader.c to make the geometry more detailed, but so far it's set at 10).

Code:

void debug_draw_sphere (GLuint list, GLfloat d, GLfloat colour[],
GLfloat specular[], GLint shininess)
{
printlog(2, " > Creating rendering list for debug sphere\n");
GLfloat radius = d/2;

glNewList (list, GL_COMPILE);
glEnable(GL_NORMALIZE); //easier to specify normals

glMaterialfv (GL_FRONT, GL_AMBIENT_AND_DIFFUSE, colour);
glMaterialfv (GL_FRONT, GL_SPECULAR, specular);
glMateriali (GL_FRONT, GL_SHININESS, shininess);

// normals still not perfect, but then it's an imperfect algorithm
int slices = 10;
int divisions = 10;
int i,j,ii,jj;

float slp = M_PI/slices;
float sld = 2.0*M_PI/divisions;
float dx,dy,dz;

for (i = 0; i < slices; i++ ) {
ii = i + 1;
glBegin (GL_TRIANGLE_STRIP);
for (j = 0; j <= divisions; j++ ) {
jj = j + 1;

dx = sin(slp * i) * sin (sld * j);
dy = sin(slp * i) * cos (sld * j);
dz = -cos(slp*i);
//printf("dx:%f dy:%f dz:%f\n", dx, dy, dz);
glNormal3f(dx, dy, dz);
glVertex3f( radius * dx, radius * dy, radius * dz );

dx = sin(slp * ii) * sin (sld * jj);
dy = sin(slp * ii) * cos (sld * jj);
dz = -cos(slp*ii);
//printf("2dx:%f dy:%f dz:%f\n", dx, dy, dz);
glNormal3f(dx, dy, dz);
glVertex3f( radius * dx, radius * dy, radius * dz );

}
glEnd();
}


glMaterialfv (GL_FRONT, GL_SPECULAR, black);

glDisable(GL_NORMALIZE);
glEndList();

It replaces both the "void debug_draw_sphere_part" and "void debug_draw_sphere" sections of the code (look for void debug_draw_box in loaders.c and those two bits are beneath it - this replaces both). I don't know how messy it is for ODE compared to the default sphere code but if you think it looks better having proper spheres instead of box-shaped things, add it in.

edit to cement longest forum post EVER ... probably

Random bit of fun/hacking - on the car. The default car is sort of "basic" and I tend to randomly decide I want to drive something that looks different.



Considering I made it out of nothing but boxes, I also found the code that renders the wheels and made them a tad rounder (changed a value from 10 to 21 - 20 left a gap, ironically).

[Slinger]

So your internet was down? Happens here now and then too. Well, at least It gave me an opportunity to finally try hl2... just gotta love that airboat vs helicopter race

edit to cement longest forum post EVER ... probably

ZOMGBRAINSPLODE!

Also, imperfections in both the sphere's surface as well as the surface it's rolling against would mean it would never be rolling perfectly straight.

Exactly, but the current simulation is a perfect world...    it's got perfect spheres on perfect surfaces

But does it really matter? Since with some more complex track (with obj loader), the ground will be imperfect, which should make things break.
I do agree wheels shouldn't roll as good as spheres, but again, does it matter that much?

Could object cfm not be used to simulate a "soft" surface for the water?

Yes, probably. But I think it might be possible to build a water surface simulation (from scratch) already, but since I've not played with transparency yet (It'll be one of the first things I do when starting on OSD/menus), it might be better to wait until it's possible to actually see things under the surface.

btw can you change the default sky colour to 0.5 0.7 0.8? it looks a lot nicer with that colour.

done!

As for that sphere rendering code, impressive! Since the game will start using obj soon (when done with the cleanup and optimizing the obj loader/renderer)... The whole internal rendering building stuff might not be used for so much longer. It might however be useful in the future to have some kind of model building helpers (imagine wanting to code an object quickly, but not wanting to use a 3d editor to create the models: just specify an imaginary file that will be created by rcx entirely in memory).

I've made some minor changes to good_drag (you probably noticed), thinking it's done now? (I can finally start the c++ porting? )

[Mac]

Personally I think you should leave the code in for rendering boxes, spheres etc as they get rendered now (quad strips and stuff) for:

1) as you said, very quickly creating a basic model that requires no actual importing of 3D models.
and also
2) for debugging, especially with regards to collision boxes/models.

You said a while ago that eventually you will add in code to be able to specify rotation and different objects (such as spheres and cylinders) to represent the car's collision box; however truth be told trying to align the collision box with the model itself is difficult, especially if those boxes are invisible

So, whilst there may be little need for these hard-coded rendering methods, having them there (but possibly just commented out or unused?) for those small things that may require them will be a good idea. I think.


Plus this way I could get the .obj car loading into the 0.05 debug sandbox on my laptop, which will save it a HELL of a lot of time as it's ridiculously laggy on there. (and even with porting graphics to the GPU it'll still lag, the graphics card on it is horrible).


You may also need to add code for resizing loaded .obj files (so I can just resize a 1m box.obj to a 2m box.obj without having to mess around in Blender ) but that's for a later date.

And I noticed you fiddled with the drag and added the wheel rotation limit. Unfortunately, that wheel rotation affects the wheels on the ground too (probably wasn't intentional) so even MY car goes damned slow with it on the default. I've put it up to 80 and, although it does take away some of the purpose of the code, it does stop the car from spinning overly fast in the air.

I've also failed to break ODE. completely. utterly. failed. I went as far as setting world erp to 50 (yes, 50) and I got nothing except a particularly impressive show of flying debris. Is it me... or is ODE happier to handle about 120 simultaneously moving geoms (at a decent speed) than it is to handle 100 of those same geoms sitting completely idle and the other 20 being pushed around onto flippers? O_o


Anyways, the drag is good imo. I can't break ODE with the buildings anymore, so I think that's enough for now go do the c++ port ... maybe you will be able to add back in spont's track editor then. (seriously. I WANT that in... it's fiddly but it's so useful for trackbuilding...)

I even think that track editor would work on the object-loader builds then... providing you kept all the code in to render it with trimeshes. o_O

[Slinger]

Man, I just spent around 2 hours (I think) trying to find some way of getting freebsd to boot from a logical slice ("partition")... Conclusion: possible, but would require a lot of manual work to convince installation system to accept it. Oh well, i'll just use a primary slice ("partition") instead.

The reason is that I've decided to give Debian GNU/kFreeBSD a try. It's essentially the normal debian system (collection of software, gnu and kernel named linux), but instead of the linux kernel (which I don't like because of one main reason: everybody think it's an os?! ), it uses the kernel from the FreeBSD OS.

Lets see the "linux is an os" people explain it to each other: "Yes that is linux... but linux itself is replaced by the kernel from freebsd... but it is not freebsd... in fact, it is gnu and other software... maybe we should just go back to calling "linux" "GNU/linux" instead?" - success!

---

Since the obj rendering system is changed (and will change even more), it might be useful to just wait until obj loading/rendering works as it should (better performance), and then write box/sphere/capsule generation code optimized for the new system?

While still talking about that: how to switch the car rendering between the proper model and boxes? I mean, it could be something simple as a specific key (I assume you don't want to restart rcx everytime switching?). Maybe this should be some kind of debug feature one first must enable in internal.conf?

You may also need to add code for resizing loaded .obj files

It is necessary to request resizing inside the code (change the load_obj resize value and then recompile)... Oh well, you know what I'm about to say: "it'll be solved when scripting is in"

Unfortunately, that wheel rotation affects the wheels on the ground too (probably wasn't intentional)

I didn't expect the wheels on ground to rotate that fast (yet). Since with the default car only got a top speed around 100km/h. But when you are using your car (which I guess got a much higher top speed?), doesn't the wheels go crazy even when they are on ground?


About breaking ODE: I think pretty much all old crashing problems were caused by the old drag (which used ode to simulate too high drag forces) but now the drag is custom (the code reads the velocity from ode, changes it, and writes it back - completely bypassing ode ). But I'm not sure what you meant with ode having trouble with things standing still?


Ok, I'll soon begin with the "0.06_cleanup" branch, in which I will change a lot of things: c++ porting, rewrite credits and readme, make it possible to have several cars at the same time... I actually wrote a list of all things - 15 different things (that I have remembered so far). Some are easy, some are hard and some will just take time. Maybe merge spontificus' track code while at it.

[Mac]

Might actually be easier to merge the good_camera and good_drag into the track editor, since I believe he already ported that branch into c++. You'd have to check if it uses the old wheel_slip code or the current, and add that too if necessary.

I have his trackbuilder version on USB - but with the old wheel_slip not the current, so if you need it I can default the sandbox and send it (got loads of junk on it.... lol)

While still talking about that: how to switch the car rendering between the proper model and boxes? I mean, it could be something simple as a specific key (I assume you don't want to restart rcx everytime switching?). Maybe this should be some kind of debug feature one first must enable in internal.conf?

I didn't think about that, ironically.
But, there are a lot of debug/test things I want to eventually see added (for debug and for fun) such as a physics slowdown key (or indeed physics speedup, if you change the values for it ) and a key to give the car a forward push (could both be used to dislodge the car from a particularly hairy position (i.e. suspended on boxes) or indeed used to test the car's reaction to a "speed boost" ). Maybe these (future) debugging things could be added as toggles in internal.conf. Maybe a "debug.conf" could be used too, and if the game doesn't find that file and the respective toggles, it just loads defaults (hey, we are developers. we hide developer tools ;P)

Come to think of it, a toggle to enable and disable drawing of collision boxes would mean that you would then have code to toggle drawing of the car model itself - so you can disable drawing it when in cam1. SOLUTIONS! ^^

I didn't expect the wheels on ground to rotate that fast (yet). Since with the default car only got a top speed around 100km/h. But when you are using your car (which I guess got a much higher top speed?), doesn't the wheels go crazy even when they are on ground?

Nope. On low stepsizes (0.02 as an example) the axes bend quite a lot, but only when the car is either cornering, or crashing (in which case the front wheels end up becoming skewed compared to one another - //-[   ] -\\ <- like that, assuming that's the front of the car), but in a straight line the wheels behave.

I use a stepsize of 0.005 because a) my computer can handle it quite nicely (lol) and b) because the higher stepsize causes less noticeable precision errors in collisions and with the wheels. They still bend while cornering and from excessive car rotation, but most times it's barely noticeable if at all. My car's only got a top speed of about 250 km/h anyway, or so I assume. I need to find that thing you added to print the car's velocity and enable it so I can find out the precise speeds I can get it to. It actually handles quite nicely too ... has a bit of oversteer at low speed and a bit of understeer at high speed, but it's usually quite predictable and it's possible to make it powerslide by steering and immediately counter-steering to make it fishtail. I should send you it so you can look at it. :]


AND YES. MOAR CARS. PLEASE. to be honest the sooner you start with that, the better. Testing with multiple cars on the object-loader build will, until you optimize it for better performance, be very difficult as the combination of a complex world and two or three cars will lag even my system. Testing on the current build for how the game can handle several cars will be easier with that respect. I'm sure it could easily handle four cars at once ... it could probably handle a split-screen view and two cars being controlled simultaneously better than two .obj cars and the .obj world. xD

I want to see your list so I know what to expect.

But I'm not sure what you meant with ode having trouble with things standing still?

I believe that ODE may use more processing power to calculate if a geom requires enabling or disabling than it does to calculate the same geom in motion (or in collision with other geoms). I find I lag more at the start of RCX with everything sitting still than I do with everything bouncing around.

it's probably just those buildings. (lol).

edit

I will probably be away this weekend (going to a friends) and definitely next weekend (gaming tournament). so... over these certain days don't expect me to reply to anything you post. expect me to read a lot of information on Monday and reply then.

[Slinger]

Perhaps just a separate branch with development-specific features (then no need to add values to internal.conf)? For stuff like "box toggling" (I seem to like to make up new words and expressions ).

I need to find that thing you added to print the car's velocity and enable it so I can find out the precise speeds I can get it to.

Assuming you are using good_camera, you should be able to find a section in physics.c with the following:

Code:

                //save ccar velocity
                const dReal *vel = dBodyGetLinearVel (carp->bodyid);
                const dReal *rot = dBodyGetRotation  (carp->bodyid);
                carp->velocity = (rot[1]*vel[0] + rot[5]*vel[1] + rot[9]*vel[2]);

Just add a printf like so:

Code:

                //save ccar velocity
                const dReal *vel = dBodyGetLinearVel (carp->bodyid);
                const dReal *rot = dBodyGetRotation  (carp->bodyid);
                carp->velocity = (rot[1]*vel[0] + rot[5]*vel[1] + rot[9]*vel[2]);
printf("%f\n", carp->velocity);

And you should be able to follow the car velocity for each step printed to stdout. Since you probably configured sdl with default settings, it modifies stdout to be written to stdout.txt (instead of the real terminal text output), which will make it more difficult to follow the velocity at realtime (but will be usefull to find real topspeed).

I want to see your list so I know what to expect.

Many of them are simple stuff like "rewrite readme with spell checking" and "gcc -> g++" and "change default eye_distance"... Most of them will be done quite soon (since I'm now starting on them).

I find I lag more at the start of RCX with everything sitting still than I do with everything bouncing around.

I remember you mentioning that before... This sounds like trouble. Lets hope it's the "building"s... somehow.

I will probably be away this weekend (going to a friends) and definitely next weekend (gaming tournament). so... over these certain days don't expect me to reply to anything you post. expect me to read a lot of information on Monday and reply then. Wink

"gaming tournament"? Well, I wish you the best of luck!

And on monday, expect the "0.06_cleanup" branch to be overflowing with random commits.

[Mac]

Interesting.

I tried that and got this as the highest top speed I reached, going from one corner of the sandbox to the other (covering a distance of probably 600m): 69.485244

I remember you saying that it's measured in m/s so I need to convert that to km/h, but since yours didn't get above 20 m/s and you worked it out to be roughly 80/100km/h I daresay it's probably about 250-300. I'll do more tests later to determine the outright top speed the car has. :]

I'm in the process of trying to get the car to stop overturning on the rescale build I set up, I've gotten fairly close. it's still a lot more twitchy than the normal build, but at least now it straightens out after a few seconds. Oddly, setting world erp to 0 completely nullifies the weird oversteer, but then the car refuses to bounce when it crashes.

That's all I can type for now. Dinner time.


edit

69 m/s works out to 250km/h. (155mph). That is, ironically, the critical speed for cars in Rollcage 1 to be able to drive on the ceilings. I'm presuming that over time the car will eventually get to 300 or higher, but my sandbox isn't big enough.

Personally, I feel that's the sort of speed that the tier1 cars should be aimed for - the 250-300km/h range. So, really what we need to do for the cars when the time comes is

a) improve the game's friction to allow the cars to handle better and accelerate better from standstill without flipping over
b) add the downforce to the cars to help the handling and for anti-grav stuff
c) fine-tune the suspension (I still don't feel the suspension_elevation code is perfect. it's a step in the right direction but doesn't work perfectly how it needs to).

Once we get the acceleration and handling sorted out, tuning the cars to give them a finite "own power" top speed will be easy. after that, we'd need to look at adding code to change these in real-time for certain things (such as for turbo boosts and stuff).


But for now, it's not a problem. I'm starting to get somewhere with the current car's code. What I need to do is finetune the default car under default gravity (make it faster) and send you it. since people seem to complain the default car is slow, a slightly faster car might prove more popular. :]


yay for 0.06_cleanup branch! :3 I will probably waste a lot of time just downloading these random commits and compiling them.

edit again

Here's my bit of interesting research for the day - with the wheel rotation limit code, setting it to 20 limits the car to a speed of 30 m/s and setting it to 50 limits it to 75 m/s. 75 m/s is  270 km/h. So, if we're to use that to outright limit ground wheel rotation as well as air wheel rotation (hint hint) then the ground value will likely be set to 100 (which should limit speed to 540km/h - the approximate ground top speed of ALL rollcage vehicles to date - don't believe me? test it. ).

This could theoretically be used to give different ultimate ground speeds for tier 1 cars compared to tier 2 (to limit them to a speed under 350, which they can't surpass even with turbo boosts) as well.

interesting research over.


edit on Friday

I believe I've succeeded in finding a balance on my rescale build between world hardness and vehicle control, and the car seems to handle similar to the normal build, only a little slower accelerating because it has more wheel drag. (fail)

It doesn't crash as good but I've worked that out as being due to the suspension being more solid (on the normal build, landing on the car's side compresses the suspension and bounces the car back up - on the rescale build, doing the same thing results in a lesser bounce as the suspension stays solid). the car tends to handle, brake, powerslide, jump and land the same as before, so that's good.

:B needs better suspension though. much better suspension.

[Mac]

Doublepost.

Just want to let you know (unless you see it before you see this) but I checked the 0.06_cleanup branch today and tested the latest commit.

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.


Also I HAVE succeeded in finding a stable cornering on the rescale build - the car handles very nicely, if a little loose when cornering at speed. It doesn't infinitely drift in a wide circle and I also got it to stop flipping over when accelerating from a standstill (a tweak of wheel_mu and throttle_speed). So yay. If you want, when you've done the 0.06 cleanup and everything is sorted, I can go rescale all the masses and other necessary variables and such. I tested it all with double gravity but I only need to weak motor_tweak and wheel_slip for normal gravity for the car to start handling nice for that.

[Codie Morgan]

Send me that mac

 Win32 =)

[Mac]

The 0.06_cleanup branch is still using the old graphics, not the object loader O_o

Same with the good_drag branch (and the camera). x.x although if you're not bothered about that, I can send it.


...you'd be able to model me a bumbleball too with it xD hell yeah ODE collision trimeshes.

[Codie Morgan]

Yeah I know =)

Just want to toy with the differences

[Mac]

http://www.animechatforums.com/mac/RCX/rescale.rar

You'll have to excuse the mess that is the ramps, but I was just messing around and I can't be bothered to remove them.

Should run fine - I got that with the exact same settings to run on my old laptop, which has a 1.5Ghz Celeron M and 64MB shared graphics, and it ran it at 30fps without any weird glitches. If it lags though, get rid of some (or all) of the buildings and try again, or change the stepsize to 0.01.

Don't try 0.02 because the suspension is stupid, and the wheels go mental. (I now understand why Slinger talks about axis bending problems. xD). if it runs on 0.005 leave it on 0.005 as that's what I tuned the car and stuff for.

Also have fun with the littlebox, box, bigbox, hugebox, oddbox and bumbleball objects. oddbox and bumbleball can be spawned with F8 and F9, bouncy balls can be spawned with F7 and are a good test with the wind. stdout.txt also prints car velocity (in m/s) so you can fiddle with the car and work out how fast it goes.

Enter also pauses the game.

(that is also the rescaled mass build - Slinger, you should look at it as well if you want. )

edit


snap, I uploaded the wrong one.

I think you need to go into internal.conf and change stepsize and iterations. change stepsize to 0.005 and iterations to 10. I left it on 0.02 I think -.-

edit

I need to reupload. I have just done something which has solved the rescaling car-drift bug more than I thought possible - I CHANGED WORLD CFM TO 0.1

There is absolutely no goddamn difference in how everything collides, but it makes the car handle......... like a dream. it turns so much better than it did before ... it now exhibits a very pleasing oversteer at low speed (= powerslide) and is quick to straighten up after a turn, as well as having a hell of a lot better cornering angle (and speed, it seems)

I've even been able to put world erp and wheel erp back to 0.8. o_o AND, I've been able to set the wheel's steering axis to 2.8 (the wheel's centre, a la rollcage) without it sliding - on the non-rescaled version, doing that made it slide all the time.

I'm awesome *-* I deserve cookie.

and uploaded. same link. I lowered world erp a little just because it prevents the car from bouncing on landings a little more. the car shouldn't be able to flip over from accelerating from a full standstill, though it might if accelerating from a small backwards velocity - still a good idea to tap the throttle two/three times from near-standstill speeds to make sure.

Lots of stuff to knock around AND a nice-handling car too. maybe Slinger's side-slip code isn't as bad as I thought it was.. :]

yet another edit

cam4 + relative damping = epic for crashing.