mojo3d: Entity in view?

About Monkey 2 Forums Monkey 2 Programming Help mojo3d: Entity in view?

This topic contains 26 replies, has 4 voices, and was last updated by  DruggedBunny 1 year, 1 month ago.

Viewing 15 posts - 1 through 15 (of 27 total)
  • Author
    Posts
  • #14054

    DruggedBunny
    Participant

    Is there a way to check if an entity is within a camera’s current view?

    I’ve been using Camera.ProjectToViewport, but it gives weird results when entities are behind the camera…

    https://www.youtube.com/watch?v=MTR4qYf5db4 (YouTube compression has f***ed this up completely, but you get the gist!)

    I tried writing my own ‘IsInViewport’ but failed miserably, though I’m not sure if I’m even using ProjectToViewport correctly…

    Notice that turning the camera all the way around (use left or right arrows) results in the * appearing again when the cube is behind the camera!

    [/crayon]
    #14055

    Ethernaut
    Participant

    Haven’t tried it, but there’s this:

    Simple mojo3d view culler

    #14056

    DruggedBunny
    Participant

    Still got some weirdness at screen edges with that*, but it’ll certainly do me for now… working much better, thanks!

    * I’ll wait until more official and see how it works then.

    #14067

    Mark Sibly
    Keymaster

    Still got some weirdness at screen edges with that

    The ‘official’ version is likely to be about the same!

    Can you post a little demo-ette of the weirdness?

    #14069

    DruggedBunny
    Participant

    Yeah, will do tonight.

    #14072

    DruggedBunny
    Participant

    OK, I’d deleted the code… now, on recreating it… it works perfectly, of course.

    I’ve attached the code just for reference.

    Few things I ran into/wished for while doing it:

    1) More physics — would like to play with constraints in particular.
    2) This code was just me trying to wrap all of the Collider types in a way I can fathom, but I found that Convex/Concave are unimplemented and MeshCollider is well dodgy (you referenced this being a Bullet problem in one of your mojo-vr tests). Any plans for these aspects? I got a cool-looking terrain but couldn’t drop my boxes onto it!
    3) While trying to get MeshCollider working, I was struggling with obtaining the world-space size of the mesh inside a scaled-down entity, could use a way to get that if possible; also a way to visualise these things would be nice. Also, Model.Width/Height would be nice, was a struggle locating those, think I had to dig into mesh bounds boxfs or something!
    4) Any chance of a pure flat-shading-mode-pretty-please?

    There were more but gotta go back to work and can’t remember off-hand!

    Attachments:
    1. toybox.7z
    #14085

    Mark Sibly
    Keymaster

    OK, I’d deleted the code… now, on recreating it… it works perfectly, of course.

    If you can get it to happen again, give me a shout.

    More physics — would like to play with constraints in particular.

    What constraint should I start with?

    MeshCollider is well dodgy

    God yes, I’ve spent considerable time on this and haven’t come up with any really solutions yet. If you can post some simpe examples of the problems you’re having that would help. It’s likely MeshCollider used with ‘real physics’ is always gonna be tricky and require considerable coder ‘assistance’ to get working, in the case of bullet anyway.

    Fake ‘FPS physics’ still appears to be doable so it’s not a complete washout. But I was looking forward to doing some ‘real physics’ intertia-er thingy things with it so it sucks that it looks like that wont be easy.

    Switching to another API would be a possiblity except that there are no real alternatives. Phys-X is the only one with similar features (and even that’s missing some of the FPS features I’d like) but that’s not open source so no go there.

     world-space size of the mesh inside a scaled-down entity

    Scale does not currently affect physics! I may be able to make this work eventually, but it’s way down the list…

    To get ‘world bounds’ of a model, transform the mesh bounds (ie: the local bounds) by the model matrix. There should really be a AffineMat4 * Box operator in there for this but there isn’t yet (will add now) but you can use the TransformBox code above for now.

    #14087

    DruggedBunny
    Participant

    Hi Mark,

    Doubt I’ll see it again — the code looks like what I thought I had before, but is clearly working! That did remind me of another point, though:

    5) I felt like ProjectToViewport should be returning 2D-style co-ordinates, but I’m having to invert the y result like below to correctly draw in 2D — and I imagine this would be the main use for projecting 3D-to-2D:

    [/crayon]

    For constraints, I’ve mostly been after fixed and ball-socket/point-to-point, going by:

    http://bulletphysics.org/mediawiki-1.5.8/index.php/Constraints

    The first would allow simple rocket bodies with boosters attached, and the second would allow for thrust-style orbs!

    /aside: I actually was looking at a javascript demo of the double-pendulum effect yesterday, and thinking it could be used to make great random dogfighting movements:

    https://nullprogram.com/double-pendulum/

    (Imagine the outer ball being an enemy circling the player ‘aircraft’ at the centre! You’d probably have to position the pendulums ‘off-world’ and just use the position results to manually position a model around the player, rather than attach the pendulum to the player, but would probably look really cool if it worked!)

    So, ball socket ought to at least allow a few interesting options…

    One thing I’m not sure about, but seem to recall reading Bullet could do, is having constraints break apart depending on force (for more realistic bullet-hitting-wall simulations), but maybe a bit early for that.

    Bullet does have built-in vehicle and ragdoll simulations, no doubt a bugger to set up, but those would be awesome to have at some point.

    Wonder why Bullet is apparently so poor with the mesh stuff? Perhaps you have to supply it with ‘nicer’ meshes or something… could a QuickHull-type of thing help, or even something like whatever Maplet did to generate simplified ‘clean’ hull meshes?

    Failing that, might be worth experimenting with manually-simplified collision meshes (ie. not the complex ‘real’ mesh), just to see if that works… can always specify that it’s up to the coder to produce these if it’s not automate-able (?!).

    I’d swear I’ve seen Bullet doing terrain demos, but could be wrong!

    I have troubling visualising scaled/translated meshes versus the visible version, but I thought what I’ve done in the attached would have worked (not sure if you class this as ‘scaled’, or if you just mean scaling the entity) — this to me reads like it’s ‘unscaled’ in the sense that the core mesh has just been amended, prior to physics being attached — note that colliders and rigidbodies are only set up in xBody.Start (), allowing for repositioning, rotating, etc prior to starting physics.

    In short:

    [/crayon]

    It almost does work (seems to collide at the right point in terms of model size), other than the end result doesn’t actually rotate in any way! Notice the carbody.Rotate (45, 45, 45), but the end result is it lands as if attached to an un-rotated cube. Wonder if this is related to the overall problem, ie. there’s simply some rotation not being applied or taken into account?

    Attachments:
    1. toybox-1.7z
    #14102

    Mark Sibly
    Keymaster

    I’m having to invert the y result like below to correctly draw in 2D

    This issue has been fixed recently in develop branch.

    Wonder why Bullet is apparently so poor with the mesh stuff?

    I suspect this is actually a common problem with ‘real’ physics engines. As far as I can tell, they don’t generally work by working out a ‘collision time’ and finding an intersection point based on velocity ala blitz3d and many ‘game physics’ engines.

    Instead, they seem to use an instaneous ‘am I colliding’ sort of system that generally doesn’t take into account direction of movement or anything, so they have to sort of ‘guess’ which way to move things when they are intersecting, usually based on nearest point to penetrating point etc.

    To account for this and make collisions more accurate you need to perform more ‘substeps’ when updating the world which, now that I think about it, is something I haven’t even looked into yet!!!!!

    I’d swear I’ve seen Bullet doing terrain demos, but could be wrong!

    If you cmake the bullet repos, there are 2 demos that involve a mesh, both of which are terrain-ish and actually work pretty well. But the size of the mesh polys is quite a bit smaller than is pratical, smaller than the shapes colliding with them. I am planning to have a closer look at these demos later as it’s at least a working starting point…

    Your scaling code looks right, the important thing is to *not* use Entity.Scale as physics currently ignores this. Will take a close look at your demo a bit later…

    #14103

    Mark Sibly
    Keymaster

    I’m having to invert the y result like below to correctly draw in 2D

    This issue has been fixed recently in develop branch.

    Wonder why Bullet is apparently so poor with the mesh stuff?

    I suspect this is actually a common problem with ‘real’ physics engines. As far as I can tell, they don’t generally work by working out a ‘collision time’ and finding an intersection point based on velocity ala blitz3d and many ‘game physics’ engines.

    Instead, they seem to use an instaneous ‘am I colliding’ sort of system that generally doesn’t take into account direction of movement or anything, so they have to sort of ‘guess’ which way to move things when they are intersecting, usually based on nearest point to penetrating point etc.

    To account for this and make collisions more accurate you need to perform more ‘substeps’ when updating the world which, now that I think about it, is something I haven’t even looked into yet!!!!!

    I’d swear I’ve seen Bullet doing terrain demos, but could be wrong!

    If you cmake the bullet repos, there are 2 demos that involve a mesh, both of which are terrain-ish and actually work pretty well. But the size of the mesh polys is quite a bit smaller than is pratical, smaller than the shapes colliding with them. I am planning to have a closer look at these demos later as it’s at least a working starting point…

    Your scaling code looks right, the important thing is to *not* use Entity.Scale as physics currently ignores this. Will take a close look at your demo a bit later…

    #14104

    DruggedBunny
    Participant

    That’s so weird! I remember maybe 20 years ago [18 years? Almost certainly as a result of Blitz3d collision comments] reading online about turning spheres into capsules to predict their position at a future point in time! I have assumed this would be just the norm since then! Wow.

    Did notice the y-update this morning, thanks!

    #14105

    DruggedBunny
    Participant

    Oh, yeah, have a look specifically at the rotation comment, just doesn’t seem to be taken into account — whether by mojo3d or Bullet I can’t tell…

    #14125

    DruggedBunny
    Participant

    In my last demo (showing as toybox-1.7z), if you change the car loading code to this, you can see that the complexity of the mesh is sort of irrelevant by replacing it with a cube:

    [/crayon]

    For some reason, it just doesn’t get any rotation applied during collisions…

    #14446

    Cole Chapman
    Participant

    DruggedBunny were you ever able to get ball socket/point2point constraints working?

    #14447

    DruggedBunny
    Participant

    No, they’re not in yet, just got to wait until Mark fancies playing with that stuff, hopefully soon!

Viewing 15 posts - 1 through 15 (of 27 total)

You must be logged in to reply to this topic.