tetris11 Posted January 11, 2016 Share Posted January 11, 2016 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? Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 12, 2016 Author Share Posted January 12, 2016 The answer is: use P2 Lightweight and has everything - http://schteppe.github.io/p2.js/examples/canvas/raycasting.html schteppe 1 Quote Link to comment Share on other sites More sharing options...
mattstyles Posted January 13, 2016 Share Posted January 13, 2016 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). Quote Link to comment Share on other sites More sharing options...
chg Posted January 13, 2016 Share Posted January 13, 2016 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 Quote Link to comment Share on other sites More sharing options...
mattstyles Posted January 13, 2016 Share Posted January 13, 2016 Yeah, my bad, oops. It's early(ish) and I may or may not be hungover. I only just noticed the OP answered their own question. Quote Link to comment Share on other sites More sharing options...
chg Posted January 13, 2016 Share Posted January 13, 2016 3 minutes ago, mattstyles said: Yeah, my bad, oops. It's early(ish) and I may or may not be hungover. I only just noticed the OP answered their own question. Well I hope you're not, being hungover sucks! tetris11 1 Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 13, 2016 Author Share Posted January 13, 2016 Let us all drink to a happy January! @mattstyles - is p2 more resource-hogging than Box2D? Quote Link to comment Share on other sites More sharing options...
mattstyles Posted January 13, 2016 Share Posted January 13, 2016 @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. tetris11 1 Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 13, 2016 Author Share Posted January 13, 2016 Okay - good to know. I like Box2D, but it feels too fully-developed to feel lightweight. Maybe it is, who knows Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 18, 2016 Author Share Posted January 18, 2016 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. Quote Link to comment Share on other sites More sharing options...
mattstyles Posted January 19, 2016 Share Posted January 19, 2016 If you're after some numbers, for me, Chrome on a newish Macbook Air knocks along at a solid ~65. Safari and Firefox ditto. tetris11 1 Quote Link to comment Share on other sites More sharing options...
chg Posted January 19, 2016 Share Posted January 19, 2016 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! tetris11 1 Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 19, 2016 Author Share Posted January 19, 2016 @chg hmm I think you're right. How do you know what the RAF for your laptop is meant to be? Quote Link to comment Share on other sites More sharing options...
mattstyles Posted January 19, 2016 Share Posted January 19, 2016 Its usually 60, its the refresh rate of your monitor. Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 19, 2016 Author Share Posted January 19, 2016 Oh right yeah. Do draw frames and refresh rate always sync? I thought there was reasonable amount of over rendering Quote Link to comment Share on other sites More sharing options...
mattstyles Posted January 19, 2016 Share Posted January 19, 2016 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. tetris11 1 Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 20, 2016 Author Share Posted January 20, 2016 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 Quote Link to comment Share on other sites More sharing options...
chg Posted January 20, 2016 Share Posted January 20, 2016 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... tetris11 1 Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 20, 2016 Author Share Posted January 20, 2016 Ah fair, interesting topic anyhow I'll read up more on it later I guess. As for the mobile figures - still seeing a noticeable lag in the Canvas renderer than compared to WebGL 2D, though the numbers now are 45-50 and 65-70 Quote Link to comment Share on other sites More sharing options...
tetris11 Posted January 21, 2016 Author Share Posted January 21, 2016 Just an interesting short read on Vsync, backbuffer and framebuffer, and triple-buffering. http://hardforum.com/showthread.php?t=928593 Well explained, and is indeed a little different than what I thought Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.