Picking; linking x y screen coordinates to scene components

What it says on the tin: a place to discuss proposed new features.
idhan
Halfling
Posts: 83
Joined: Mon Dec 10, 2007 2:51 pm

Re: Picking; linking x y screen coordinates to scene components

Post by idhan » Mon Mar 23, 2009 5:11 pm

Hi,

I have a project with free-forms objects, initially was based in plane opengl with the z-buffer picking system provide by the library it self.
The terrain and objects of the scene are all free-form based objects, so thousands of triangles are used to give the final form to each
object and a LOD was use to improve the render-performance.

In order to archieve easily some more realistic scenes including lights and shadows I decided to move to Ogre obtaining some really nice 3d-views.
Unfortunately, the picking methods of ogre were really imprecise if the objects where really close to each other, only moving the camera
angles I could finally pick some objects.

The alternative proposed at that in this forum was a traingles-intersection algorithm that is anywhere in the ogre-wiki. However the performce of
that algorithms only was good for very simply free-form objects.

A didn't have any performance problem using only plain-opengl, because in the Z-buffer picking system disable all the lights, shadows, textures, etc.
at the very moment of render for picking, given me the posibility of interact with the system in real time. This z-buffer is also offer by D3D and other
high-level 3D libraries such as Irrlicht (Irrlicht also provide the AABB picking system which ogre offers)

Finally now I start to read more about irrlicht features and has become a very interesting alternative to ogre, so far with all features ogre offers except
LOD (but it will be included in future releases)

From my point of view, the physics libraries are needed for collision detection in 3D, but simply mouse picking methods should be offers by Ogre it selft.
This lack of feature also reduce the posibilites of picking with interesting 2D objects that are not rectangular.

Best greetings.
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: Picking; linking x y screen coordinates to scene components

Post by jacmoe » Mon Mar 23, 2009 6:16 pm

If you're happy with IrrLicht, then go for it. :wink:
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

idhan
Halfling
Posts: 83
Joined: Mon Dec 10, 2007 2:51 pm

Re: Picking; linking x y screen coordinates to scene components

Post by idhan » Mon Mar 23, 2009 7:51 pm

If you're happy with IrrLicht, then go for it. :wink:
Well, as I say I am only reading alternatives for my problem (an so far this thread shows, it is the problem for other people too),
however, so far I'm still waiting to see the future development of ogre in this matter (basically because I'm still dealing with many
other problems that has nothing to do with ogre). Of course, if the time come, I will be FORCE to "go for it", but as I said (wrote)
some time ago, I think ogre has a great future, I want also donate, but wasn't possible trough money-bookers.

I just thing that is a feature to be consider.. I hope one day (hopefully soon) is part of the Ogre-API.

Again, best greetings.
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Re: Picking; linking x y screen coordinates to scene components

Post by xavier » Mon Mar 23, 2009 8:06 pm

idhan wrote: From my point of view, the physics libraries are needed for collision detection in 3D, but simply mouse picking methods should be offers by Ogre it selft.
This lack of feature also reduce the posibilites of picking with interesting 2D objects that are not rectangular.
What lack of feature? Ogre itself has the support you need to pick objects at the AABB level, and there is perfectly working code in the Wiki for raycasting further to the polygon level for more precise picking. Maybe I'm missing your point -- are you asking to have it spoon-fed in a single function call? What about all of those people who have different picking needs? Does Ogre need to support each and every one of their slightly different desires as well?

Everything you need is there already. IMO this issue is "closed and solved".
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

idhan
Halfling
Posts: 83
Joined: Mon Dec 10, 2007 2:51 pm

Re: Picking; linking x y screen coordinates to scene components

Post by idhan » Mon Mar 23, 2009 8:28 pm

Yes, you are missing the point, because ogre and irrlicht support the AABB picking feature, but irrlicht support in addition,
the feature has been requested in this thread.

If ogre support each and every one of their slightly different desires of all ogre-users, why this thread even exist?
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: Picking; linking x y screen coordinates to scene components

Post by jacmoe » Mon Mar 23, 2009 10:09 pm

idhan wrote:Yes, you are missing the point, because ogre and irrlicht support the AABB picking feature, but irrlicht support in addition,
the feature has been requested in this thread.
Ogre does not support AABB for picking. It uses it for culling.
As it's a rendering engine, all it needs is approximate functions.
If you need accurate, go code accurate. Ogre doesn't need it. Ogre tries to be a speedy, flexible 3D Renderer, not a Swiss Army Knife. :wink:

