Hi,
I have asked a question earlier regarding imprecise picking results from bullet. I have encountered with the same issue again, and I am way too confused last few days.
I have rebuilt bullet-2.78 from the scratch, without optimizations and in Debug configuration (on Mac and Linux). I have then started Demos/BasicDemo/AppBasicDemo then resized the window to 320x480 and tried to pick objects.
When I tried clicking on objects away from center, bullet couldn't hit anything (throwing boxes also seems like wrong). Objects at/around center are more or less hit correctly.
I have seen this post, but it didn't help.
I would be really happy if you have any suggestion or solution to this problem.
ClosestRayCallback doesn't work when width < height
-
- Posts: 5
- Joined: Wed Dec 01, 2010 10:13 pm
-
- Posts: 237
- Joined: Tue Jun 29, 2010 10:27 pm
Re: ClosestRayCallback doesn't work when width < height
This sounds like an issue with your interface/graphics system, not Bullet. Whenever the viewport dimensions are changed, you're typically going to need to update the graphics appropriately. Your bullet objects are exactly where they should be, but your picking (raycast from mouse) is probably not where it appears to be (ie it looks to you like you're clicking on an object, but the screen point translated into simulation space is actually somewhere else). Also watch out for things like inverted y coordinates for your screen. I made an application once where my clicks would be translated into points mirrored on the opposite vertical side of the viewport, so I had just had to flip the screen y coord before translating to world coords.
-
- Posts: 5
- Joined: Wed Dec 01, 2010 10:13 pm
Re: ClosestRayCallback doesn't work when width < height
Thanks for quick reply. I do not agree with your assumption. For the record, my engine is using bullet's world coordinates for displaying the objects.
Assuming I have some graphical representation problems, what about the bullet demo itself? As I mentioned, the Demos/BasicDemo/AppBasicDemo exhibits exactly the same symptoms. Please run this example, shrink the window (yes, you will see the viewport is also weirdly resized, because they, for some reason, try to invert the aspect ratio - "fixing" (!) that won't change the outcome, for the record). Debug drawer seems like to draw objects at correct places. Either ray casting or ray result callback is failing at some point, IMO, but I have no idea.
If you can test this with the bullet demo itself, you may understand what I mean exactly.
Assuming I have some graphical representation problems, what about the bullet demo itself? As I mentioned, the Demos/BasicDemo/AppBasicDemo exhibits exactly the same symptoms. Please run this example, shrink the window (yes, you will see the viewport is also weirdly resized, because they, for some reason, try to invert the aspect ratio - "fixing" (!) that won't change the outcome, for the record). Debug drawer seems like to draw objects at correct places. Either ray casting or ray result callback is failing at some point, IMO, but I have no idea.
If you can test this with the bullet demo itself, you may understand what I mean exactly.
-
- Posts: 237
- Joined: Tue Jun 29, 2010 10:27 pm
Re: ClosestRayCallback doesn't work when width < height
What I mean is that Bullet doesn't care if you change the window/viewport size. Nothing about that operation changes the state of the physics objects or where they are in the simulation. Thus, it's a matter of getting the proper screen coord's and translating them properly into world space, which the raycast then uses. If the picking doesn't work quite right in the demos, then it seems they are not handling resizing properly either (the demos aren't always perfect
), but again this is a UI/graphics issue. Picking/resizing works fine in my simulation (which uses a different windowing and graphics system from the demos).
I just tried the demo and can confirm the issue you mentioned. So yeah, they just aren't updating the viewport properly. You might wanna file a big report: http://bulletphysics.org/Bullet/phpBB3/ ... p?f=9&t=17

I just tried the demo and can confirm the issue you mentioned. So yeah, they just aren't updating the viewport properly. You might wanna file a big report: http://bulletphysics.org/Bullet/phpBB3/ ... p?f=9&t=17
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: ClosestRayCallback doesn't work when width < height
It was a bug in the DemoApplication code, copy attached file into Bullet/Demos/OpenGL or update to latest trunk for a fix.
Can you try it?
Thanks,
Erwin
Can you try it?
Thanks,
Erwin
You do not have the required permissions to view the files attached to this post.
-
- Posts: 5
- Joined: Wed Dec 01, 2010 10:13 pm
Re: ClosestRayCallback doesn't work when width < height
Thank you, Erwin. Your patch works for the demo, and almost the same as what I did. But my problem still continues.
Example is using a fixed FOV while in my case, FOV may (and does) change. I think that's the weak link in my case, but I am not exactly sure about it either. My implementation is still broken (that is, imprecise). I will work a little more on that today, if I can have time.
Example is using a fixed FOV while in my case, FOV may (and does) change. I think that's the weak link in my case, but I am not exactly sure about it either. My implementation is still broken (that is, imprecise). I will work a little more on that today, if I can have time.
-
- Posts: 237
- Joined: Tue Jun 29, 2010 10:27 pm
Re: ClosestRayCallback doesn't work when width < height
A little while ago I was doing some manual camera adjustment in my simulation based on window resizing, and in my calculations I had to check if the width was < than the height. If it was, I had to modify the calculation. Your problem might well be different, but it sounds somewhat related. So in case it helps at all, below is my code.
I use the Ogre graphics engine. 'e' is the Ogre::Entity instance that holds my mesh. Essentially, this code moves the camera to the appropriate distance (along the z direction) from the mesh such that it fits the whole mesh in the view. I call this code whenever the mesh is replaced with a new one, or when the window is resized.
Note that if the viewport width is less than the height (vpX<vpY), I need to multiply the FOV (in the y direction, in this case) by the aspect ratio.
I use the Ogre graphics engine. 'e' is the Ogre::Entity instance that holds my mesh. Essentially, this code moves the camera to the appropriate distance (along the z direction) from the mesh such that it fits the whole mesh in the view. I call this code whenever the mesh is replaced with a new one, or when the window is resized.
Code: Select all
Ogre::AxisAlignedBox bbox = e->getWorldBoundingBox();
Ogre::Vector3 center = bbox.getCenter();
Ogre::Vector3 offset = bbox.getMaximum() - center; // radius vector
camPosDefault = Ogre::Vector3(0, center.y, 0);
Ogre::Viewport * vp = mRoot->getRenderTarget("ogre window")->getViewport(0);
int vpX = vp->getActualWidth();
int vpY = vp->getActualHeight();
if (vpX >= vpY)
{
camPosOffset = Ogre::Vector3(0, 0, offset.length() / tan(cam->getFOVy().valueRadians() / 2.0f));
}
else
{
camPosOffset = Ogre::Vector3(0, 0, offset.length() / tan((cam->getFOVy() * cam->getAspectRatio()).valueRadians() / 2.0f));
}
cam->setPosition(camPosDefault + camPosOffset);
cam->lookAt(camPosDefault);
-
- Posts: 5
- Joined: Wed Dec 01, 2010 10:13 pm
Re: ClosestRayCallback doesn't work when width < height
Thank you, dphil. It seems like you have a point! I still believe my graphical representation is correct, because I compared those with fixed pipeline implementations and they are matching (except may be at some minor fractions, as I used floats and have my own implementation). I have no in depth, but brief knowledge about workings of ray casting and unprojecting the window coordinates. I prefer using existing libraries/implementations instead, as it cuts down significant development time. Besides, it is difficult for me to learn every single bit about the details.
What I have realized, as I pointed out before, was my fov value. Demo apps have a constant fov. This could be leading the confusion. In my case, my fov value is initially 45 degrees. I will keep you posted.
What I have realized, as I pointed out before, was my fov value. Demo apps have a constant fov. This could be leading the confusion. In my case, my fov value is initially 45 degrees. I will keep you posted.