# Bow_vernon

Member

454

1. ## Random terrain generation with fixed elevation

Hi folks, a fellow gamedev here. So recently I've been trying to make a business simulation games (similar to Holiday Island or Sim City), and start moving on the vital element of the game: terrain generation and manipulation. The terrain is a simple heightmap with a randomly generated height values (I haven't implemented the random generation part, cause of this issue I'm talking about). Basically, in my game the terrain has to have fixed elevation, so when you compare a terrain vertex to its neighbors, they could either: have similar height have a 0.5m height difference (higher or lower). It must not have more than 0.5m difference. I need to do that to simplify the terrain manipulation (the game kinda heavily relies on it). I was thinking on simply generate the random height first, and then loop over every vertex to force its offending neighbors to lower/heighten itself accordingly. But alas it just doesn't seem to be the right way. Perhaps any of you ever done similar things in the past? I hope you could give me any advice on this matter. It's been boggling my mind. basically this is the game that inspires me.
2. ## raycast vehicle physics problem

That would be the black arrow in your drawings, right?   Yes sir. I apply the force along the black arrow (normal of ray hit)
3. ## raycast vehicle physics problem

Hi people, I am now attempting to implement the ol' famous raycast vehicle physics. Based on several readings, particulary:  http://blog.spaceduststudios.com/space-dust-racing-unreal-engine-4-arcade-vehicle-physics-tour/ https://docs.blender.org/manual/en/dev/game_engine/physics/types/vehicle.html It works fine most of the time, as long as I satisfy these constraint: the raycast have to be of similar length (the suspension+wheel radius) cannot differ from one another. the suspension properties must be uniform (the spring coefficient(k) and damping coefficient(c)) cannot differ from one another. Here's how I do the vehicle physics: for each wheel, each frame: shoot a ray from the wheel suspension start position (in absolute frame) towards the absolute ray direction. Usually this is down (0, -1, 0) in local frame. from the raycast detection routine, I got several useful information (the "time of impact" of the ray hits [0..1], the ray hit position (where the ray hits), the hit normal (the normal of the ray hit position). then I calculate the suspension force (Ignoring the side slip friction and forward/brake force atm, focusing on the "hovering" first). the suspension force is then applied at the chassis @ suspension "start" position, and the opposite force is applied to "ground" @ rayhitpos. The force direction is parallel to the suspension direction (ray direction). As I said, as long as the rays are uniform (similar length, spring coeff and damping coeff), it will works fine. Thing is, I'm trying to simulate a dune buggy, where the back suspension would have longer travel distance, also the back wheels are bigger in diameter than the front ones. Now that means I have to Make the back "ray wheels" have longer suspension travel and bigger radius, resulting in non uniform suspension length and spring properties. Also, the buggy suspension is not uniform. The back suspension is directed a bit backward, and the front suspension is directed a bit forward (this is called "caster angle", usually configured like that to smoothen up the ride). Now because of this, the vehicle would gain forward speed most of the time, because the net force applied would cause the chassis to move forward a bit. I am thinking of instead of applying the suspension force along the suspension travel direction, perhaps it would be better to apply the force along the ray hit normal. This would cause the chassis to "float" along the ground just fine, since all the force are acting along the ground normal ("up" usually), so no lateral force would emerge. But is it the right thing? how did the vehicle physics in GTA 2 Vice City was implemented? Because one of the vehicle there (the "harley" bike) exactly configured like this (the front wheel's suspension is slanted @ 45 degree, not totally "down"), and the bike would ride just fine.   Here's an image that depicts the problem: in the non-working case, the vehicle would move to the left, this is without side friction or forward/brake force (it shouldn't, right?). the red line is the ground, the blue is the ray, the black box is the chassis, the black arrow is the ground normal (rayhitNormal), and the brownish arrow is the suspension force, which is applied at the "raystart" (which is the end of the blue line inside the chassis)
4. ## Car skidding behavior