It's easy enough to do accurate picking - use MOC, for instance.
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

idhan
Halfling
Posts: 83
Joined: Mon Dec 10, 2007 2:51 pm

Re: Picking; linking x y screen coordinates to scene components

Post by idhan » Mon Mar 23, 2009 10:43 pm

Jacmoe:

The "AABB picking" is was just an expression, the ogre ray-query basically use the AABB for intersection.
If you need accurate, go code accurate
I appreciate your way of tell me what to do :wink:
all it needs is approximate functions
well, not all people works just with approximations, isn't?
Ogre tries to be a speedy, flexible 3D Renderer, not a Swiss Army Knife. :wink:
do you really think that provide basic feature such as precise mouse picking convert ogre in a "Swiss Army Knife"?
It's easy enough to do accurate picking - use MOC, for instance.
at the time I ask for this feature, MOC wasn't available. I have seen videos from MOC for very simply polygonal scenarios, such of games, not for fully b-splines scenarios.

And speaking about MOC, on this thread; http://www.ogre3d.org/forums/viewtopic.php?t=45267, is very interesting to take in account how many ogre-users were really grateful for this feature, isn't?
perhaps many people need a "Swiss Army Knife" :D

Any way, if you are a developer of ogre and you wanted to say "we will not even consider this feature" I got it :wink:
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Re: Picking; linking x y screen coordinates to scene components

Post by xavier » Mon Mar 23, 2009 11:05 pm

idhan wrote:
all it needs is approximate functions
well, not all people works just with approximations, isn't?
Ogre tries to be a speedy, flexible 3D Renderer, not a Swiss Army Knife. :wink:
do you really think that provide basic feature such as precise mouse picking convert ogre in a "Swiss Army Knife"?
You're proving our point, but obviously not listening to yourself speak. You point out, rather correctly, that "not all people works [sic] with just approximations", yet Ogre would have two choices: (1) implement something, that is almost guaranteed not to fit everyone's needs, or (2) implement everyone's exact needs, even if they are slightly different "on the surface". So it (correctly, IMO) does neither: it gives you the low-level API needed for you to code your own damn mouse picking algorithm. To wit:

1) use getCameraToViewportRay() and feed that to a RaySceneQuery
2a) use the results of that query as is (AABB results), or
2b) feed each of those returned objects to the raycasting-to-the-polygon-level code available in the Wiki (code, I might add, that is drop-in ready)


Can you tell we get tired of hearing people whine and complain that Ogre doesn't basically just write their whole application for them?

BTW, Jacmoe and I are not "developers of Ogre" -- you should pay more attention to the legend under the poster names. It doesn't say "Ogre Team Member" there, does it?
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

idhan
Halfling
Posts: 83
Joined: Mon Dec 10, 2007 2:51 pm

Re: Picking; linking x y screen coordinates to scene components

Post by idhan » Mon Mar 23, 2009 11:55 pm

Xavier,
you should pay more attention to the legend under the poster names
I'm sorry about the "ogre developer", my mistake.

I already discuss this point with you, you even thought I was asking for GLUT feature, later was particular opengl feature and not in D3D (although it is include it in D3D).
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=38368
Can you tell we get tired of hearing people whine and complain that Ogre doesn't basically just write their whole application for them?
,
this basic feature doesn't write my whole application, does it for you?

As i say the ogre "raycasting-to-the-polygon-level" is to slow for complex objects, can be accelerate using the GPU but I suppose is not relevant for you.
I ask my self why this feature has been implemented in opengl, D3D and offers by Irrlicht-API using opengl or D3D? perhaps to write their entire users applications?
may be to not ask for features in their forums? perhaps to create easily interactive 3D applications with high level of quality and real time response
even for complex scenarios? mmmm probably not, for sure Opengl, D3D and Irrlicht-API were waisting their time, it could be enough with a
"raycasting-to-the-polygon-level", probably accelerate this process using the GPU is irrelevant.


I am sorry for the irony but is a little contagious :mrgreen:
0 x

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Re: Picking; linking x y screen coordinates to scene components

Post by xavier » Tue Mar 24, 2009 12:27 am

idhan wrote: I ask my self why this feature has been implemented in opengl, D3D and offers by Irrlicht-API using opengl or D3D?
You'll have to show me where in Direct3D this is implemented. It's not.

It's also not in OpenGL either.

