Author Topic: about the speed of getPixels, GPU collision detection  (Read 2074 times)

Offline MichaelJPCT

  • float
  • ****
  • Posts: 266
    • View Profile
about the speed of getPixels, GPU collision detection
« on: September 06, 2020, 10:30:44 am »
hi Egon,
the java doc says getPixels costs a lot of time (for realtime rendering).
is the time related to the size of framebuffer?
if the framebuffer is of size 1x1, does it still cost that much time or is the time much shorter?
i think of using getpixels to do collision detection, is it possible?
the method is like this, place a camera at a bullet, set farclip to the distance that bullet travels in delta time, read the resulting depthbuffer to know whether/where/when the bullet hits something.
if this is possible, is it better or worse comparing to the ray-polygon collision detection in jpct engine?

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12297
    • View Profile
    • http://www.jpct.net
Re: about the speed of getPixels, GPU collision detection
« Reply #1 on: September 07, 2020, 02:45:33 pm »
It depends on the size, yes. A 1x1 buffer should be reasonable fast. There's still some cost to it, because it causes a GL pipeline flush, which is expensive. I'm not really sure if I understood your approach, but I think that the geometrical approach will work much better anyway. If it is a performance problem, then using simplified collider objects instead of real geometry might be an idea.

Offline MichaelJPCT

  • float
  • ****
  • Posts: 266
    • View Profile
Re: about the speed of getPixels, GPU collision detection
« Reply #2 on: September 08, 2020, 09:02:03 am »
thank you Egon.
i am just exploring possibilities, i have little experience in collision detection.
overall i think using simplified mesh with JPCT's collision detection methods is the best solution.