Hiya fellow gamedevs!   So I finally implemented the so called Pacejka "magic" formula (correctly). It allows the car to steer around like a car supposed to. However I only use Pacejka for lateral (cornering) force so far, the longitudinal is still using simple formula that works well enough. But that's not my problem. My problem is the car now can skid (spin uncontrollably), and of course a countersteer is sometimes enough to alleviate it. But I haven't factored the driving force in skidding behavior. The question boils down to this: suppose a rear wheel drive car (2WD) is spinning to the right, so we do a counter-steer, but suppose this is not enough to stop the car from spinning. in that situation, what is the effect of hitting the pedal to the metal? would that make the car spin even worse?  in that situation, would hitting the brake (slowly perhaps) helps the driver taking back control of the car? I wonder because: I don't have a car nor a skidpad or a wide field to test it myself lel  :P This video  basically stated that just let go of the gas(let the wheels free rolling?) or was it to push the pedal slightly(reduce drive force?) damn my listening skill is not good :( The behavior of the car in Need For Speed Porsche Unleashed ™  is kinda against the tips in number (2). Usually in the game, when you corner without hitting the pedal (turning while the wheels are free rolling), your car would spin, and hitting the gas in that situation would help reduce the spin (you gain back control). While in the video in number (2) states that hitting the gas while spinning would make your car go 180. Also what I don't understand is, in the game (NFS PU), it's basically impossible to have your car spinning when you turn around the corner while hitting the pedal. Your car would instead do a high speed, understeer turn. What is the true behavior of a car in such situation in real life? Thanks pal. I've been trying to play the old games again (it has seriously the most realistic physics for the car game in that time IMO), but to no avail. It keeps crashing because it uses DX7 for rendering.
5. ## Problem implementing soft collision contact (and impulse based spring)

Hi people, so I'm trying to implement the impulse based spring (soft constraint in general). I read erin paper, where it talks about CFM (constraint force mixing) and ERP (error reduction parameter). I just cannot make sense out of it. I tried looking at the Box 2D source code, to no avail. Can anyone give some explanation? basically when solving for impulse P, the equation is divided into two parts, I call them the velocity solver part and the position error projection part. For example, here's how the collision impulse is calculated in my engine (inelastic collision): impulseNormal = (-velocity . contactNormal + posError) * massNormal; // velocity is velocity at contact point // contactNormal is normal vector // posError is the bias term (the penetration depth adjusted with small slop) // massNormal is the effective mass along the normalDirection at contact point // I call the (-velocity . contactNormal) the velocity solver part, and // posError the position error projection part Now my goal is to make the collision resolution "spongy" or soft. Basically in general I wanna make my engine capable of simulating soft constraint. But I just cannot fathom how the CFM and ERP affect the impulse calculation. Perhaps there's some good books that explain this in an easier way? perhaps a naked/stripped down implementation that I can take a look at? sorry if this is too much to asks. I've been losing sleeping over this things.
6. ## The tick rate of old console games