Both of these APIs provide you example code for building a ray (which works, not surprisingly, an awful lot like Ogre's algorithm for building a camera-to-viewport ray), which you can then use to your satisfaction. Irrlicht builds on top of this the same way Ogre does. Whether or not they provide additional functionality for application-specific code such as selecting objects in a scene, is a design decision made by them. The Ogre design elects not to infect the library with application-specific code such as this, and instead provides you a facility on top of which you can build your own application.

I don't know what part of this is so hard for you to understand.
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

idhan
Halfling
Posts: 83
Joined: Mon Dec 10, 2007 2:51 pm

Re: Picking; linking x y screen coordinates to scene components

Post by idhan » Tue Mar 24, 2009 12:58 am

Xavier,

Isn't implemented? as example, ask you self, how can you do a mouse-picking with opengl if you the concept of object doesn't really exist?
how these APIs can execute a ray-AABB intersection algorithm if isn't really any object to create an AABB in first place?

I am not going to continue this conversation, it is a waist of time, from the moment that you highlight GLUT already show how much
you know about opengl or D3D features. Event D3D make use of the z-buffering for picking if is needed.
I don't know what part of this is so hard for you to understand.
I got it.
Last edited by idhan on Tue Mar 24, 2009 9:32 pm, edited 1 time in total.
0 x

User avatar
madmarx
OGRE Expert User
OGRE Expert User
Posts: 1668
Joined: Mon Jan 21, 2008 10:26 pm

Re: Picking; linking x y screen coordinates to scene components

Post by madmarx » Tue Mar 24, 2009 9:25 pm

Xavier,

Did you really think that idhan was taking time to explain just to get his application done, or because he was stupid? :wink:

Opengl picking is a feature since at least opengl 1.2.(try google if you don't believe me).
This is the best way sometimes to pick complex object (ever tried to do picking on 3D textures with realtime speed ??).

Of course you can say "sorry not interesting feature", but please try not to say fake things when you don't know.

I would like to say bravo at idhan who also took the time to explain twice its opinion.

Pierre, opengl teacher.

PS : no flameware intended but sometimes people must realize when they are giving fake informations on the forums. That helps to improve, beyond the infini :lol: !
0 x
Tutorials + Ogre searchable API + more for Ogre1.7 : http://sourceforge.net/projects/so3dtools/
Corresponding thread : http://www.ogre3d.org/forums/viewtopic. ... 93&start=0

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US

Re: Picking; linking x y screen coordinates to scene components

Post by xavier » Wed Mar 25, 2009 12:10 am

madmarx wrote: Opengl picking is a feature since at least opengl 1.2.(try google if you don't believe me).
I did Google before posting, and saw no reference to it, other than

http://www.opengl.org/resources/faq/tec ... ection.htm

GL_SELECTION is not mouse picking -- it's the same concept as hardware occlusion query, and requires a render in order to work.

Not only that, it has no analogue in Direct3D, which should be the obvious answer to idhan's question as to why Ogre doesn't support it -- Ogre does not provide an interface to functionality that exists in one API but not the other.

Regardless, none of this addresses idhan's real question: "why doesn't Ogre do this for me so I don't have to?" I think I've answered that amply, and am done repeating myself on this matter.
0 x
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

MattStevens
Goblin
Posts: 239
Joined: Mon Apr 07, 2008 10:27 pm

Re: Picking; linking x y screen coordinates to scene components

Post by MattStevens » Wed Apr 01, 2009 9:28 pm

In my opinion, it is a feature that does have its place in Ogre. We already have the feature with "RaySceneQuery" that uses the bounding boxes, so I believe the "polygon-level ray picking" feature could fit in. Yes, there could be a performance issue in some case, but so does everything else in Ogre. And yes, it would not fit everyone's need, but we can try to please as many as possible.

Also I find xavier's post to be very aggressive without reason. The whole point is not that we want to be spoon-fed and a full "ready-made application", we just believe it is a feature that has it's place and would enhanced Ogre. That's all. There's no whining and no complaining, people in this thread were making positive suggestion on how to implement a general purpose picking feature that many Ogre users could use, while still fitting into Ogre's scope.

- Matt
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Picking; linking x y screen coordinates to scene components

Post by Kojack » Wed Apr 01, 2009 10:07 pm

We already have the feature with "RaySceneQuery" that uses the bounding boxes, so I believe the "polygon-level ray picking" feature could fit in.
In fact we already have some scene managers doing it, so there's an inconsistency.
Both the Terrain and BSP scene managers will do polygon level intersects against the level (ground for Terrain, the static world for BSP) when you do a ray scene query.

So it's hard to justify not having a feature when we already have it partially done (it's against world geometry, not entities) in 2 of the official scenemanagers. :)

It becomes harder with a pure ray vs triangle method when an entity has a vertex shader which changes it's shape or has hardware skinning, but for general purpose entities it seems like a logical thing to have.
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: Picking; linking x y screen coordinates to scene components

Post by jacmoe » Sun Apr 05, 2009 9:50 am

Kojack wrote:
We already have the feature with "RaySceneQuery" that uses the bounding boxes, so I believe the "polygon-level ray picking" feature could fit in.
In fact we already have some scene managers doing it, so there's an inconsistency.
Both the Terrain and BSP scene managers will do polygon level intersects against the level (ground for Terrain, the static world for BSP) when you do a ray scene query.
The world fragments returned by the BSP scenequery only return plane bounded volumes, not actual polygonial data.
And the TSM returns the ground, not the actual polygon.
Kojack wrote:So it's hard to justify not having a feature when we already have it partially done (it's against world geometry, not entities) in 2 of the official scenemanagers. :)
It's entirely up to the author of any particular scenemanager to implement scenequeries.
Kojack wrote:It becomes harder with a pure ray vs triangle method when an entity has a vertex shader which changes it's shape or has hardware skinning, but for general purpose entities it seems like a logical thing to have.
An irresistible patch seems to be a good way to sneak this feature into Ogre.
We need to be careful, though: what belongs to the scenemanager and what belongs to the core needs to be thought out.
I don't see any particular reason not to have this feature, if done the right way.
Both hardware accelerated and software poly-picking against movable objects.
A patch on the tracker is always better than a mere feature request. :)
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
SomeFusion
Gremlin
Posts: 191
Joined: Sun Dec 01, 2002 12:38 am

