Bust! Some physics requests…

About Monkey 2 Forums Monkey 2 Development Bust! Some physics requests…

This topic contains 56 replies, has 8 voices, and was last updated by  DruggedBunny 12 months ago.

Viewing 15 posts - 31 through 45 (of 57 total)
  • Author
  • #14578

    Mark Sibly

    Very cool! Landing on its own is quite fun, how about…

    • A landing zone target(s).
    • Ability to crash the landing if you’re going too fast or land too far from target.
    • A velocity readout/indicator, perhaps turns red if you’re going too fast?


    Yeah, landing pads and crashing are on the to-do list, probably flying through hoops and stealing the orb, plus fuel/fuel collection.

    Still fighting my camera, not got it any better than in the last update, but it’s not too bad, so will live with it for now.



    Just a minor update after finally figuring out collision groups — smoke now collides with terrain, without affecting the rocket (which got knocked off course by the smoke objects last time I added this). Just a nice visual effect, but landing pads should be easy now too!

    Source code

    EDIT: Ignore below, seem to recall there was a fix for this, not updated yet! Just means the web version will fail for now…

    However, it seems to fail on Emscripten here:




    Fixed web version with ground-colliding smoke particles. (Note that thanks to collision masks/groups they don’t collide with and affect the ship as they once did.)

    As an ‘also’ ahead of the main question: would it be possible to get shadows for alpha’d entities? Even if it uses the non-alpha’d entity to generate the shadow, and just alphas the resulting shadow, that would be cool. (No idea how shadows work.)

    EDIT: IGNORE, major “Duh” on this part below — Collide (body:RigidBody) refers to the OTHER body! Works fine using the correct body! Still need to figure out correct velocities for my triangles, but basically good.

    Anyway, I’m trying to get the velocity of a body at the time of collision, but it always seems to be 0, 0, 0. Any idea how to get this? Wondering if it’s stored in some separate collision info?

    I’ve even tried storing the body’s velocity just before calling scene.Update but the result is still 0 when the Collided callback runs…

    This is a very messy WIP, but I’ve highlighted the relevant points with ' CHECK_ME!

    My triangles need work, as I have to use boxes for their bodies… might amend the resulting triangles to rects to work around this.

    In reality, it needs a proper model and a chunkier ‘split-parts’ model to do it properly, as I’m skipping many tris when splitting the model, and it’s still slow in webgl.

    If I can get collision velocities, though, it should look pretty cool in the meantime.



    A problem I just ran into while trying to add ground collisions — even though collision masks/groups seem to be set up correctly, terrains seem to always trigger the Collided callback, even while not colliding:

    Stripped-down sample

    Note colliding with ground while falling.

    Also note in previous post with no terrain, collisions aren’t erroneously triggered all the time as they are here.



    Added landing pads — they recharge your energy level (which currently does nothing when zero), 5 pads in the main area and 5 scattered in and around the mountains — the latter of which in particular highlight the camera limitations for close-up work, unfortunately!


    Can’t do ground collisions yet due to the aforementioned problem.


    Mark Sibly

    Nice find on the collision detection stuff, I was doing it wrong. Things were actually colliding with terrain even if just bounding boxes intersected, should be fixed now.

    Note that CollisionMask and CollisionGroup are bitmasks, each collision type should get 1 bit eg: 1,2,4,8,16 etc. then you ‘or’ together all the types you want to collide with. You may already realize this of course – your demo only uses type 1 and 2 so it’s hard to tell, but I’ll look into making this stuff more intuitive ASAP.

    I can probably wangle something with alpha objects casting shadows but there might be some limitations, eg: self shadowing may or may not be a problem. Will look into this too.



    Yep, after messing about setting individual bits per the Bullet docs, I finally realised it was just 1, 2, 4, 8, etc and they just needed Or’ing together! I’ve got a few types on the go in the Bust source, not sure if latest upload has the pads, etc, from memory.

    It’s not much different to Blitz3D, from what I remember, in that you specify a type (mask) for each object, and a group that decides which types collide. Each group has to include both types in order for a collision to work, eg. the rocket group has to include the terrain type, and the terrain group has to include the rocket type.

    (I got the triangle shatter thing going not too badly in a separate thread under Programming.)

    Will hopefully get to try the new bits tonight, not going to have much time the rest of this weekend.

    Thanks for having a look at shadows… even if alpha shadows disable self-shadowing (?), being able to cast onto other objects should still be an improvement.



    Hacked explosions in on contact with terrain, thanks to recent fix:


    Seems to be a weird shadow error on Emscripten at the moment…

    Explosions look slightly weird as the cone model turns out to be built from ‘shards’, which I hadn’t expected (as much sense as it obviously makes), but basically work nicely here, spraying out in the direction of travel.

    Messy source is on same link as previously.


    Mark Sibly

    Shadow weirdness should be fixed now – well kludged around anyway.

    It actually relates to this problem, which appears to be a bug in angle and/or the d3d compiler:


    I found ‘shaderfrog’ in the process which is kind of fun and should help to narrow down such bugs in future:


    Would love to do something like this for monkey2 too!



    Yep, updated/uploaded and shadows look good now, thanks!

    Regarding doing something like ShaderFrog, do you mean web-based MX2 coding? I did that for MX1*, and it worked really well, but of course that generated JS code directly within a fraction of a second, whereas MX2 would impose a huge load on a server, what with all the C++ building and Emscripten conversion (especially as soon as just a couple of users are running code at the same time). Not sure how well it would work really!

    * Front-end here, back end server no longer present. (The ‘static’ while building is an MX1 app though!)



    OK, this is a pretty flucking cool update if you ask me!

    I’ve added a rocket model from Google Poly (licensed under CC-BY, ie. freely-distributable, ie. Banana-able eventually) and done a load of fixing to account for its multiple materials, which means that when it ploughs into the terrain it looks fer-hucking beautiful on desktop/decent PC!

    However, explosions are unsurprisingly slow as hell on WebGL, so it skips every 3 triangles… and is still slow as hell*:


    I highly recommend downloading and building the source for desktop** in order to get the full explosion experience!

    It’s only when the full 100% triangle explosion occurs that you can really appreciate it… the WebGL version undersells it considerably!

    Massive tidy up next, I think…

    * Have since disabled shadows for explosion triangles on WebGL, makes quite a speed difference here. (Not yet in source zip.)
    ** NB. I use the Github development release.


    Mark Sibly

    Nice, rocket model and explosions look cool!

    I suspect for max speed for the explosion fragments, you’re probably best manually updating a single model’s vertexbuffer instead of using a Model instance for each triangle, but that’d be a major PITA…

    The fragment ‘clouds’ look a bit ‘boxey’ though, I suspect you’re generating velocities via something like Rnd(-1,1) for x,y,z?

    You might want to consider normalizing here, eg:

    Function FragVel:Vec3f( minSpeed:Float,maxSpeed:Float ) ‘untested!
    Return New Vec3f( Rnd(-1,1),Rnd(-1,1),Rnd(-1,1) ).Normalize() * Rnd( minSpeed,maxSpeed )

    The normalize steps makes the length of the random vector ‘1’, effectively giving you random points on a sphere.

    Also, the fragments are doing something weird when they hit the ground, kind of ‘sticking’ or something, perhaps play around with friction or restitution here?



    Literally just finished for the night, but done loads this evening (not that all of it is visible)…

    I suspect for max speed for the explosion fragments, you’re probably best manually updating a single model’s vertexbuffer instead of using a Model instance for each triangle

    Probably a bit out of my league for now! (Edit: besides, I want them to interact physically with the terrain! I’m considering HTML5 to be just for quick demo purposes, with PC as primary target.)

    The rocket trail definitely isn’t doing anything clever yet, so I’ll look at your suggestion there… I’m not seeing the stickiness you are, though! It’s meant to be blocky smoke interacting with the ground, but the spawning/spread definitely needs work…

    Anyway, tonight’s update includes:

    * Fuel limit!
    * Audio! Includes boost, low-fuel alarm and explosion!
    * And, on Windows-64-with-Xbox-pad… analogue gamepad control! (Not in web version, highly recommend trying it on desktop.)

    Bust! Web version (booooo!)


    Windows 64-bit executable (Have an Xbox controller plugged-in for analogue control! Xbox 360 wired and Xbox One wireless tested.)

    Analogue Xbox-pad controls: Left-stick, right trigger. Start resets.

    Source code

    Couple of things I’m struggling with:

    * Collision with terrain isn’t always detected right away — entity.Collided (Class Rocket) appears not always to trigger, yet the rocket can sometimes be seen to collide and bounce off the ground; next time it hits it usually explodes. In theory, should just explode on contact every single time. Not sure what this is, since update rate appears not to be the problem, given it bounces, even if it doesn’t explode…

    * In relation to entity.Collided, I’m trying to figure out how to determine that I’m not colliding with an object (any more)! Specifically, the rocket.landed result that shows in the display text — hitting a landing pad changes landed to True, but I can’t find any way to clear this back to False after taking off from the pad. (If I set it to False every frame, then it’ll be re-detected every frame — I want to trigger a landing sound once, which is what this variable is for. Trickier than it seems… )

    * I wondered if entity.Collided ought to be RigidBody.Collided, feels a bit odd to me, seems like RigidBody should be what collides!

    I really need to get in and tidy/separate out my source now, though…



    Couple of other things I’ve just remembered:

    * I couldn’t figure out how to make it night-time… as in, I set all lights to zero/Color.Black or disabled, AmbientLight to 0, scene ClearColor to 0, but my terrain was still all lit-up like daylight. (Excuse any mis-remembered light/colour refs here.)

    * I added a light to my orb, but had to settle for a Spotlight attached to it, pointing down — looks pretty cool when you’re looking for it (particularly after crashes, where it separates and lights up the terrain like a falling torch), but I actually intended a PointLight, which I think is the only one left unimplemented. Think this would look cool as it swings by terrain. (Messing with this is what lead to the attempted night-time scene.)

    Think I had more, but gone blank for now.

    (I can’t stress enough that the Win64-with-Xbox pad version is way cooler than the web version!)

Viewing 15 posts - 31 through 45 (of 57 total)

You must be logged in to reply to this topic.