Thread: [Plib-users] Selecting with mouse
Brought to you by:
sjbaker
Menu
▾
▴
plib-users
|
From: SilvioCVdeAlmeida <scv...@gr...> - 2002-09-27 19:57:22
|
Hello... I'm new to the list, so please excuse me if selection is an old issue here... I'm working on a drawing system and I want to find the nice way to select an ssgLeaf with the mouse, in order to edit a colour for example. My difficult is to isolate, from scenery, a traversal suitable to go inside a selecting function along with GL_SELECT, InitNames... But SSG's by-element GL state management apparently make it difficult to treat some very OpenGL specific problems. Does somebody have a good advice? __________________________________________________________ SilvioCVdeAlmeida 2002.09.27 scv...@gr... |
|
From: Steve B. <sjb...@ai...> - 2002-09-28 01:23:40
|
SilvioCVdeAlmeida wrote: > > I'm new to the list, so please excuse me if selection > is an old issue here... > > I'm working on a drawing system and I want to find the > nice way to select an ssgLeaf with the mouse, in order > to edit a colour for example. > > My difficult is to isolate, from scenery, a traversal > suitable to go inside a selecting function along with > GL_SELECT, InitNames... > > But SSG's by-element GL state management apparently > make it difficult to treat some very OpenGL specific > problems. > > Does somebody have a good advice? Take a good, long look at http://ppe.sf.net Nobody is working on that project right now :-( ...but it does allow you to pick polygons and vertices out of a ssgLeaf node and to edit it. ----------------------------- Steve Baker ------------------------------- Mail : <sjb...@ai...> WorkMail: <sj...@li...> URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net |
|
From: David M. <da...@me...> - 2002-09-28 14:05:41
|
Steve Baker writes: > > Does somebody have a good advice? > > Take a good, long look at http://ppe.sf.net > > Nobody is working on that project right now :-( > ...but it does allow you to pick polygons and vertices > out of a ssgLeaf node and to edit it. I found the ppe source complex and unhelpful, so I'll recommend against looking at it if you're already confused. Steve and others have assured me that it's easy to pick the SSG entities under a screen location with existing SSG code. Could someone please explain precisely how? Let's assume that I have ssgRoot * root; and ssgContext * context; Using PUI, I receive a mouse click at x=30, y=50. Now, exactly what C++ code would I use to get the list of ssgEntity objects under that screen location? Thanks, and all the best, David -- David Megginson, da...@me..., http://www.megginson.com/ |
|
From: Steve B. <sjb...@ai...> - 2002-09-28 14:19:52
|
David Megginson wrote: > Steve Baker writes: > > > > Does somebody have a good advice? > > > > Take a good, long look at http://ppe.sf.net > > > > Nobody is working on that project right now :-( > > ...but it does allow you to pick polygons and vertices > > out of a ssgLeaf node and to edit it. > > I found the ppe source complex and unhelpful, so I'll recommend > against looking at it if you're already confused. Well, it is complex but... > Steve and others have assured me that it's easy to pick the SSG > entities under a screen location with existing SSG code. I don't think I ever said it was easy. It's possible though. PLIB wasn't ever designed to do this - so it's not a simple mechanism and it's not documented - if you want to do it, you'll *HAVE* to read the PPE sources. I'm sorry if that's not convenient - but like I said, PLIB wasn't designed with this kind of thing in mind. ----------------------------- Steve Baker ------------------------------- Mail : <sjb...@ai...> WorkMail: <sj...@li...> URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net |
|
From: David M. <da...@me...> - 2002-09-28 14:38:09
|
Steve Baker writes:
> PLIB wasn't ever designed to do this - so it's not a simple
> mechanism and it's not documented - if you want to do it, you'll
> *HAVE* to read the PPE sources.
>
> I'm sorry if that's not convenient - but like I said, PLIB wasn't
> designed with this kind of thing in mind.
It's not a matter of convenience -- after two hours with the PPE
sources, I was scarcely any more enlightened than I am now.
We've already begun this discussion, but it's worth repeating that
this should be core functionality for a scene-graph API -- any 3D
editor or any game or simulation that allows the user to interact with
the scene graph using the mouse (i.e. to manipulate objects) will need
to do this.
If someone can explain what I need to do, I'll be happy to contribute
an ssgSelect() function so that we won't have to rehash this thread in
the future:
ssgEntity ** ssgSelect (ssgRoot * root, ssgContext * context,
int mouse_x, int mouse_y);
(or something similar.)
All the best,
David
--
David Megginson, da...@me..., http://www.megginson.com/
|
|
From: Norman V. <nh...@ca...> - 2002-09-30 11:08:05
|
David Megginson > Steve Baker writes: > > > PLIB wasn't ever designed to do this - so it's not a simple > > mechanism and it's not documented - if you want to do it, you'll > > *HAVE* to read the PPE sources. > > > > I'm sorry if that's not convenient - but like I said, PLIB wasn't > > designed with this kind of thing in mind. > > It's not a matter of convenience -- after two hours with the PPE > sources, I was scarcely any more enlightened than I am now. Hmm.. If the PPE source is that 'opaque' then a 'refresher' course in the OpenGL 'way' might help http://fly.cc.fer.hr/~unreal/theredbook/chapter12.html Norman |
|
From: David M. <da...@me...> - 2002-09-30 12:45:18
|
Norman Vine writes: > If the PPE source is that 'opaque' then a 'refresher' course in > the OpenGL 'way' might help > http://fly.cc.fer.hr/~unreal/theredbook/chapter12.html That's not the issue -- I understand (most of) the OpenGL stuff, but I find the PPE source very difficult to follow. No offence is intended to the authors; my point is just that "read PPE" isn't particularly helpful advice either to me or to the others who've posted the same question. I'd like to make two major points: 1. The lack of a simple objects-under-the-mouse function in SSG is a serious gap; i.e. it's a need-to-have, not a want-to-have feature for a general-purpose scene-graph API. 2. I'm not assuming that it's Steve's responsibility to fill that gap, but would be grateful for more concrete guidance from the plib development community as a whole. Point #1 might not be self-evident to someone like Steve who writes high-end simulation software that will be used with prebuilt panels and cockpits, but it's critical for the PC world. It's useful not only for operating instruments in a flight or racing simulator, but also for manipulating objects in a modeller, identifying features in a 3D GIS display, etc. etc. etc. There's no point making each application writer recreate this code from scratch. All the best, David -- David Megginson, da...@me..., http://www.megginson.com/ |
|
From: Curtis L. O. <cu...@me...> - 2002-09-30 14:02:52
|
David, I think step one would be to get a general purpose vector/scene-graph intersection routine in plib. Plib does have something that will intersect a z=up vector with the geometry (for use in finding ground height in a z=up game.) But, there needs to be a more general purpose routine that can find intersections with any arbitrary vector. FlightGear has something close, but it is highly optimized and specialized for the flightgear scenery so it may not work as general purpose drop in to plib. But, once you have such a thing, the it should be relatively straight forward to figure out which vector goes from your eye/camera view point through the near clip plane at the mouse coordinates, and then intersect this vector with the scene graph. You'll likely need to do some post processing of the results to find the particular intersection point of interest, but that would be pretty application specific anyway. Plib does have some sort of "LOS" intersection routine stubbed in, but last time I checked in was completely in-op. That's how my mind works any way, there's probably a much cleverer/quicker way with inverting the camera matrix or something, but I don't feel that matrix-friendly today to even try to think that one through. Regards, Curt. David Megginson writes: > Norman Vine writes: > > > If the PPE source is that 'opaque' then a 'refresher' course in > > the OpenGL 'way' might help > > http://fly.cc.fer.hr/~unreal/theredbook/chapter12.html > > That's not the issue -- I understand (most of) the OpenGL stuff, but I > find the PPE source very difficult to follow. No offence is intended > to the authors; my point is just that "read PPE" isn't particularly > helpful advice either to me or to the others who've posted the same > question. > > I'd like to make two major points: > > 1. The lack of a simple objects-under-the-mouse function in SSG is a > serious gap; i.e. it's a need-to-have, not a want-to-have feature > for a general-purpose scene-graph API. > > 2. I'm not assuming that it's Steve's responsibility to fill that gap, > but would be grateful for more concrete guidance from the plib > development community as a whole. > > Point #1 might not be self-evident to someone like Steve who writes > high-end simulation software that will be used with prebuilt panels > and cockpits, but it's critical for the PC world. It's useful not > only for operating instruments in a flight or racing simulator, but > also for manipulating objects in a modeller, identifying features in a > 3D GIS display, etc. etc. etc. There's no point making each > application writer recreate this code from scratch. > > > All the best, > > > David > > -- > David Megginson, da...@me..., http://www.megginson.com/ > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > plib-users mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-users -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities cu...@me... cu...@fl... Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org |
|
From: Steve B. <sjb...@ai...> - 2002-09-30 22:17:03
|
Curtis L. Olson wrote: > I think step one would be to get a general purpose vector/scene-graph > intersection routine in plib. Plib does have something that will > intersect a z=up vector with the geometry (for use in finding ground > height in a z=up game.) But, there needs to be a more general purpose > routine that can find intersections with any arbitrary vector. Whilst I agree that this is useful - for selection, it's better to use the OpenGL mechanism because it allows you to select within a rubber-banded region - and it stands a good chance of being hardware accellerated. ----------------------------- Steve Baker ------------------------------- Mail : <sjb...@ai...> WorkMail: <sj...@li...> URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net |
|
From: David M. <da...@me...> - 2002-09-30 22:40:10
|
Steve Baker writes: > Whilst I agree that this is useful - for selection, it's better to use > the OpenGL mechanism because it allows you to select within a rubber-banded > region - and it stands a good chance of being hardware accellerated. How would you map from the OpenGL hits back to the scene graph, without doing a depth-first search of the whole thing? All the best, David -- David Megginson, da...@me..., http://www.megginson.com/ |
|
From: Steve B. <sjb...@ai...> - 2002-10-01 00:04:10
|
David Megginson wrote: > Steve Baker writes: > > > Whilst I agree that this is useful - for selection, it's better to use > > the OpenGL mechanism because it allows you to select within a rubber-banded > > region - and it stands a good chance of being hardware accellerated. > > How would you map from the OpenGL hits back to the scene graph, > without doing a depth-first search of the whole thing? My recollection of how it worked with PPE is that I built a table of OpenGL "name" tags versus SSG node addresses while descending the scene graph for cull/draw and then when I retrieve the name tags from the OpenGL pick function, it's a simple lookup table to get directly to the SSG node. What vastly complicated PPE was that we needed to be able to pick each vertex and each edge. I don't recall how that was done. ----------------------------- Steve Baker ------------------------------- Mail : <sjb...@ai...> WorkMail: <sj...@li...> URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net |
|
From: Andy R. <an...@ne...> - 2002-10-01 02:59:24
|
Curtis L. Olson wrote: > I think step one would be to get a general purpose vector/scene-graph > intersection routine in plib. Plib does have something that will > intersect a z=up vector with the geometry (for use in finding ground > height in a z=up game.) But, there needs to be a more general purpose > routine that can find intersections with any arbitrary vector. This shouldn't be too terribly difficult. The mouse vector can be gotten from the modelview/projection matrices. Either invert them yourself or use gluUnproject(). Transform the near and far plane and you'll get two world-space points to define your line. Then recurse into the scene graph, testing the bounding sphere's against the line*. When you find a leaf whose sphere matches, test each triangle** for intersection. If the bounding spheres are sane, it works in log time in the geometry complexity. And I agree -- vector intersection should be a core plib feature. The landing gear code wants it too. Andy * This test is pretty easy -- just project the sphere centroid onto any 2D space perpendicular to the line and take the 2D distance along the plane. That sounds harder than it is: pick any vector and cross it with the line direction to get a perpendicular vector. Cross that with the line again and normalize all three. These three vectors are the columns of your rotation matrix. Just run any vector from the line to the sphere centroid through this matrix, and ignore the coordinate along the line direction. The remaining 2D distance is the distance to the line. ** This one is harder. I'd have to look it up. You could do it with the projection above -- the problem then becomes a 2D point-in-polygon test, which is reasonably easy. There might be a better way, though. -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA an...@ne... http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X