Re: Picking; linking x y screen coordinates to scene components

Post by SomeFusion » Sun Apr 05, 2009 4:59 pm

You could also try to use a selection buffer instead of ray-triangle collision.
I posted a working example here: http://wiki.python-ogre.org/index.php/C ... ion_Buffer
Adapting this to C++ propably isn't a big problem.


I use it in my editor project for pixel perfect selection.
I never had any speed problems even for larger scenes with my python version.
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=48714
0 x
Summoning Wars is an open source role-playing game, featuring both a single-player and a multiplayer mode for about 2 to 8 players.
http://www.sumwars.org

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Picking; linking x y screen coordinates to scene components

Post by Kojack » Mon Apr 06, 2009 5:31 pm

jacmoe wrote:The world fragments returned by the BSP scenequery only return plane bounded volumes, not actual polygonial data.
And the TSM returns the ground, not the actual polygon.
Returning plane bounded volumes from BSP is optional, it also supports single point intersection. You can choose which type of intersect you want using the scene query's setWorldFragmentType() method.
For single point intersect, it recursively traces the ray through the bsp tree, doing AABB tests against movable objects as it goes. When it reaches a leaf node, it performs accurate intersection against the planes of the leaf node's brush, and returns the vector3 where the ray intersects the plane if no movable objects were in the way. Since a bsp's level geometry is made of bounded planes and the ray query performs perfect ray intersect against planes, this means it does accurate polygon collision against the bsp level (but not against movable objects, they still intersect the AABB).

For TSM, it has 2 methods of calculating a single intersect point. If the ray direction is straight up or down, it performs a linear interpolation of the height of the vertices surrounding the xz position of the ray origin, which gives an exact collision point with the ground.
If the ray direction isn't exactly vertical, then it iterates along the ray testing for a change in sign of the height at each interval. When the height changes sign (from above ground to below ground) the current position along the ray is returned as the intersect point. This isn't exactly accurate, but it is still trying to perform an intersect against actual level geometry rather than just an AABB of the level.

True, neither of these give info on the actual thing hit, but they are examples of "raycast to polygon level" which has been mentioned in this thread a few times.
0 x

DarkHorizon
Kobold
Posts: 35
Joined: Thu Mar 01, 2007 6:28 pm

Re: Picking; linking x y screen coordinates to scene components

Post by DarkHorizon » Thu May 07, 2009 3:05 am

Since Ogre already offers bounding-box level picking, couldn't that hit-list be shoe-horned into pixel-perfect picking? E.g. if a ray potentially intersects 10 objects, only those 10 objects would need to be rendered to RTT or whatever (and not the entire scene), thus improving performance drastically.

Just an idea from a noob...
0 x

