Jump to content

Ray tracing/casting for bullet penetrance in 2D?


tetris11
 Share

Recommended Posts

My character fires a bullet and how far it goes depends on what it hits or passes through.

 

Box2D and other physics engines have useful callbacks for collision detection for moving objects, but this bullet would be rendered instantaneously so I figured raytracing would be the solution.

 

How would I go about doing this?

Link to comment
Share on other sites

In essence you distill the direction (and possibly magnitude, but its easier to assume the bullet travels forever) into a vector and check for an intersection between that vector and all objects in the scene. Checking collisions between a plane and a box isnt too difficult but you need to know your maths.

Using a library is easier, I'd be surprised if Box2D could not do this, but I can also vouch for P2, it is superb (I wouldnt call it lightweight though, but, it is tight in scope which gives it the edge over other libraries like MatterJS for me i.e. it focusses purely on physics, the rendering is up to you).

Link to comment
Share on other sites

3 minutes ago, mattstyles said:

In essence you distill the direction (and possibly magnitude, but its easier to assume the bullet travels forever) into a vector and check for an intersection between that vector and all objects in the scene. Checking collisions between a plane and a box isnt too difficult but you need to know your maths.

And by "plane" you mean "ray" right? I suspect the OP gets what a "ray" is without the explanation :P

Link to comment
Share on other sites

@tetris11 not sure, I suspect both are fairly heavy calculation-wise (necessarily). I'm not really up with how optimised Box2D is for JS but I do know that P2 is well-maintained and sees active development including additional features, bug-fixing and optimisations.

I've used P2 on smallish scenes and even IE9 can keep up with a solid framerate, I dont know if Box would see the same result.

Link to comment
Share on other sites

Just to let you guys know that I've ported the P2 Raycast demo in my first post to PIXI, with the option of rendering to either Canvas or WebGL 2D as you like.

http://tetris11.bitbucket.org/p2_raycast_demo/

 

PC (firefox) has shown absolutely no difference in framerates.

Mobile (firefox(ish)) has shown ~ 55fps for WebGL, and ~45fps for Canvas.

 

Link to comment
Share on other sites

I also see 65 fps on my aging laptop... so I think theirs a bug in the FPS averaging code you are using to display the frame rate (just to clarify these numbers are higher than RAF fires for my setup, and I checked and see that you are using RAF)

I am surprised that you are see FPS that low for mobile devices though with so few tests!

Link to comment
Share on other sites

Your monitor can not physically render faster than its refresh rate.

Actually I've just done some googling to see if that statement is completely correct as I suspected it isnt, well, its not! It gets a little more complicated than that when you take into account blurring frames and such other graphics magic. LCD monitors generally cap out at 60hz so if you run your app at 120FPS (if you can) then I think you need to blend between those intermittent frames as they will not be rendered even though your GPU may be able to render them to a buffer. I know that gamers will frequently state they can tell the difference between 120fps and 60fps, even on an LCD, so maybe there is some blending magic going on (the browser has, technically, the same access to the GPU as any other application so you could make it happen).

Ordinarily though, there is no need to render more than 60 fps because your average screen wont display it. However, tech changes all the time. requestAnimationFrame should give you the differing frame rates and should be dependent on the screen.

Link to comment
Share on other sites

I always thought the renderer dished out to a framebuffer at a rate equal to (or slightly greater than) the refresh rate, and your monitor grabbed the latest frame from the framebuffer independently (though still at the refresh rate) - leading to tearing if the frame wasn't complete yet.

I know Nvidia introduced some fancy feature in their new monitors to only grab a frame from the fbuffer if it recieved a go-ahead signal, but standard monitor's don't have this feature...

I guess what I'm saying is: it wouldn't be strange to over render, inefficient maybe - but not unheard of

Link to comment
Share on other sites

4 minutes ago, tetris11 said:

I always thought the renderer dished out to a framebuffer at a rate equal to (or slightly greater than) the refresh rate, and your monitor grabbed the latest frame from the framebuffer independently (though still at the refresh rate) - leading to tearing if the frame wasn't complete yet.

I know Nvidia introduced some fancy feature in their new monitors to only grab a frame from the fbuffer if it recieved a go-ahead signal, but standard monitor's don't have this feature...

I guess what I'm saying is: it wouldn't be strange to over render, inefficient maybe - but not unheard of

The Nvidia feature you are describing is "Adaptive VSync", what we've otherwise been discussing involves regular "VSync", and neither work quite the way you've described - so in that way something that worked the way you've detailed would be strange to me. While RAF does give the browser judgement to do what it thinks is best with regards to framerate, theirs no denying that such behaviours are both well described for particular browsers/browser versions (ie. who's to say what a version of Chrome will do 6 years from now), and it is somewhat consistent between webpages (at least in the case described where the cost of a frame is less than the frame rate). Anyway it's a bit off-topic and you can see confirm the frame rate in other ways such as using the browser's developer tools.

Oh, and any word on those mobile figures, I still stand by my gut reaction that they seem a bit low... I've actually had no experience with P2 but I don't think ray tests involve enough computation to explain the frame rate to my satisfaction...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...