Page 3 of 4

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

Posted: Mon Mar 23, 2009 5:11 pm
by idhan
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.

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

Posted: Mon Mar 23, 2009 6:16 pm
by jacmoe
If you're happy with IrrLicht, then go for it. :wink:

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

Posted: Mon Mar 23, 2009 7:51 pm
by idhan
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.

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

Posted: Mon Mar 23, 2009 8:06 pm
by xavier
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".

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

Posted: Mon Mar 23, 2009 8:28 pm
by idhan
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?

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

Posted: Mon Mar 23, 2009 10:09 pm
by jacmoe
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.

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

Posted: Mon Mar 23, 2009 10:43 pm
by idhan
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:

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

Posted: Mon Mar 23, 2009 11:05 pm
by xavier
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?

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

Posted: Mon Mar 23, 2009 11:55 pm
by idhan
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:

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

Posted: Tue Mar 24, 2009 12:27 am
by xavier
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.

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

Posted: Tue Mar 24, 2009 12:58 am
by idhan
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.

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

Posted: Tue Mar 24, 2009 9:25 pm
by madmarx
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: !

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

Posted: Wed Mar 25, 2009 12:10 am
by xavier
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.

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

Posted: Wed Apr 01, 2009 9:28 pm
by MattStevens
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

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

Posted: Wed Apr 01, 2009 10:07 pm
by Kojack
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.

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

Posted: Sun Apr 05, 2009 9:50 am
by jacmoe
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. :)

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

Posted: Sun Apr 05, 2009 4:59 pm
by SomeFusion
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

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

Posted: Mon Apr 06, 2009 5:31 pm
by Kojack
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.

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

Posted: Thu May 07, 2009 3:05 am
by DarkHorizon
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...

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

Posted: Thu May 07, 2009 8:24 am
by xadhoom
Special Raycaster implementations behave like this. They are much more resource expensive then rasterizers which are used in typical games today...

xad

Re:

Posted: Fri Jun 26, 2009 7:27 am
by crazii
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.

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

Posted: Sat Jun 27, 2009 12:04 pm
by crazii
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

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

Posted: Sun Jul 26, 2009 8:48 pm
by marchingcubes
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.

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

Posted: Mon Apr 05, 2010 5:06 pm
by wonderswan
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!

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

Posted: Sat Apr 10, 2010 5:25 pm
by madmarx
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,...).