User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany

Re: Picking; linking x y screen coordinates to scene components

Post by xadhoom » Thu May 07, 2009 8:24 am

Special Raycaster implementations behave like this. They are much more resource expensive then rasterizers which are used in typical games today...

xad
0 x

User avatar
crazii
Kobold
Posts: 25
Joined: Tue Jan 13, 2009 10:06 am
Location: PRC.Asia

Re:

Post by crazii » Fri Jun 26, 2009 7:27 am

KungFooMasta wrote:
ah,I thought this is good,but yet not accurate enough.not quite appliable to skeleton animations.coz mesh infomation we get is the original(none-animated) buffer.so I guess a RT approach is needed,some like render a pointer(address) or id to the rendertarget.
0 x
The world is full of BUGs.

User avatar
crazii
Kobold
Posts: 25
Joined: Tue Jan 13, 2009 10:06 am
Location: PRC.Asia

Re: Picking; linking x y screen coordinates to scene components

Post by crazii » Sat Jun 27, 2009 12:04 pm

finnaly I got one solution,just using the method in the wiki,but added skeleton animation pick.
main approach is to use subentity's "_getSkelAnimVertexData()" method.this also need CPU to calulate skeleton animation,"addSoftwareAnimationRequest" called. :D
0 x
The world is full of BUGs.

marchingcubes
Kobold
Posts: 35
Joined: Sun Jul 26, 2009 10:19 am

Re: Picking; linking x y screen coordinates to scene components

Post by marchingcubes » Sun Jul 26, 2009 8:48 pm

I am using OGRE to render a number of texture-mapped quads, most of which contain large alpha-masks. this means that when picking, I wish to ignore any area of a polygon that has alpha over a certain threshold applied - I need to 'pick through' transparent areas. Everything i need to pick is an Entity. I've got this mostly implemented, and this thread is quite interesting.

So far, I do the following:

Set up an alternate scene manager for the entities
Clone my main scene camera
Set up a RTT target for the pick buffer

Create a shader material that renders the opaque portions of my textures (using a simple threshold alpha scheme) as a solid colour, passed as a shader parameter.

Each time the user clicks the mouse, I:

Perform a RaySceneQuery on the main scene, extracting a list of the 'hit' entities
Copy my main scene camera's position and orientation to my 'alternate' scene managers camera
Create copies of my 'hit' entities, and attach them to my alternate scene manager.
Create copies of my selection material, setting their colour shader parameter to an indexed value, and assign it to my entities.
Render
Clean-up - destroy/unload any entities/textures/materials in my alternate scene manager.

Now i have an RTT texture with an image of my RaySceneQuery-hit objects silhouettes, each indexed with a colour. I can write this buffer out to disk and see it all looks correct.

I can read this texture back to main memory in its entirety using a PixelBox and then extract my required coordinate, but i'd really like to either:

Set up my alternate scene managers camera frustum to include only a single pixel's area - this would let me set up a 1x1 RTT texture and read it back to main memory in it's entirety

or:

Render the entire scene from the main camera clones POV and read back only a single pixel from this texture.

However i'm not 100% sure on how to do either of these things - its not clear to me how to calculate the alternate camera's frustum so it encompasses only a single pixel on the view set up by the 'main' camera, nor can I find an obvious API call that will let me copy an area of a RTT to main memory

Thanks for any help you can provide.
0 x

User avatar
wonderswan
Halfling
Posts: 40
Joined: Fri Jul 11, 2008 8:56 pm

Re: Picking; linking x y screen coordinates to scene compone

Post by wonderswan » Mon Apr 05, 2010 5:06 pm

Reviving this thread to ask if these has been any progress on this? OGRE support for ray intersection to the polygon level on entities would be an incredibly welcome and appropriate feature!
0 x

User avatar
madmarx
OGRE Expert User
OGRE Expert User
Posts: 1668
Joined: Mon Jan 21, 2008 10:26 pm

Re: Picking; linking x y screen coordinates to scene compone

Post by madmarx » Sat Apr 10, 2010 5:25 pm

The thread that you revived had already informations like this (see previous posts) :

http://www.ogre3d.org/wiki/index.php/Ra ... ygon_level

But if you intend to do big calculation, you could check a collision engin (opcode,...).
0 x
Tutorials + Ogre searchable API + more for Ogre1.7 : http://sourceforge.net/projects/so3dtools/
Corresponding thread : http://www.ogre3d.org/forums/viewtopic. ... 93&start=0

Post Reply