Hi all, since I'm not sure if my question belongs in specific sectiin, I'll ask here. Does anyone know the common tick rate of old console games (amiga64, psx). I wonder because recently I watched several longplays (where people play games until it's finished), and noticed that some of the games were rendered @ 60fps. Holy molly. I thought amiga64 < psx in term of processing power? Also, some of the early car sim game (gran turrismo anyone)? And some dude's name rally games were available back then at psx, which was amazing simulating all those at 30(felt like) hz. Also does the console (specifically psx) dictates that the tick is hardwired to 30hz? I know that this is not the case with ps4, but since I never saw any psx games with >30fps render rate, I'm not sure.

8. ## raycast vehicle physics problem

Ah, finally the problem was solved. I simply apply the "suspension force" along the normal direction of collision. This works well enough for my purpose. Thanks pal.
9. ## The tick rate of old console games

Wow, that's a lot of information. Btw I made a typo. I meant to compare n64 vs psx (not amiga vs psx). But I got my question answered. Thanks.
10. ## That old dos game

Hi people. I've lost sleep over that old dos games that I still can't remember. It was an old adventure game like zelda, but the protagonist was a young indian, like disney Hiawata. The first weapon was bow and arrow, and the enemies were like wild animals and such. Do you know its name? I've been googling with no luck. Even seeing the old dos games compilation on youtube didn't help.
11. ## That old dos game

Yes it was topview like zelda are you sure it was originally a dos game and not a port from some other platform, like amiga or something? it doesn't sound like your typical dos first game from the VGA era. more like a port. as i recall, mode13H was the big deal about VGA 320x200x256 palletized colors. combined with a 386, and you could write a raycaster like doom in a couple of man years or so.Now this is what I suspect. I've searched thru the dos games list @ dosgamesarchive.com which provides screenshot, and I didn't find it there. Now I think it might be port from amiga. Gonna search again! EDIT: FOUND IT!! turns out it was originally released for amiga and sega cd. The game title was "Legends". Here's the detail of the game: http://www.lemonamiga.com/games/details.php?id=1767
12. ## That old dos game

I believe it was vga, cause it uses 256 colors and was smooth enough to me.
13. ## That old dos game

Ahh sadly that's all I remember.you started at plain meadow, so green. Also the indian boy wore a bird feather in the back of his head. The art style is like zelda (cute/chibi). All I can say is the protagonist pretty much looks like disney's Hiawatha
14. ## Inflat/Deflate convex shape for gjk core shapes

Hi people, I've been working on my physics engine. I recently do a performance testing of each integration steps (broadphase, narrowphase, solver, etc), and found out that the narrowphase took the most out of execution time. I thought it was reasonable because I simply use EPA to generate contact point. Now most presentation of physics for games that I read suggest using gjk + core shapes to generate contact point. I already have the gjk part implemented nice and sound. Now, how do I inflate/deflate the convex shapes though? scaling by its center would result in non-uniform scale, that is, the distance of the "inflated" to the core shape is non-uniform. Here's a picture showing the non-uniform scaling problem.   the green box is the core shape, the red one is the inflated shape, scaled up to 1,5x. but now the distance between the core and the inflated one is non uniform (Here, dX should equal dY!). I've been thinking of how to solve this, but to no avail. How would I generate the inflated shape based on the core shape + margin?
15. ## Inflat/Deflate convex shape for gjk core shapes

After tinkering a bit, I implemented iterative solution for this problem, and it worked nice! but perhaps non optimal, but since it's an offload process, it's fine. Anyway, here it is showing the "core shapes" + pure gjk for contact generation (at around 34 seconds mark)   Thanks for the reply! after toying a bit, I implemented the iterative version of this. Basically, each vertex has to satisfy a series of linear equation, and then I solve it using gauss seidel iteration.   The quick hull!! it really helps tremendously in visualizing the CSO. Thanks for the share. But in the end, I yield to iterative solution, I'm gonna read your solution thoroughly later though!   Thank you for the link! gonna read em.
16. ## Inflat/Deflate convex shape for gjk core shapes

Uh... Hi Mr. Gregorious, happy new year!! Btw I can't seem to follow the dual space thingy. I've been reading the article at wikipedia, but aaghh, I just don't understand. I can push the faces inside by specified margin, this will result in faces that is overlapping with each other, as shown in these pictures:   the red is the original convex shape, the light blue one is with the face "pushed in" along its normal as far as the specified margin. Is this what you mean at step 1? I reckon you meant to push the faces back by dividing the normal plane +/- margin? but at step 2 you said to build convex hull? doesn't that mean step 1 should produce clouds of points? ugh, I got confused....can you maybe...show some pictures? sorry if I bother you.
17. ## incremental persistent manifold - sliding box on inclined plane problem

Hi all, sorry if I start annoying you with my posts :P   So I recently added a persistent manifold in my simple physics engine. It worked nice and fine, until I try to slide a box down an inclined plane. Basically the box slide with a bit "jerky" movement (along the normal), because the cached contact gets broken now and then (it causes contact to come and go). But first, here's how I store my contact. A contact contains these information: world position on body A world position on body B local position on body A local position on body B normal depth each frame, the manifold gets refreshed. then the contacts get removed if they become invalid. Here's how I check if a contact becomes invalid: based on current bodies transformation, compute world position on body A and B vAB = world position A - world position B; calculate new depth: depth = vAB.normal; (normal pointing to body A, so if it's positive, it means it's separated) "flatten" vAB on the collision plane: vAB -= normal * (vAB . normal); now we can calculate 2D distance along the collision plane dist = vAB.vAB;   valid if: valid = depth < tolerance && dist < CACHE_DISTANCE_TOLERANCE; and I simply remove them if they become invalid. For most of the time, the bodies tumble and come to rest just fine. I also add debug rendering of the manifold, they show just fine. But on the sliding case though (especially when sliding fast), there goes the jerky problem. It's not too visible if the box is sliding along the ground plane, because the friction will slow it down quickly, resulting in cache hit and faster convergence which will cause the body to come to rest. But on inclined plane, however, they're gonna keep moving (cause of gravity), and sometimes the friction wouldn't be strong enough to stop the bodies from moving along the inclined plane. Here's the problem shown in pictures (pardon me of the picture).     At t0, the box has just fall down on the inclined plane. GJK+EPA calculate a collision point (the red is the collision point on body A, the blue one is on body B). At t1, the box has moved, so the cached contact has to be refreshed. We recalculate the world position based on the local points stored in the contact. the blue point is still there (cause the box is not moving and has infinite mass), while the red has moved. Now the distance has become too far, and we remove the cached conact. At t2, GJK+EPA get new collision point (it's on there because the box has rotated a bit, of course). And we add it to the manifold. Now repeat to t0. Basically, on an inclined plane, the manifold will have their contacts appear and dissapear quickly, resulting in jitter. So how would you solve it? I tried to look for similar cases on youtube, but there's no videos on the subject. Also, this happens only for incremental manifold. For one shot manifold (clipping features), it doesn't happen of course, because you would always have full manifold that is stable. If you have any ideas on how to solve it, or have experienced such thing, please share your knowledge. Thank you, fellow gamedev.   EDIT: rusty english, mixed tense. sorry.   EDIT2: the problem is quite visible at the original simulation rate, which is 30 Hz. When I crank it up to 60 Hz, it's basically.....kinda disappear (no visible jitter). My conclusion is perhaps because of much higher refresh rate, whilst moving slower each frame (due to smaller timestep), the cache hit rate increases, so the convergence gets better. But still, c'mon, I intend to do it @30 Hz for my android game :(
18. ## incremental persistent manifold - sliding box on inclined plane problem

Thank you Mr. Gregorious!! that material really helped (although my lack of mathematical knowledge got in the way fast). I got Ball/Sphere joint and distance joint implemented. Question: Why can't I warmstart the distance joint though? With the sphere joint, I could accumulate impulse, and apply them at the next frame (before computing the new Jacobian).   Here's how I calculate the constraint mass of my distance joint @Override public void preCalculate(float dt, float baumgarte) { // update position worldA = bodyA.toWorld(localA); worldB = bodyB.toWorld(localB); Vector3.sub(worldA, worldB, n); // grab bias. no slop needed bias = (length - n.length()) * baumgarte / dt; // totally stiff // normalize direction n.normalize(); // calculate mass? kMass = bodyA.getInvMass() + bodyB.getInvMass(); Vector3 r = new Vector3(); Vector3 rn = new Vector3(); bodyA.getRot().transformVector(localA, r); Vector3.cross(r, n, rn); Vector3.cross(rn, r, rn); bodyA.getWorldInvInertia().transformVector3(rn, rn); kMass += Vector3.dot(n, rn); bodyB.getRot().transformVector(localB, r); Vector3.cross(r, n, rn); Vector3.cross(rn, r, rn); bodyB.getWorldInvInertia().transformVector3(rn, rn); kMass += Vector3.dot(n, rn); kMass = kMass > 0 ? 1.0f/kMass : 0; // should do warmstart here, applying old impulse, // but the joint would blow away!! // bodyA.applyImpulse(accumP, worldA); // bodyB.applyImpulse(accumP.inverse(), worldB); } basically, It's quite similar with contact constraint mass calculation. Nothing special I guess. The bias term is the difference between the target length and the actual distance, am I right :unsure: ?   and here's the solver part: @Override public void solve() { Vector3 j = new Vector3(); Vector3.sub(bodyA.getVelWS(worldA), bodyB.getVelWS(worldB), j); float jMag = (-Vector3.dot(j, n) + bias) * kMass; j.setTo(n); j.scale(jMag); bodyA.applyImpulse(j, worldA); bodyB.applyImpulse(j.inverse(), worldB); // accumulate impulse Vector3.add(accumP, j, accumP); } basically, jMag = (-deltaV.n + bias) * kMass;   then I apply the impulse to body A, the same with body B, albeit with different direction (inverted).   which is pretty similar to contact impulse calculation. it worked just fine, the difference is, I dont clamp it against accumulated impulse, since it is an equality constraint. Applying old impulse (when calculating the jacobian) would cause the bodies to go crazy. perhaps warmstarting is not needed at all for this type of joint?   EDIT: I seem to forgot to mention that the distance joint works just fine without warmstarting, but it kinda itches me though, why can't I warmstart the distance joint the same way I do ball joint?
19. ## incremental persistent manifold - sliding box on inclined plane problem

Hi Dirk! Thanks for the material. Yes, in fact I was inspired by your slides, although I didn't use "core" shapes margin+GJK closest points. I simply let bodies overlap and use EPA to compute contact points on both bodies. I already implemented the one full shot manifold, and indeed, there would be no such problem. Thing is, I love incremental manifold, it looks elegant, fast, also works with common convex shapes (I need to support cylinder + cone) with no hassle (only need support point function, no clipping stuffs). To my surprise, it worked well enough for stacking things. I didn't implement feature id though (I used to do that, but dang, that adds a lot of complexity). One thing that I note though, it seems to happen at low simulation rate, perhaps because I used simple baumgarte stabilization to correct position error. With huge timesteps, it cause huge overlap,  resulting in huge added energy, which might explain the jitter back and forth on inclined plane. I recently implement split impulse and sort contacts from bottom to top, so lowest manifold gets processed first, albeit it was still a "hack" basically, but it worked great!! no more visible jittery movement, also stacks got more stable, even @30 hz, 7 solver iteration, 3 position solver iteration (I could stack up to 7 boxes). I have not implemented joint yet, the computing Jacobian for joint is confusing for me. Do you have any source that explain it in a more "geometrical" way? all tutorials do it in pure mathematical way, hard to follow.
20. ## Generating contact point from EPA Convex Hull [SOLVED: See comment for solution]

SOLVED IT!!! Turns out it's a pretty simple, actually. So whey you're building the minkowski difference, you don't simply store the support point  Support (ShapeA, dir) - Support (ShapeB, -dir) But you actually need to store the support points themselves. Then, when EPA runs (blowing up simplex), you also do the same (store the support point in A and B -- they are in world space).   Finally, when you terminate from EPA, you must have found the closest EPA triangle from the origin. Simply compute barycentric coordinate of projected origin on that triangle, and then: you can calculate world space contact point of Shape A --> using the support point A stored along the CSO vertex you can calculate world space contact point of Shape B --> using the support point B stored along the CSO vertex but that only gives you single contact point, you need to cache and building a manifold over the frame. As for the caching scheme, many exist. I for one use simple distance based caching. And only remove separating cached contact (i.e., contact point A and contact point B are no longer overlap).
21. ## Generating contact point from EPA Convex Hull [SOLVED: See comment for solution]

Hi, people. This is another thread by me about generating collision contact with EPA. For now, my method is one shot full contact manifold generation. But I thought I ever saw someone said that I can get a single contact point using the EPA convex hull (aka the resulting polytope). He said something about transforming the closest EPA triangle into world space. I can't wrap my head around it, because as I know it, the vertices of said EPA Triangle are made of minkowski difference between the two shape (in world space configuration, of course). And then, how do I transform the EPA Triangle into world space? Which shape's transformation matrix do I use or how do I combine them (because there are 2 shapes, so there are two transformation matrices)?
22. ## Generating contact point from EPA Convex Hull [SOLVED: See comment for solution]

That's what I'm confused at. Logically, the Polytope result from EPA is the convex hull of shape A and B (in minkowski difference though). So it follows that the closest triangle to the origin contains the collision point (it is the only triangle we're interested at). I already got the triangle. I already did compute the origin's projection's barycentric coordinate, in which once I get the triangle in world space, I could simply get the collision point by calculating   tA * u + tB * u + tC * w (u,v,w: barycentric coord. tA, tB, tC is the vertices of EPA Triangle). What I don't know is the transforming of EPA Triangle (minkowski difference space) into world space. Googling doesn't help though.   EDIT: half dizzy typing, scrambling words. sorry.
23. ## Generating contacts from EPA result (normal + depth)

I decided to implement the one shot manifold as described in that paper, and it works nice!! I haven't implement contact reduction, but I will once I move to 3D, I guess. Thanks a lot pal for your contribution! Wish I could +1 you again.
24. ## Generating contacts from EPA result (normal + depth)

I've been working on a simple physics engine in 2D, but will translate to 3D after everything works right. Right now I have GJK for collision detection, which will return a 2-Simplex (a triangle) containing origin when the two shapes are colliding. If collision is positive, I run EPA using the returned simplex for initializing polytope. When the EPA terminates successfully, it will give me collision normal and depth, which when combined would give me enough information to separate the two shapes.   But now I need to generate contact points. What suitable method would be best to use with GJK+EPA? in the past, I did it by identifying the closest feature of both shapes (most aligned "face" with collision normal), and clip them against each other. But it was when I was using SAT algorithm, and I used special data structure containing a shape's feature (Edge+Face List, mainly. It was 3D. Also it only supports box so far). But I'm looking for a simpler method now, since GJK+EPA are more generic than SAT, I lean more towards them. Also, I didn't store feature(face/edge) in the Shape data structure, only its vertex (in clockwise order, also they must be convex). Because the "Feature" are so diverse (in 3d, we can have triangle-face, quad-face, planar_polygon-face, even curved surface as a "face/feature" of spherical shape).   TL;DR; So what is the most suitable method for generating contacts when one is already using GJK+EPA?   Below is some of my WIP 3d physics engine. Support box only so far. Using SAT for collision detection, and use some feature identification + clipping to generate contacts. based of Box2D-lite (it's basically 3D version of Box2D-lite). Has contact caching, support warmstarting, also support stacking (the number can get quite high depending on the simulation rate and the solver iteration). Stacked boxes wiggle around for a while before resting in peace forever.   2d implementation of GJK + EPA. Red and White shapes : the shapes being tested for collision Yellow triangle : Simplex returned by GJK Red-Purplish shape : 2D Polytope generated by EPA Green dot : origin   I didn't show the collision normal + depth, but it's there.