Re: [osg-users] [MASSMAIL] PolytopeIntersector and LineSegmentIntersector
Hi Gianni,
On 03.11.2014 10:37, Gianni Ambrosio wrote:
Hi All,
I'm trying to handle mouse movements to show some informations to the user.
I have basically two questions.
1) Lookig at osgkeyboardmouse.cpp example found the following code:
Code:
if (_useWindowCoordinates)
{
// use window coordinates
// remap the mouse x,y into viewport coordinates.
osg::Viewport* viewport = viewer-getCamera()-getViewport();
double mx = viewport-x() + (int)((double
)viewport-width()*(ea.getXnormalized()*0.5+0.5));
double my = viewport-y() + (int)((double
)viewport-height()*(ea.getYnormalized()*0.5+0.5));
// half width, height.
double w = 5.0f;
double h = 5.0f;
picker = new osgUtil::PolytopeIntersector(
osgUtil::Intersector::WINDOW, mx-w, my-h, mx+w, my+h );
} else {
double mx = ea.getXnormalized();
double my = ea.getYnormalized();
double w = 0.05;
double h = 0.05;
picker = new osgUtil::PolytopeIntersector(
osgUtil::Intersector::PROJECTION, mx-w, my-h, mx+w, my+h );
}
Is there a casa in which osgUtil::Intersector::WINDOW option is preferred
with respect to osgUtil::Intersector::PROJECTION?
The window coordinates will give you a pixel based pick area whereas the
projection coordinates
work on normalized [-1,1] coordinates.
If your application supports different screen resolutions it might be more
intuitive for the user
to use window coordinates.
2) osgUtil::LineSegmentIntersector does not seem to work fine if the geometry
is a line created with:
osg::Vec3Array* vertices = new osg::Vec3Array;
...
osg::DrawElementsUInt* elements = new
osg::DrawElementsUInt(osg::PrimitiveSet::LINE_STRIP);
geometry-setVertexArray(vertices);
geometry-addPrimitiveSet(elements);
In this case when I move the mouse over that geometry I get
containsIntersections() = false.
Could you please explain me why?
LineSegementIntersector only handles primitives that cover a 2d-area
(triangle/quad-strip/sets and such).
PolytopeIntersector can handle all primitives but it slower for 2d primitives.
Regards,
Gianni
Best regards,
Peter
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector and LineSegmentIntersector
Hi Gianni,
On 03.11.2014 11:47, Gianni Ambrosio wrote:
Hi Peter,
thank you for the fast reply.
I need some clarifications about question 1.
In my application I will use the picked point to calculate, and then show,
the arclength of a path, i.e. the length of the path from start to the picked
point. So I would not need to show coordinates to the user. So I guess WINDOW
or PROJECTION would be the same for my case.
But I would like to understand why I get different coordinates from
intersection.localIntersectionPoint with osgUtil::Intersector::WINDOW wrt
osgUtil::Intersector::PROJECTION
Here is a code snippet as an example:
Code:
osgUtil::PolytopeIntersector* picker;
{
osg::Viewport* viewport = viewer-getCamera()-getViewport();
double mx = viewport-x() + (int)((double
)viewport-width()*(ea.getXnormalized()*0.5+0.5));
double my = viewport-y() + (int)((double
)viewport-height()*(ea.getYnormalized()*0.5+0.5));
double w = 5.0f;
double h = 5.0f;
picker = new osgUtil::PolytopeIntersector(
osgUtil::Intersector::WINDOW, mx-w, my-h, mx+w, my+h );
osgUtil::IntersectionVisitor iv(picker);
viewer-getCamera()-accept(iv);
if (picker-containsIntersections())
{
osgUtil::PolytopeIntersector::Intersection intersection =
picker-getFirstIntersection();
std::cout osgUtil::Intersector::WINDOW
intersection.localIntersectionPoint.x()
intersection.localIntersectionPoint.y()
intersection.localIntersectionPoint.z() std::endl;
}
}
{
double mx = ea.getXnormalized();
double my = ea.getYnormalized();
double w = 0.05;
double h = 0.05;
picker = new osgUtil::PolytopeIntersector(
osgUtil::Intersector::PROJECTION, mx-w, my-h, mx+w, my+h );
osgUtil::IntersectionVisitor iv(picker);
viewer-getCamera()-accept(iv);
if (picker-containsIntersections())
{
osgUtil::PolytopeIntersector::Intersection intersection =
picker-getFirstIntersection();
std::cout osgUtil::Intersector::PROJECTION
intersection.localIntersectionPoint.x()
intersection.localIntersectionPoint.y()
intersection.localIntersectionPoint.z() std::endl;
}
}
And I get an output like this:
osgUtil::Intersector::WINDOW 18.8821 0.0163024 0
osgUtil::Intersector::PROJECTION 31.7343 0.0274029 0
osgUtil::Intersector::WINDOW 18.8821 0.0163024 0
osgUtil::Intersector::PROJECTION 31.7343 0.0274029 0
osgUtil::Intersector::WINDOW 22.529 0.019452 0
osgUtil::Intersector::PROJECTION 34.8797 0.0301198 0
The WINDOW case shows different coordinates (look at X coordinate please) wrt
PROJECTION case, but they does not seem to be one in pixel and the other
normalized. Am I missing something?
The PROJECTION/WINDOW parameter specifies the coordinate system of the polytope
you are using.
The intersections points you are printing are in the local coodinate system,
i.e. the one where the basic
geometry was defined.
The PolytopeIntersector has the added quirk that the localIntersectionPoint is
actually the geometric
center of all intersectionPoints. IntersectionPoints are points where the
primitive is intersecting a polytope plane
and all primitive vertices completely inside the polytope volume. This could
account for different results you are seeing.
Moreover in the WINDOW case I need to be closer to the geomwetry to get a
valid intersection. Can you explain me please why?
The WINDOW case uses a 10 by 10 pixel area around the mouse position and the
projection case
uses 0.1*screenWidth by 0.1*screenHeight which is only the same if you have a
screen resolution of 100x100.
Best regards,
Gianni
Best regards,
Peter
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [MASSMAIL] Erratical behaviour with PolytopeIntersector
Hello,
On 08/04/2014 11:18 AM, Sonya Blade wrote:
Dear All,
I'm experiencing very weird problem when using the polytope intersector.
Since there is not any explicit example on how
to use polytope example with rectangular selection I use osgPick example in
OSG and modify the codes to suit my need.
The canonical example for PolytopeIntersector is osgkeyboardmouse which shows
one possible usage.
Normally the below code picks the objects on scene but shows that 400 picked
objects which is not correct and far beyond of
scene object range where that I have, I only have 5-6 object in scene,
As Sebastian Messerschmidt has suggested the PolytopeIntersector returns
intersections on
a per-primitive level and that also includes all primitives inside the polytope.
If you only want results on a higher level (e.g. per drawable) you can just
modify
the counting loop in you code to eliminate duplicate drawables.
Admittedly, the current behaviour is of PolytopeIntersector is not very space-
or time-efficient
for your use-case. I think a useful extension would be some kind of
only-first-intersection-flag
which should reduce the number of generated intersecions for cases like yours.
Cheers,
Peter
What could be the reason of that malfunctioning ? I 'll appreciate your
guidance on that !.
case (osgGA::GUIEventAdapter::RELEASE):
{
if (btn_counter == 1 )
{
firstX = ea.getX(); firstY = ea.getY();
btn_counter = 2;
break;
}
if (btn_counter==2)
{
btn_counter = 1;
osgUtil::PolytopeIntersector* polytop = new
osgUtil::PolytopeIntersector( osgUtil::Intersector::WINDOW, firstX,firstY,
ea.getX(), ea.getY() );
osgUtil::IntersectionVisitor iv(polytop);
view-getCamera()-accept(iv);
int k;
if (polytop-containsIntersections() )
{
osgUtil::PolytopeIntersector::Intersections
intersections= polytop-getIntersections();
osg::Vec3 screenpos =
osg::Vec3(ea.getX(),ea.getY(),0);
for(osgUtil::PolytopeIntersector::Intersections::iterator hitr =
intersections.begin();
hitr != intersections.end(); ++hitr)
{
k+=1;
std::cout k
hitr-drawable-getName() hitr-drawable-className()\n ;
}
}
}
}
}
}
};
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Erratical behaviour with PolytopeIntersector
Hello again, On 08/06/2014 10:28 AM, Sonya Blade wrote: Hi All and Thanks for your feedback, Please find the reproduced example and obj file at the attachment, it doesn't have any visual aids, with 1st user click program creates leftbottom of rectangle, second user click creates righttop, for intersection rectangle and invokes PolytopeIntersector. If I select them all I'd expect totally 5 objects to be picked, but program produces 420. There is a high chance that as Sebastian Messerschmidt emphasized, I pick all vertices but can you confirm it ? Thanks for your example. I can see that you are using setIntersectionLimit(osgUtil::Intersector::LIMIT_ONE_PER_DRAWABLE ) which should be doing what I meant by only-first-intersection. Testing your example I do get a lot more intersecions than is to be expected. Clearly something is wrong there. But I think I found the reason for the erratic part of your problem: Currently PolytopeIntersector does not produce correct results in presence of scaling transformations (which are used in your example). As a workaround you could rescale your geometry directly. Cheers, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Erratical behaviour with PolytopeIntersector
Hello, On 08/06/2014 02:33 PM, Sonya Blade wrote: Thank you for the entrypoint, What you mean by rescaling the geomtry directly? Directly modify the vertices and dirty the displaylist, rather than using transformation matrices? I'll try that workaround, it sounds quite coherent for the reason of discrepancy. Yes, I meant modifying the vertex coordinates. I can see that you are using setIntersectionLimit(osgUtil::Intersector::LIMIT_ONE_PER_DRAWABLE ) which should be doing what I meant by only-first-intersection. I personally not observed any improvement in Polytope behaviour in any of the (/NO_LIMIT, //LIMIT_ONE_PER_DRAWABLE/ , /LIMIT_NEAREST/ etcc.. settings, in any case it retrieves plenty of objects. I found the the reason why your code produces to many intersection: You must call setIntersectionLimit(osgUtil::Intersector::LIMIT_ONE_PER_DRAWABLE ) before the result collection starts, i.e.: polytop-setIntersectionLimit(osgUtil::Intersector::LIMIT_ONE_PER_DRAWABLE ); osgUtil::IntersectionVisitor iv(polytop); view-getCamera()-accept(iv); Then I do get at most 5 intersecions with your example as is to be expected. Regards, Cheers, Peter Date: Wed, 6 Aug 2014 14:16:31 +0200 From: peter.hre...@intes.de To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Erratical behaviour with PolytopeIntersector Hello again, On 08/06/2014 10:28 AM, Sonya Blade wrote: Hi All and Thanks for your feedback, Please find the reproduced example and obj file at the attachment, it doesn't have any visual aids, with 1st user click program creates leftbottom of rectangle, second user click creates righttop, for intersection rectangle and invokes PolytopeIntersector. If I select them all I'd expect totally 5 objects to be picked, but program produces 420. There is a high chance that as Sebastian Messerschmidt emphasized, I pick all vertices but can you confirm it ? Thanks for your example. I can see that you are using setIntersectionLimit(osgUtil::Intersector::LIMIT_ONE_PER_DRAWABLE ) which should be doing what I meant by only-first-intersection. Testing your example I do get a lot more intersecions than is to be expected. Clearly something is wrong there. But I think I found the reason for the erratic part of your problem: Currently PolytopeIntersector does not produce correct results in presence of scaling transformations (which are used in your example). As a workaround you could rescale your geometry directly. Cheers, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersection of lines: line widths?
Hi Andy, Am 22.10.2012 21:05, schrieb Andy Skinner: I know that intersections are about 3d world coordinates, and line widths are about pixels. But is there a way to use line widths in calculating intersections with the polytope intersector? There is currently no code in PolytopeIntersector which takes line widths (or point sizes) into account. While it would be possible to implement it I doubt that it would be worth the effort. In other words, I want a wider line to be easier to pick. I think this could be accomplished by a post-processing step on the results: Normally you would use the nearest intersection but in your case you could also check the line width and prefer thicker lines over nearer lines. I could just expand the polytope a bit, except that the lines are just one kind of thing in the scene, and they could have different line widths. I think your expanded polytope-idea should also work. You could use differently sized polytopes for different line widths. As for your other kinds of thinks in the scene you should be aware that the performance of PolytopeIntersector for 2d-geometries is rather bad. It is much faster to use LineSegementIntersector for those and combine the results afterwards. thanks, andy Cheers, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersection of lines: line widths?
Hi Andy, Am 23.10.2012 15:03, schrieb Andy Skinner: Thanks for comments, Peter. By easier to pick, I didn't mean relative to other lines in the scene, but that I wouldn't have to be as close to the actual line geometry. It is a question of whether the line will be in the list of intersections, rather than which intersection I choose. I suspect the same thing about whether it is worth the effort. As for your other kinds of thinks in the scene you should be aware that the performance of PolytopeIntersector for 2d-geometries is rather bad. It is much faster to use LineSegementIntersector for those and combine the results afterwards. By 2d-geometries, do you mean triangles and quads (and not 2D scenes)? And that it would be better to run the polytope intersector for points and lines, and a separate line intersector for triangles and quads, and combine intersections? I know all of that is pretty much what you said, but I wanted to be sure. That's using two intersection traversals. Sounds interesting if it is really faster. Yes, I did mean triangles and quads. I haven't done performance measurements but I did implement the PolytopeIntersector for triangles and quads. There are quite a few cases to cover to get it correct. The IntersectionVisitor has the additional advantage that it can use a kd-tree for speedup (which unfortunately is totally geared towards triangles, and hence unsuitable for the PolytopeIntersector). But, yes, I do mean performing two separate intersections, where you can turn off the PolytopeIntersector checks for 2d-elements by using setDimensionMask(DimZero|DimOne) and merging those results with the results from a LineSegmentIntersector. thanks, andy Cheers, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Arrays and custom allocators?
Hi, Am 13.08.2012 18:07, schrieb Paul Martz: Hi all -- There doesn't seem to be a way to use a custom allocator with an OSG Array type. Is that correct, or have I missed something? I have a large store of array data, and want to create a new instance of an OSG Array that references that data store without invoking a data copy or per-element constructor. The typical way to do this in C++ is with a custom allocator, but as near as I can tell, OSG's Array types don't allow an allocator as a template parameter. If I can't use a custom allocator, does anyone have any ideas on how to create an OSG Array that references a pre-allocated data store? Maybe the osgsharedarray example can give you a hint. It is not using STL-style allocators but you can subclass an osg::Array. Any ideas would be appreciated, thanks. Hope this helps. Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::PolyTope question
Hi Teodor, Am 29.02.2012 15:56, schrieb Teodor Hanchevici: Hi, I have trouble getting all the points that are contained in a polytope. I have 5 points and their coordinates are: [...] A couple of questions: 1. When constructing a polytope from a list of planes, do I have to take care of the normal of the plane? The documentation says When adding planes, their normals should point inwards (into the volume), does this apply to void osg::Polytope::add(const osg::Plane pl) method only? The normal direction is very important. In fact, you get a different polytope when one normal direction is flipped: Think of a cube and add another plane which intersects all 6 planes. Obviously the cube is split into 2 polytopes and only the normal direction determines which one you want. I have not checked your example but you can easily find out which plane is wrongly oriented by calling Plane::distance on your points and checking if the values of that function-call are positive or negative. 2. Is there a better method of achieving this? No, you have to get your normals right. Thank you! Cheers, Teodor Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersectors with double precision
Hi Leandro, Am 25.11.2011 12:47, schrieb Leandro Motta Barros: Hello, In a project I am working on, I need to use intersectors (PolytopeIntersectors, in particular) with double precision floating point, but with the intersectors provided by OSG (using 3.0.1 here), I get only single precision. I noticed that osgUtil::PolytopeIntersector already contains code intended to make it use osg::Vec3f or osg::Vec3d depending whether OSG_USE_FLOAT_PLANE is defined or not -- but there are one or two places in which a osg::Vec3 is used -- which ends up as floats. The code that does is wrong is probably from me. osgUtil::LineSegmentIntersector, on the other hand, uses osg::Vec3 (i.e., floats) everywhere. So, I am ready to change the few bits of osgUtil::PolytopeIntersector still using hardcoded osg::Vec3 and to modify osgUtil::LineSegmentIntersector so that it uses a similar approach (that is, use osg::Vec3f and float if OSG_USE_FLOAT_PLANE is defined, otherwise use osg::Vec3d and double) and send this to osg-submissions. (I did some successful experiments with a fully-double osgUtil::PolytopeIntersector already.) Fixing the missing bits in PolytopeIntersector should be done in any case. The LineSegmentIntersector is a bit more complicated as it uses the KdTree-class is float-only for now and which also would have to me adjusted (it does not look to complicated to do that through a typedef and/or templates). But for LineSegementIntersector I would not make it all depend on OSG_USE_FLOAT_PLANE. That makes sense for PolytopeIntesector as it practically only uses plane calculations. I would suggest something like OSG_USE_FLOAT_LINE_INTERSECTIONS (default ON). Would this be OK? Am am missing something? Would some different approach be preferable? Do you have any other feedback? I like your idea and I think it would be an improvement. In the long run - as an application developer - I would like the have the ability to have both options in the same build. Usually I have raw data in double format and build a float-scenegraph. But for some algorithms I would like to use the original double data. Cheers, LMB Cheers, looking forward to see your submmission Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector usage
Hi Vincent, Am 08.09.2011 08:51, schrieb Vincent Bourdier: Hi all, I'm currently trying to compute an intersection between a sphere and a node. PolytopeIntersector seems to be the best choice according to the documentation, but I didn't find any example of implementation. Have a look at the osgkeyboardmouse example. Next, are there some limitations to its usage ? (I saw something about convex clipping volumes...) PolytopeIntersector is mostly useful when used for interactive picking with small volumes. Its return data structure is too big for large volumes (containing lots of intersections). The goal is to compute if a point is at less than a fixed distance from a node, and to my mind the intersection is the best way but maybe there is something more adapted ? I think that should be possible. I would recommend using a cube which contains the distance-sphere as the polytope and check the results from the PolytopeIntersector for the real (euclidian) distance. I would advise against trying to use a sphere-polytope since the intersector must check all polytope-planes in the innermost loop. Thanks for your help. Regards, Vincent. Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector usage
Hi Vincent, Am 08.09.2011 10:00, schrieb Vincent Bourdier: Hi Peter Le 08/09/2011 09:40, Peter Hrenka a écrit : The goal is to compute if a point is at less than a fixed distance from a node, and to my mind the intersection is the best way but maybe there is something more adapted ? I think that should be possible. I would recommend using a cube which contains the distance-sphere as the polytope and check the results from the PolytopeIntersector for the real (euclidian) distance. I would advise against trying to use a sphere-polytope since the intersector must check all polytope-planes in the innermost loop. I am trying with an octaedron (8 faces) to avoid having a complex structure (like a sphere) with too much faces, just to run some tests. I build the polytope a the point position (radius or the checked distance) and compute the intersection. If there is a least one result, I consider the point is near from the the model. There is no need to check the euclidian distance to my mind, isn't it ? Well, it depends what you mean by distance... If the octahedron is good enough for you then you are done. But if you need to consider the exact (euclidian) distance then must choose your octahedron to contain the distance-sphere and check the results to eliminate the false-positives which lie in the octahedron but not in the sphere. Thanks for your help. Regards, Vincent Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fast VectorArray inizialization.
Hi Giulio,
Am 01.04.2011 10:57, schrieb Giulio De Vecchi:
Hi all,
I have some code like this:
float coordinates[]
...
... an external source fill the previous array ...
...
osg::ref_ptrosg::Vec3Array vertices = new osg::Vec3Array();
for (int i = 0; i 3 * numPoints; i += 3)
{
float x = coordinates[i];
float y = coordinates[i+1];
float z = coordinates[i+2];
vertices-push_back(osg::Vec3(x, y, z));
}
modelGeometry-setVertexArray(vertices);
I'd rather do something like this:
modelGeometry-setVertexArray_FromCArray(coordinates);
Is it possible? How?
Yes, have a look at the example osgsharedarray.
Of course you have to make sure the the array
is not freed until the last draw is finished.
---
Best regards,
Giulio
Cheers,
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
Hi Fred, Am 25.03.2011 11:52, schrieb Fred Smith: Things work if I call setVertexArray. I mean that I have to call setVertexArray, in addition to setVertexAttribArray, even though my shader is solely based on vertex attribute data and doesn't use GL2-style dedicated vertex coordinates data. Code: // This line should not be needed but seems required geom.setVertexArray(vertices); geom.setVertexAttribArray(verticesLoc, vertices); Is this expected? If I compile and use OSG with GL3 core profile support, will this still be required (again, it shouldn't)? This hints again to a faulty bounding box calculation. I you setup a VertexArray OSG uses this to calculate the bounding box. You already said that you provide the bounding box (callback) yourself, so maybe you still have some error there (it was not included in you original post). On the GL trace side I don't see anything wrong when I don't call setVertexArray: glVertexAttribPointer(...); glDrawElements(...); When I also specify a vertex array the glVertexPointer call obviously seems superfluous: glVertexPointer(...); // pointless glVertexAttribPointer(...); // ok glDrawElements(...); Can you compare the traces of the working and the non-working version? If so, can you spot differences in the values of osg_ModelViewProjectionMatrix? Other custom vertex attributes that I tried to use to pass through color data behave fine. Vertex coordinates seem to be treated specially in OSG. Cheers, Fred Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
Hi Fred,
Am 24.03.2011 15:37, schrieb Fred Smith:
Hi,
I can't get vertex attributes to work in my application.
Right now my aim is to display geometry with just any color, meaning I can
have very simple shaders, to start with.
I call setUseModelViewAndProjectionUniforms(true) on application startup to
make sure I can get the MVP matrix as a uniform. I am not calling
setUseVertexAttributeAliasing as I *think* I do not need it (I am not 100%
sure what this feature does, either).
My geometry creation code looks like the following:
Code:
int verticesLoc = 6;
geom.setUseDisplayList(false);
vertices.setName(in_vertex);
geom.setVertexAttribArray(verticesLoc, vertices);
geom.setVertexAttribNormalize(verticesLoc, false);
geom.setVertexAttribBinding(verticesLoc, BIND_PER_VERTEX);
Program *program = new Program();
program.addBindAttribLocation(in_vertex, verticesLoc);
geom.getOrCreateStateSet()-setAttributeAndModes(program, StateSet::ON);
Do you set the initial Bounding Box?
I think with generic Vertex Attributes
OpenSceneGraph has no chance calculate
the Bounding Box by itself.
Cheers,
Peter
My shaders are:
Code:
// vertex shader
#version 150
uniform mat4 osg_ModelViewProjectionMatrix;
in vec3 in_vertex;
in vec4 osg_Vertex;
void main(void)
{
gl_Position = osg_ModelViewProjectionMatrix * vec4(in_vertex, 1.0);
}
// fragment shader
#version 150
out vec4 out_fragcolor;
void main(void)
{
out_fragcolor = vec4(1.0, 0.0, 0.0, 1.0);
}
My window just remains blank. I was wondering whether the automatic setup of
the camera in the viewer would still work when vertices reside in vertex
attribute buffers.
Cheers,
Fred
NB: to refer to the previous, GL3-related topic I opened I am still using a
regular GL 1.x/2.x context here, but would like to transition to GL3
afterwards.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=37864#37864
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL for non-rendering operation
Hi Simon, Am 23.03.2011 04:12, schrieb Simon Kolciter: Well, the problem is that the normal vertices are PER_VERTEX, not PER_PRIMITIVE. In Geometry shader, I only have access to the current primitive, not the whole mesh, right? In principle, you are right, the geometry shader can only access the current primitive, but there are new kinds of primitives that were introduced to give the geometry shader some neighbourhood on information. One of those is the new primitive type GL_TRIANGLES_ADJACENCY which will give you information about adjacent (via edges) triangles. I found a nice explanation at the beginning of http://prideout.net/blog/?p=54 I need to 1. calculate the normal vector of each face (triangle) and add it to the normal vectors of all 3 vertices 2. normalize the normal vector of each vertex (optional) Is there any way to access normal vector of each vertex in geometry shader? In that situation I would think that you need to use TRANSFORM_FEEDBACK to record the primitive normals to a buffer object on a first render pass (with rasterization disables) and then do the summing/ normalization on the second and final render pass. There does not seen to be a lot of support for TRANSFORM_FEEDBACK in OSG at the moment. The only thing i could find was osg::TransformFeedbackBufferBinding. There are some (non-OSG) examples for TRANSFORM_FEEDBACK at http://rastergrid.com/blog/tag/transform-feedback/ Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37819#37819 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL for non-rendering operation
Hi Simon, Am 22.03.2011 16:58, schrieb Simon Kolciter: Hi, I have a model the geometry of which is being modified in real time and therefore, the PER_VERTEX normal vectors have to be updated as well. The modification of normals takes too much computing force, so I thought of pushing the computation onto the GPU. My question: Is it possible to use GLSL for operations that are independent from the actual rendering? I am looking for something like this (all in a C++ function): 1. Push the list of vertices and primitive indices to the GPU. 2. Call GLSL function. 3. Pull the resulting list of normals from the GPU. Is it possible to do it this way? Or are there any other ways to use HW acceleration for such operations using only OSG and GLSL? You could use a geometry shader to calculate the normals on the GPU. The geometry shader basically sees the whole primitive and can can therefore perform the normal calculation of a deforming geometry. Thank you! Cheers, Simon Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to Develop/Create a Cylinder Intersector ??
Hi Sanat, Am 03.03.2011 20:21, schrieb Sanat Talmaki: Hi, I want to test for intersection in my scene using a cylinder instead of a line segment. For example if my object is on a terrain I want to highlight all features that are within an imaginary cylinder around my object. I read about polytope intersector but it seems as though that is for planes only or can I get cylinder intersector from there as well ? You could use the PolytopeIntersector with a hexagonal shape which envelops the cylinder and post-process the results. This sould give you a good aproximation and little false positives. As was noted by Chris PolytopeIntersector can be very slow if there are many Intersections in the picking volume. That is because every primitive and every vertex that is inside the volume is recorded in the result. The kd-tree is not integrated into PolytopeIntersector as of now. Any tips on how I can get started will be much appreciated. Thanks! Sincerely, Sanat. -- Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange behaviour / bug in PolytopeIntersector
Hi Brad,
Have you checked if any your Vertex-Coordinates contain
Infs or NaNs?
Does you geometry have any degenerated primitives
such as lines or triangles with identical vertices?
Next thing I would check would be the consistency
of geometry with respect to array lengths.
If everythings checks out ok, you could add the
NaN-check in PolytopePrimitiveIntersector::checkCandidatePoints
(in src/osgUtil/PolytopeIntersector.cpp).
Cheers,
Peter
Am 23.02.2011 08:54, schrieb Christiansen, Brad:
Hi,
In my application I have found that the PolytopeIntersector is returning
intersections with objects which are behind my camera. The code I am
using is this:
osgUtil::PolytopeIntersector* picker =
new osgUtil::PolytopeIntersector(
osgUtil::Intersector::WINDOW,
leftX,
bottomY,
rightX,
topY);
osgUtil::IntersectionVisitor iv(picker);
camera-getBound();
camera-accept(iv);
if (picker-containsIntersections()) {
osgUtil::PolytopeIntersector::Intersections intersections =
picker-getIntersections();
for (osgUtil::PolytopeIntersector::Intersections::iterator
it=intersections.begin();
it!=intersections.end(); ++it) {
osgUtil::PolytopeIntersector::Intersection intersection=*it;
if(intersection.distance != intersection.distance) { //NaN
//intersected object is behind the camera. Is this a bug?
}
}
}
…
In my efforts to figure out what was going on I came across a possible
clue. For all objects that are behind my camera, intersection.distance
!= intersection.distance (i.e. intersection.distance is NaN). For now I
have worked around the issue by simply discarding results where this is
the case but I am guessing this is a bug.
Before I spend too much time stepping through the code to determine what
is going wrong I want to make sure that this isn't the expected
behaviour. Assuming this is a bug, can anyone who has worked with these
classes before offer any suggestions that might help me track down the
issue?
Cheers,
Brad
DISCLAIMER:---
This e-mail transmission and any documents, files and previous e-mail
messages attached to it are private and confidential. They may contain
proprietary or copyright material or information that is subject to
legal professional privilege. They are for the use of the intended
recipient only. Any unauthorised viewing, use, disclosure, copying,
alteration, storage or distribution of, or reliance on, this message is
strictly prohibited. No part may be reproduced, adapted or transmitted
without the written permission of the owner. If you have received this
transmission in error, or are not an authorised recipient, please
immediately notify the sender by return email, delete this message and
all copies from your e-mail system, and destroy any printed copies.
Receipt by anyone other than the intended recipient should not be deemed
a waiver of any privilege or protection. Thales Australia does not
warrant or represent that this e-mail or any documents, files and
previous e-mail messages attached are error or virus free.
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render To Texture is very slow
Hi Martin, Am 02.02.2011 14:35, schrieb Martin Großer: Hello David, So I use the FRAME_BUFFER_OBJECT and I have a NVIDIA GTX 470 grafics card. I tried the osgprerendercubemap, but I cannot print out the frame rate. Additionally I tried the osgprerender example and I get a frame rate of around 3500 FPS. Here my Implementation: osg::ref_ptrosg::Image img = osgDB::readImageFile(image.tga); osg::ref_ptrosg::Group rtt = new osg::Group; root-addChild(rtt); osg::ref_ptrosg::Camera camera = new osg::Camera; camera-addChild( scene ); camera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); camera-setViewport(0,0,2048,2048); camera-setRenderOrder(osg::Camera::PRE_RENDER, 0); camera-setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); camera-attach(osg::Camera::COLOR_BUFFER, img, 0, 0); Your performance Problem is in the previous line: By attaching an image you instruct OSG to fetch the whole image back to CPU memory (for each frame!). If this is what you really want, it probably is as fast as it will get. If you want to use the rendered image on the GPU, then you should attach an osg::Texture instead. See osgprerender example, with useImage=false. rtt-addChild(camera.get()); Is the image format (internal format) a problem? Thanks Martin Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DrawElements vertices, normals, texcoords, indices without copying to osg::Array
Hi Chris, Am 31.01.2011 17:10, schrieb Chris 'Xenon' Hanson: I have a situation coming up where my code will be fed large blocks of vertex, normal, texcoord and index data from a non-OSG code environment. The goal is to draw this data with DrawElements. Currently, it looks to me like I need to rebuild some of this data (anything Vec*-based) into an osg::Array, which seems to necessitate copying the block. Am I missing anything, or is there some way to get the provided simple C-style arrays of data over to DrawElements without a copy in the middle? I know there will be a copy going from the CPU to the GPU anyway, so I'd like to avoid a second, needless CPU-CPU copy. You can have a look at osgsharedarray in the examples-directory. It shows how you can subclass osg::Array to use static C-array data without copying. Thanks in advance. Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vector of const ref_ptr
Hi Gianni, Gianni Ambrosio schrieb: Il 5/18/2010 6:23 PM, Alberto Luaces ha scritto: Gianni Ambrosio writes: can anybody tell my why I get a bounch of compile errors declaring a std::vector const osg::ref_ptrMyObject? If I remove the const statement it works fine. Why do you want do to that? Simply, to use the const constraints. Example: void Class::method(std::vectorconst A*); That means the content of each object inside the vector does not chenge its status inside the method or more precisely only const methods can be called on a A* inside the method ;-) This works for plain pointers because const pointers are Assignable. But this does not work for osg::ref_ptr because it must be able to change the reference-count of the object it points at. First you would have to make the reference-count mutable and you would have to an osg::ref_const_ptr which implements the proper const-semantics. Whether Robert would approve of such changes is a completely differt matter... I guess you would have errors even if you declared a std::vectorconst int. No, that's not true. It works fine. You should bear in mind that most STL-containers/algorithms are implemented as templates. Have you tried doing anything useful (resize/push_back) with your std::vectorconst int? Mind you, it might even work for your compiler, but the fact remains that no STL-implementation is required to compile this, which will leave you with very unportable code. Regards Gianni Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vector of const ref_ptr
Hi Gianni,
Gianni Ambrosio schrieb:
Hi all,
can anybody tell my why I get a bounch of compile errors declaring a
std::vector const osg::ref_ptrMyObject ?
std::vector has the requirement that the
value type must be Assignable which is not
true for const types (they can be initialized
but not assigned).
Basically that means that the std::vector must be
able to do the following thing internally
(say for push_back, resize):
void _assign(T to, const T from) {
to = from;
}
now, if T itself const this becomes:
void _assign(const T to, const T from) {
to = from;
}
This obviously cannot work.
If I remove the const statement it works fine.
Then you should remove it.
Regards,
Gianni
Cheers,
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using PolytopeIntersector from the root of the scene graph instead of camera
Hi Julien-Charles, Julien-Charles Lévesque schrieb: Hi Peter, What do you mean by a degenerated polytope of volume 0 ? That polytope definitely doesn't have a null volume since I've been using it to select objects in my application and it works. The four planes all have the same starting point because I want the polytope to be a pyramid coming out from a user's hand, so the planes -should- all intersect at the summit, no ? You are right. I did not look closely enough and assumed you where trying to build a parallel polytope. The polytope looks to be alright. Julien-Charles On Thu, Feb 4, 2010 at 8:35 AM, Peter Hrenka p.hre...@science-computing.de mailto:p.hre...@science-computing.de wrote: Hi Julien-Charles, Julien-Charles Lévesque schrieb: [...] Here is my code... stripped down to a minimum. I assume that you have a 4x4 matrix containing orientation of your selector (lOrientation) and a vec3 containing it's position (lPosition). I built the polytope to point in the direction of positive y-axis. Sorry for the french variable names and comments here and there... I don't think they hurt readability much at this level :P However, I wasn't able to extract a reliable 3x3 rotation matrix from mouse coordinates. I can only say that this code works well with the raw 3x3 orientation and position provided by my tracker. Do you have any idea for a desktop variation ? I can implement it. I could also integrate all this in the examplekeyboardmouse, once I've figured out how to do it with a mouse :P I would suggest to control the rotation and position using the keyboard. This should be enough for the purpose of an osg-example. I think it would be nice if the polytope would be visualized as a wireframe model. I also would suggest of creating a new osgpolytopeintersector- example because nobody really looks into osgkeyboardmouse when looking for polytope-intersection functionality... Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using PolytopeIntersector from the root of the scene graph instead of camera
Hi Julien-Charles, Julien-Charles Lévesque schrieb: [...] Here is my code... stripped down to a minimum. I assume that you have a 4x4 matrix containing orientation of your selector (lOrientation) and a vec3 containing it's position (lPosition). I built the polytope to point in the direction of positive y-axis. Sorry for the french variable names and comments here and there... I don't think they hurt readability much at this level :P However, I wasn't able to extract a reliable 3x3 rotation matrix from mouse coordinates. I can only say that this code works well with the raw 3x3 orientation and position provided by my tracker. Do you have any idea for a desktop variation ? I can implement it. I could also integrate all this in the examplekeyboardmouse, once I've figured out how to do it with a mouse :P You seem to use the same base-point for all but one plane: lPlane.set(lNorm, lPosition); This will give you a degenerated polytope of volume 0. Try using lPlane.set(lNorm, lPosition-radius*lNorm); with some radius 0 Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using PolytopeIntersector from the root of the scene graph instead of camera
Hi Julien-Charles, Julien-Charles Levesque schrieb: Hi, I'm trying to use a PolytopeIntersector in my scene and so far I have succeeded but only by using the camera (i.e. mCamera-accept(PolyVisitor)) with a PolytopeIntersector built from x and y coordinates in window frame. However I would rather pass the visitor the root of my scene. I am doing this in a virtual reality project, and using the camera seems to complicate things a fair bit because we modify projection matrices and viewports a whole lot. For my LineSegmentIntersector I have used 3D points in model space, which worked fine when visiting the root of the scene. For the PolytopeIntersector I am unsure how to do this... Only examples I have found so far used either coordinates in projection space or coordinates in window space. Yes, the examples do not use all available constructors of PolytopeIntersector. That is something that has been sitting on my to-do-list for a long time... Now I have seen the CoordinateFrame MODEL or VIEW in the PolytopeIntersector constructor, but I am unsure as how to use it. I have seen that the Znear plane is fixed to 0 for MODEL and VIEW coordinate frames.. Does this mean that any object behind Z=0 could not be intersected? I also have a bad feeling that building and using the PolytopeIntersector in MODEL and VIEW coordinate frames will make it just rectangular instead of pyramidal. There are two constructors that should be suitable for your use-case: /** Construct a PolytopeIntersector using specified polytope in MODEL coordinates.*/ PolytopeIntersector(const osg::Polytope polytope); /** Construct a PolytopeIntersector using specified polytope in specified coordinate frame.*/ PolytopeIntersector(CoordinateFrame cf, const osg::Polytope polytope); You can pass an arbitrary Polytope which does not have to be rectangular. To recapitulate : I am trying to build a polytpe intersector from one 3d point in model space (or world space) and it's orientation. I would prefer this polytope intersector to be independent from the cameras or viewports. I am stuck at this point. Am I assuming something wrong? Did I miss something that could make this simpler? Do you have any clue that could help me? Am I even making sense? :D Try using one of the contructors above with a polytope that you provide and use the MODEL coordinate frame. That should work. Thank a lot, Sincerely, Julien-Charles Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is PolytopeIntersector a good choice for multiple selection?
Hi Neil,
Neil Clayton schrieb:
Hi,
I've a scene with only a handful of Geodes (under 200).
If I wanted to detect which objects were selected within a 2D rectangle on screen (think clicking, holding, dragging out a rectangle over the view) - would a PolytopeIntersector be a good choice?
Code:
osgUtil::PolytopeIntersector *picker = new osgUtil::PolytopeIntersector(cf,
fmin(downX, lastX),
fmin(downY, lastY),
fmax(downX, lastX),
fmax(downY, lastY));
osgUtil::IntersectionVisitor iv(picker);
view-getCamera()-accept(iv);
if(picker-containsIntersections()) {
// do stuff
}
I ask because I've tried (using the above) - where downX/Y are filled in on
mouse down - and as soon as the selection encompasses a number of geodes it
really slows down, considerably (I'm doing this every time the mouse position
changes, e.g: ::DRAG). I suspect I'm doing something wrong / using the
polytope incorrectly perhaps?
The main problem with PoltopeIntersector is that it generates large
amounts of result data if it is used with large picking volumes.
The typical usage (as shown in osgkeyboardmouse example) is
picking small volumes where only a handful of picks occur.
But you are not the first one that tries to use it with larger volumes...
Any pointers?
One possible optimization I can think of is changing the result
data structure in such a way that it only stores the intersecting
node-path and the first intersecting primitive. This data should
be enough for your usage pattern. The detailed result data could
be generated in an extra step (at a cost).
I'm considering using a nodemask to only examine the few things I need to test
for (ends up being about 12 quads). But wondering if I'm doing things
incorrectly from the outset...
Using an invisible (via nodemask) picking geometry is certainly an
option.
Cheers,
Neil
Cheers,
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] IntersectVisitor does not recognize Nodes on different Projection
Hi Thorsten, Thorsten Werner schrieb: Hi, OK. Thank you. Got it working now. Changed setProjectionMatrixOrtho2D into setProjectionMatrixOrtho. Next problem that i have is that the Buttons in my SceneGraph consist of several geometries and the Button is a Geode but its not recognized as Geode. Only as several Geometries. I dont know how to solve this. After going through the API i found Geode-setNodeMask. Could this help maybe? Ive no idea what a nodemask is though... If you are looking for the Geode you can use the nodePath field of the Intersection result which contains the complete path leading to the hit geometry. NodeMasks are basically bitmasks that can be used in the context of intersection testing. You can set them using Node::setNodeMask() and search for Nodes matching a NodeMask using osgUtil::IntersectionVisitor::setTraversalMask(). But even using this method you still have to look in the NodePath to find your geode... Thank you! Cheers, Thorsten Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] IntersectVisitor does not recognize Nodes on different Projection
Hi Thorsten, Thorsten Werner schrieb: Hi, I've got a loaded model which is a child of the root. the second child of the root node is a ortho2d projection, which i use for the GUI. Now i've taken the example osgkeyboardmouse from the osg site and my problem is that it only catches intersections with the loaded model. Not with the Goedes which are at the Ortho2D ProjectionMatrix. double w(.05), h(.05); osgUtil::PolytopeIntersector* picker = new osgUtil::PolytopeIntersector( osgUtil::Intersector::PROJECTION, x-w, y-h, x+w, y+h); osgUtil::IntersectionVisitor iv(picker); viewer-getCamera()-accept(iv); this is how i configured the Visitor. I've tried to change the Intersector into a osg::Intersector::WINDOW. ut then absolutely nothing happens anymore. What kind of primitives are you trying to pick? For Triangles/Quads it is more efficient to use the LineSegementIntersector (which is the default when you start osgkeyboardmouse, you can toggle using 'p'). The osgpick example always uses the LineSegementIntersector. Assuming you want to use PolytopeIntersector, I have to say that it not work well when Projections are involved. To fix that properly we might need a completely different approach. As a workaround you could try to call PolytopeIntersector on your (unprojected) HUD-Node directly and see if it helps. Thanks in advance. Cheers, Thorsten Cheers Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Hi, Paul Martz schrieb: Hi Robert -- The code submission by Wojciech and I for MSFBO has opened a small can of worms on declaring bits and bitmasks. I hope you can weigh in and put an end to the debate. Has anybody had a look at Qt's QFlags? http://doc.trolltech.com/4.5/qflags.html They provide a type-safe way of dealing with bit-mask-style enums. The implementation is mostly a template class with overloaded operators. Once you have the idea, it should be rather trivial to reimplement this from scratch and tailor it OSG's requirements. Cheers, Peter Originally, my submission followed the Optimizer's OptimizationOptions pattern of declaring bit values in an enum, but declaring the bitmask variable as an unsigned int. In Wojciech's modified submission, he changed the bitmask variable to a signed int, with the reasoning that enum values are also signed ints, and this eliminates the need for a typecast to get rid of compiler warnings. This caused me to weigh in with the workaround of declaring the bit values as static const unsigned int, and keeping the bitmask unsigned. But this goes against the OSG precedent set with the Optimizer. The ensuing discussion has covered the merits, or lack thereof (depending on the poster) of declaring bitmasks as signed or unsigned. What this really boils down to is: If we decide that the MSFBO bit/bitmask declarations should be different from the Optimizer pattern for bits and bitmasks, then we should change the Optimizer to follow the new standard, and also do the same for any other classes that followed the Optimizer's current pattern. If you could post with do it this way or do it that way, I (for one) could get back to work and stop prodding everyone with my code style opinions. :-) Thanks, -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Hi Chris, Chris 'Xenon' Hanson schrieb: Peter Hrenka wrote: Has anybody had a look at Qt's QFlags? http://doc.trolltech.com/4.5/qflags.html They provide a type-safe way of dealing with bit-mask-style enums. The implementation is mostly a template class with overloaded operators. Once you have the idea, it should be rather trivial to reimplement this from scratch and tailor it OSG's requirements. I'm not familiar with it, but I agree that perhaps a flags class/template would be a smart way to clean up the situation. If it would solve the issues. I know I'm always happier using a provided set/test API than manually masking stuff. As long as it doesn't bloat the data size beyond the simple storage of the flag word. as long as we don't make any of it virtual, I think it would be ok. Though I don't know how RTTI adds to the class per-instance weight of a real class (as opposed to a built-in type like unsigned long int). Any C++ guru care to comment on that? Nothing needs to be virtual here. It's just a template class with overloaded operators which means everything is effectively inlined. We could also use an unsigned int as internal storage type (Qt seems to use a signed int). Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change to Optimizer OptimizationOptions
Hi Chris,
Chris 'Xenon' Hanson schrieb:
Peter Hrenka wrote:
Nothing needs to be virtual here. It's just a template class
with overloaded operators which means everything is effectively
inlined. We could also use an unsigned int as internal storage type
(Qt seems to use a signed int).
But doesn't RTTI embed a hidden pointer (similr to the vftbl) into every
class as well,
that points to the common per-class ID/metadata?
Boy, you're paranoid. Well, sometimes that's a good thing ;-)
My understanding is that as long as you do not have virtual
methods or derive (directly or indirectly) from a class that
has virtual methods, there is no overhead in the memory layout
of the class instances.
But of course, I cannot guess what stange compilers will do...
The example programm gives me the following output on
64-bit gcc on Linux:
EnumSize: 4
EnumFlagsSize: 4
EnumFlagsArraySize: 40
PlainClass: 4
VirtualClass: 16
So the template class does not use more memory than the plain enum
(on this platform).
I guess quibbling about an extra pointer is very old-skool 80s coder of me.
You can have
my VIC-20 when I'm done porting OpenGL ES 1.0 to it! ;)
No, your concerns are valid. As you can see the virtual method adds a
factor of 4 in memory usage to the VirtualClass as compared
to the PlainClass in the example.
Cheers,
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
#include iostream
enum MyFlags {
ONE = (10),
TWO = (11),
TREE = (12)
};
templateclass enumType
class EnumFlags {
private:
unsigned int _flags;
};
class PlainClass {
void foo() {}
int _data;
};
class VirtualClass {
virtual void foo() {}
int _data;
};
int main(int argc, char* argv[]) {
std::cout EnumSize: sizeof(MyFlags) std::endl;
std::cout EnumFlagsSize: sizeof(EnumFlagsMyFlags) std::endl;
EnumFlagsMyFlags enumArray[10];
std::cout EnumFlagsArraySize: sizeof(enumArray) std::endl;
PlainClass p;
VirtualClass v;
std::cout PlainClass: sizeof(p) std::endl;
std::cout VirtualClass: sizeof(v) std::endl;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] support for kdtree in polytope intersector?
Hi Peter, Peter Amstutz schrieb: Has there been any work adding support for KdTrees to the PolytopeIntersector? A quick search of the mailing list came up with a discussion about a year and half ago but no indication if there has been any work since then. I know that the version of OSG I am presently using (2.9.5) doesn't support it. I did some work on PolytopeIntersector and I had look at the Kd-Tree implementation but it turned out to be tailored specifically to Triangles only. My application works with large point cloud data sets, on the order of hundreds of thousands of points in a single geode, and as a result doing a single mouse pick with the current naive polytope intersector takes on the order of 5-10 seconds to complete (in debug mode, fwiw). I would be motivated to add support for this to OSG if no one else has done so already. If you can split up your point cloud into multiple Geodes you should already see a speedup with PolytopeIntersector as it can take advantage of available bounding volume information. Still, I'd also like to see Kd-Tree support for PolytopeIntersector. I do not have much time to do this myself but I could offer some hints and perform testing if you choose to implement it. Cheers, Peter H. -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to improve frame rate of my scene with lots of cubes and cylinders?
Hi Maurizio, Maurizio Lodo schrieb: Hi, Thanks Peter for your very helpful reply. I have sorted that issue thank to your pointers. Now I have only one more question then I promise I won't bother you anymore. It seems that when I generate my model using the simple geometries I created and using VertexShader, the resulting cube, for example, has a very flat uniform colour, where it is impossible to distinguish the various faces. This does not happen when using the shapeDrawable cube or cylinder and so on. Would any of you mind pointing me in the right direction of how to resolve this? You need to provide normals to your geometry and enable light to achive the effect you desire. Thank you! Cheers, Maurizio Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector distance and Transform
Hi Andrew, Andrew Cunningham schrieb: Hi Peter, Did you ever work up a fix for this? ... I had a partial fix which helped as long as there is no projection involved. Unfortunately that is probably the main use-case... I think the proper way to do this involves storing the inverse matrices in the result- structure and back-transforming the intersection points before sorting. Right now I do not have much time to work on PolytopeIntersector, but if you want to fix it yourself I could describe my idea in more detail. It should not be hard (no hairy math involved). Thank you! Cheers, Andrew Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBOs and dynamic update problem
Hi J.P., Which version of OSG are you using? There has been a fix for VBO in Rev. 9362 which fixed some problems we encountered. But as you didn't attach the source I can't tell if this fix applies to your problem. Cheers, Peter J.P. Delport schrieb: Hi all, I'm having a problem updating Vertex Buffer Objects (VBOs) after creation. If I create geometry and use display lists everything is OK, but if I switch to VBOs I get strange results (looks like corrupted/missing data on the GPU). Attached is an example (modified osgcompositeviewer) that shows the issue. At first I need to determine if the same problem exists for other people. To test run e.g. ./test -s -d This uses display lists and should show what is expected. Press space in one of the windows to see that the spiral is growing. What I have issues with is ./test -s -v This switches to VBOs and initially the points I added before the first frame is shown correctly, but in my case if 'n press space the added spiral geometry is not shown. If one zooms in one can still see the original geometry though. The fact that one has to zoom shows that the bounding box of the geometry is updated correctly, but the vertices seem to go nowhere. Attached a screenshot of one window showing corrupted data. Any ideas/suggestions? Am I doing something silly? regards jp PS. If one uncomments the line //geometry_-getOrCreateVertexBufferObject()-dirty(); it seems that one of the views are updated OK when using VBOs, but not the other. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBOs and dynamic update problem
Hi J.P., J.P. Delport schrieb: Hi, Sorry for the missing info and attachment. Using OSG from svn rev 10424. System is Debian sid with NVidia drivers OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce Go 7400/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 185.18.14 First you must call dirty() on vertices_ and normals_ (otherwise the VBO will not be updated at all). But there is still a bug in the update of the VBO. Context 0 changes the _totalSize member of the VertexBuffer object and context 1 assumes its size is already changed... I have fix using glGetBufferParameteriv which I am preparing for submission. thanks jp Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector distance and Transform
Hi Andrew, Andrew Cunningham schrieb: Hi Peter, Although your fix did not work - it is definitely the scale part of the transform causing the problem. If I remove the scaling part of the transform , then the polytope picking works as expected ... Thank you for the example. It turns out that transforming the distance plane is not so straight-forward after all when scaling is involved. I'll try to work out the proper transformation for that case. Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector
Hi Maxime, Maxime BOUCHER schrieb: Hi, Just a question. The polytopeIntersections compute the intersections with planes or all objects in the Polytope? I mean if I draw the local intersection points will I get an empty or full shape of the polytope? The polytopeIntersector performs the intersection with the space volume defined by the polytope. So if a triangle lies completely inside the polytope (without intersecting the polytope's planes) it is still considered an intersection because it intersects the volume. I wonder because I tried a polytope with a single plane (to test), and I had a lot of points non coplanars... Yes, that is to be expected because you basically got all primitives lying in the half-space to one side of your plane. I also drawed it using intersection.localIntersectionPoint, which is the center of the primitive, isn't it? Almost ;-) No actually it is the center of all intersection-points. Say you have a triangle where two points lie inside the polytope-space and one point lies outside of this space. Than you have 2 intersection-points for the points lying inside, and 2 intersections points where the edges intersect the polytope plane(s). This gives you a total of 4 intersection points and the localIntersectionPoint is the centroid(barycenter) of those 4 points. Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector distance and Transform
Hi again Andrew, Andrew Cunningham schrieb: Hi, I am having some problems with the distance found by the PolytopeIntersector but only when the geometry I am trying to pick has a non-null (Matrix)Transform in it's parent. The PolytopeIntersector registers that object as a 'hit', BUT the distance recorded appears to be incorrect ( the end result is I end up 'highlighting' the wrong object behind the object I want to pick). The intersection calculation works perfectly (with the transformed object) but the distance to the reference plane (used for sorting the intersections) does not accurately reflect the expected distance. Just to re-iterate this. As long as I do not try to pick a node with a transform, the sorting of the PolytopeIntersector works as expected Using the LineSegmentIntersector on the same scene does not show the issue. It correctly sorts the intersections. Any ideas? I had another look at the code and found a nasty surprise in Plane::transformProvidingInverse(). There is a call to Plane::makeUnitLength() in it which should totally screw distance results of PolytopeIntersector if you have any non-orthogonal Matrix-Transforms (i.e. scaling). Could you try commenting out this line and check if it works for you? If it does help I will think of a proper fix. Thanks Andrew Cheers Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector
Hi Maxime, Maxime BOUCHER schrieb: Hi, I have a lot of questions for you! But, there is one really more critical than the others. Let me just introduce the problem :). (I am sorry if I bother, but I searched on the net, in the doc and examples and didn't find answers. I apologize if this is because I badly searched.) I want to cut my primitives along the frustum of a camera. 1) To do this I first have to get my planes equations. I have found a page dealing about this problem in OpenGL: http://www2.ravensoft.com/users/ggribb/plane%20extraction.pdf I think I'll use it, replacing in OSG conventions. I also found this: http://markmail.org/message/eeolcuruqpsbgrgu#query:osg%20frustum+page:1+mid:eeolcuruqpsbgrgu+state:results From famous Paul ;). Well, it draws the frustum, but it can be used to get the planes equations. (for whom it may interest) 2) Then I have my equations. Thus I can declare many osg::Plane. Question If the plane is a Vec4d (a,b,c,d) does it well represent the equation ax+by+cz+d = 0 ? The plane uses the above plane equation. (If you are familiar with projective spaces, the Vec4 can be seen as the projective normal in homogenous coordinates: (a,b,c,d) dot (x,y,z,w) = 0, where w=1 for affine points ) Note the the representation is only unique up to a factor (you can always multiply the equation with a factor != 0.0) I would like to use a PolytopeIntersector. In the doc it's written planes normals have to point the inside of the polytope. Question How are the normals set when the plane is initialized? The normal is given implicitly by the representation. Given the above equation, the normal is (a,b,c). You can easily change the direction of the plane normal unsing its flip()-method. Question Is there any problem declaring a non-closed (also called opened) polytope? I don't mind about the far plane. No problem at all. PolytopeIntersector uses open polytopes internally when the geometry lies to one side of a plane. 3) Once I have a polytope, I would like to intersect the polytope with the scene. Thus I declare a PolytopeIntersector I associate to an IntersectionVisitor. The BIG Question How do I associate the IntersectionVisitor to a model? I saw for a LineIntersector it is possible to associate it to a view via computeIntersections(), but it doesn't seem possible to do the same with polytope. You call the method accept(osg::NodeVisitor) of your model (which is a osg::Node). See the example osgkeyboardmouse. 4) Question Having the intersected points, is it possible to easily get the primitive or do I have to use this (it is in french, sorry): http://www.enseignement.polytechnique.fr/profs/informatique/Philippe.Chassignet/03-04/INF_431/td_16.html (exercise 4) This exercise is about polygons not polytopes! As for the PolytopeIntersector: It will give you all points, lines, triangles and quads which truly intersect the polytope volume, given by the primitive index. Thank you a lot! Cheers, Maxime Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector
Hi Maxime, Maxime BOUCHER schrieb: [...] Peter Hrenka wrote: You call the method accept(osg::NodeVisitor) of your model (which is a osg::Node). See the example osgkeyboardmouse. My bad, I should have seen it. We certainly need an osgpolytopeintersector example... Meanwhile grep is your friend. Peter Hrenka wrote: This exercise is about polygons not polytopes! Yes, I meant testing this way for each primitive. Well... I fail to see an analogy here. The point of Polytopes is that they are convex which makes all kinds of tests very easy. If you want to modell something non-convex (something like Constructive Solid Geometry) then PolytopeIntersector will not help you as it is. Peter Hrenka wrote: As for the PolytopeIntersector: It will give you all points, lines, triangles and quads which truly intersect the polytope volume, given by the primitive index. Sorry, I'm not sure I really understand. It is possible to get the intersected triangle instead of just a list of intersections coordinates? The struct PolytopeIntersector::Intersection contains a int-member primitiveIndex which probably is what you want. There is code to output the primitiveIndex in the osgkeyboardmouse example. You can access the first intersection with PolytopeIntersector::getFirstIntersection() or the set of all Intersections with PolytopeIntersector::getIntersections(). Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking Problem PolytopeIntersector
Hi Jean-Sébastien,
Jean-Sébastien Guay schrieb:
Hello Matthias,
[...]
Another difference, the line segment intersector orders objects by their
distance (closest intersection first), but the polytope intersector
doesn't (it would be pretty hard to implement even an approximation, and
even that would be slow - the polytope intersector is slow enough as it
is).
I'd like to correct you on that one. Let me quote PolytopeIntesector:
/** set the plane used to sort the intersections.
* The intersections are sorted by the distance of the
* localIntersectionPoint and the reference plane.
* The default for the reference plane is the
* last plane of the polytope.
*/
inline void setReferencePlane(const osg::Plane plane) {...}
We use this for point and line picking and only have to check
the first (few) intersections.
So you see, the two types of intersectors lend themselves naturally to
different applications. Hope this helps,
J-S
Regards
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking Problem PolytopeIntersector
Hi Matthias, Matthias Asselborn schrieb: Yes it is. First my SceneGraph has a a root ( osg::Group ). The Root contains few transform nodes under one transform nodes is one node, a model added by a loader. now i want to click on a object on the screen. and i want to get a pointer of this object by picking! the example in the book is done with the PolytopeIntersector but it doesnt work accurately i get a node when i clicked on a empty place in the scene or i clicked on another node and i get a other node from the picker. Can you reproduce your problems with the osgkeyboardmouse example? It switches to use the PolytopeIntersector when you press 'p' once (actually it toggles). If you use a OSG loader you can pass your filename as first parameter to the executable. I have not read the quick start guide but I have some general remarks: - you can adjust the accuracy of the Polytope-Picking by the size of the polytope which is usually incorporated in the constructor arguments of PolytopeIntersector (see osgkeyboardmouse) - the PolytopeIntersector returns *all* intersections it encounters, and if you call getFirstIntersection() you will only get one. This may account for your getting the wrong node. ive tested the LineIntersector in OSG examples it works great but i get only points on the screen no nodes... Regards, Peter Hrenka -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Most efficient way to use osg::DrawElementsUInt?
Hi Jesper, Jesper D. Thomsen schrieb: Hi all, I'm developing an application where I have to create up to 1000 osg:geometry objects per frame during certain interaction modes. I'm using osg::DrawElementsUInt push_back() to define the geometry primitive sets, and this push_back() seems to be the primary bottleneck for my applications graphical performance. Is there a more efficient way to define the primitive sets than to fill a osg::DrawElementsUInt by push_back and add it to the geometry? This is currently bringing me down to about 1 second per frame, which is kind of a roadblock. You can use reserve() to pre-allocate the needed memory. After that push_back() will not perform any reallocations/copies until the limit is reached. regards, Jesper D. Thomsen Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Most efficient way to use osg::DrawElementsUInt?
Hi Jesper, Jesper D. Thomsen schrieb: Hi, and thank you. I naturally tried to use reserve() (but thanks for suggesting it) and this of course helped somewhat, but it still seems to be the primary bottleneck. I've changed most of the rest of the per-frame geometry generation code to use static arrays rather than std::vector and this caused a major speedup (factor 10 or more) of my own part of the code, but I'm still stuck with the push_backs on osg::DrawElementsUInt. Maybe there's just no faster way to do it, or maybe I'm just using OSG in a somewhat un-intended way. Jesper D. Thomsen Just some more ideas/comments: Are you testing a release build? Debug-Verions (especially on Windows) are known to have dramatically slower implementations. What profiling tool are you using? Sometimes the output is misleading and can point you in the wrong direction. As from my experience push_back() on an pre-reserved() vector should not be a performace issue. If you can spare the memory you could also try swap(), implementing your own double-buffering for your osg::DrawElements. Cheers, Peter From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Peter Hrenka [p.hre...@science-computing.de] Sent: Thursday, March 26, 2009 12:00 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Most efficient way to use osg::DrawElementsUInt? Hi Jesper, Jesper D. Thomsen schrieb: Hi all, I'm developing an application where I have to create up to 1000 osg:geometry objects per frame during certain interaction modes. I'm using osg::DrawElementsUInt push_back() to define the geometry primitive sets, and this push_back() seems to be the primary bottleneck for my applications graphical performance. Is there a more efficient way to define the primitive sets than to fill a osg::DrawElementsUInt by push_back and add it to the geometry? This is currently bringing me down to about 1 second per frame, which is kind of a roadblock. You can use reserve() to pre-allocate the needed memory. After that push_back() will not perform any reallocations/copies until the limit is reached. regards, Jesper D. Thomsen Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Quick Start Guide: picking example - memory leak?
Hi Cristian,
Christian schrieb:
hi, i'm new to OSG so i started with reading the Quick-Start-Guide.
In the last example of the book (Picking) heap memory is allocated in a memberfunction
which is being called in case of a certain mouseevent. A normal pointer (picker) and not
a smartpointer is used to reference it - wouldn't this yield to a memory leak, because,
at least, in application code i can't see any delete picker statement?
This code has no memory leak because the IntersectionVisitor
stores the picker as a ref_ptr internally (in a std::list of ref_ptr).
As the IntersectionVisitor itself is allocated on the stack it will be
deleted on exiting its scope and the PolytopeIntersector's refcount will
reach 0 and it will be deleted.
This is common idiom in OpenSceneGraph. When you know that you
will pass a newly created object to another object that will keep a
ref_ptr on it, you can allocate it as a plain pointer. This will
save 2 ref-count operations and saves a bit typing work. But when in
doubt (and when it is not performace-critical) it is better to use
ref_ptr.
Code:
// Perform a pick operation.
bool pick( const double x, const double y,
osgViewer::Viewer* viewer )
{
if (!viewer-getSceneData())
// Nothing to pick.
return false;
double w( .05 ), h( .05 );
osgUtil::PolytopeIntersector* picker =
new osgUtil::PolytopeIntersector(
osgUtil::Intersector::PROJECTION,
x-w, y-h, x+w, y+h );
osgUtil::IntersectionVisitor iv( picker );
viewer-getCamera()-accept( iv );
...
Another question i have is:
Why is it even necessary to create the PolytopeIntersector at heap and not
simply at the stack of the pick memberfunction, like done with the
IntersectionVisitor? As far as i understand this example, none object inside
the memberfunction has to store any value/state/node/etc. till a possibly next
call, all work is done within the call and the return value is only TRUE/FALSE;
so the memory cleanup could be done implicit with leaving the scope of the
memberfunction.
Thanks in advance,
christian
Cheers
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in VertexBufferObject::compileBuffer
Hi Robert,
I have been chasing a bug in our osg-based application where a color
change resulted in a broken geometry (which uses VertexBufferObjects).
The update of the VBO does not seem to work when copyAll is false
(i.e. total size did not change) and not all Arrays are modified:
VertexBufferObject::compileBuffer(State state) const
{
[...]
unsigned int offset = 0;
for(BufferEntryArrayPairs::const_iterator itr =
_bufferEntryArrayPairs.begin();
itr != _bufferEntryArrayPairs.end();
++itr)
{
const BufferEntryArrayPair bep = *itr;
const Array* de = bep.second;
if (de)
{
if (copyAll ||
bep.first.modifiedCount[contextID] !=
bep.second-getModifiedCount() ||
bep.first.dataSize != bep.second-getTotalDataSize())
{
// copy data across
bep.first.dataSize = bep.second-getTotalDataSize();
bep.first.modifiedCount[contextID] =
de-getModifiedCount();
if (copyAll)
{
bep.first.offset = offset;
de-setVertexBufferObjectOffset((GLvoid*)offset);
offset += bep.first.dataSize;
}
[...]
The offset variable is only updated when the particular Array
has changed. If only the second of two arrays changes it writes at
offset 0 (where the first array starts) so both arrays will have an
offset of 0.
I think a proper fix which also properly handles array
additions/removals would have to use free-lists (or some
other memory management scheme).
I can not think of a simple fix which still minimizes updates.
Regards,
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Florian Geyer,
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Prof. Dr. Hanns Ruder
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector and line width
Hi Aude, a.lagnier schrieb: Hi, I'm using osgUtil::LinesegmentIntersector to pick objects from my scene. It works all fine except Geode containing line geometry (with LineWidth stateset). But, I want to pick somes thick lines, how can I do? LinesegementIntersector cannot pick lines (or points). You can use osgUtil::PolytopeIntersector instead. Have a look at the osgkeyboardmouse example for example code. Thanks in advance! Aude Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Newbie]: PolytopeIntersector in WINDOW CoordinateFrame is not working as expected
Hi guys,
Karl Karsten schrieb:
Hello Jean-Sébastien,
it no big deal for me, coding around OpenSceneGraph is my hobby ...
... to keep a bit on track and good for my brain.
A made some other code to select geometry objects within a box.
The scenario is that I place 1.000 cows.osg (transform + scale) in a world cube
of 200,200,200.
Then I do an intersection for each cow with a given SelectionBoundingBox (max:
200,200,200).
For each node I do ... nodeBoundingBox.intersects(selectionBoundingBox); ...
This is very, very fast, 1sec for 1.000 cows.
But some nodes could be outside the selectionBoundingBox, because the box of
the node has an intersection with the SelectionBoundingBox and not the node
itself.
To be more accurate I made another try, using PolytopeIntersector
For each node I do ...
osg::Polytope polytope;
polytope.setToBoundingBox(selectionBoundingBox);
PolytopeIntersectorRef boxContent = new
osgUtil::PolytopeIntersector(polytope);
GroupRef group = new osg::Group;
getWorldGroup(group.get()); // own func. to get the node with the
transforms to the world position
IntersectionVisitorRef intersectionVisitor = new
osgUtil::IntersectionVisitor(boxContent..get());
group-accept(*intersectionVisitor);
osgUtil::PolytopeIntersector::Intersections intersection =
boxContent-getIntersections();
if (intersections.size())
{
...
This example computes me the exactly the nodes inside the box but it's slower.
I takes about 6-7minutes for the 1000 cows.
I expect that the most time is used in generating the result structure
which contains all primitives in the intersected volume (which is
probably not what you really need).
Bear in mind that primitives that are completely inside
the polytope are also considered to be intersections.
- Any idea to speed up this procedure?
Combine your two approaches: First check the planes of your
Polytope against the bounding volumes of your nodes.
Do not use intersect but check if the volume is
properly on the inner side of the plane. If this
test passes for all planes you don't need to generate
all the results.
If the bounding volume of the node is on the outer
side of any plane, there are no intersections.
If the bounding volume of the node intersects one of the planes
itself, use the polytope intersector for that node
to check for proper intersections.
- How can I use setDimensionMask(DimZero)? Is this faster? How put I then the
points of the nodes into the intersection algo?
This will only speed up things when you have only GL_POINTS(SPRITES) and
do not want intersections with lines/triangles/quads.
Many thanks for any kind of help.
Karl ...
=
-- Forwarded message --
From: Jean-Sébastien Guay [EMAIL PROTECTED]
Date: 18 Nov., 22:44
Subject: [Newbie]: PolytopeIntersector in WINDOW CoordinateFrame is not working
as expected
To: OpenSceneGraph Users
Hi Karl,
hey, you are a hero ... It's working, fine.
Glad I could help. Seems we're doing similar things... :-)
Do you have any experience in terms of performance when expanding a rect
(dragging like a rubberband) over a huge number of models (ex. hundreds or
thousands of cow.osg) and computing the intersection in a EventHandler
depending on mouse positions?
That's exactly what I'm doing, and it's pretty slow. Even compared to a
single LineSegmentIntersection without kd-trees, a relatively complex
geometric object takes a few seconds to be selected if I make a
box-selection that contains it all. If I make a smaller box it's faster
of course.
I'll be looking into using the kd-tree to do PolytopeIntersections in
the near future, to speed this up. Although, I've been having weird
results profiling this... It seems like STL operations
(additions/removals from STL containers) are taking a sizable amount of
time, even in release mode.
I had a look at that myself. Unfortunately the code and the
data structures in the kd-Tree implemenation are very much taylored
towards triangles only.
But since one of the use cases of the PolytopeIntersector is to
support picking points and lines I cannot re-use the existing
code easily. Still, I'd like to do it someday, but right now I
do not have much time...
J-S
--
Cheers,
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Florian Geyer,
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Prof. Dr. Hanns Ruder
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple parents, unique states and selective lights
Hi Andreas, Andreas Lindmark schrieb: Hi, I have a situation where I have Geodes with multiple parents. This means that the Drawables in the scenegraph might be rendered multiple times with different transforms depending on the node path to the root. The problem is that I need to be able to set a unique set of shader uniforms for the different rendered instancies of the same Drawable. What I want to do is to test the bounding sphere of the instance against that of the lights in the scene and set the uniforms based on this test. We do not use osg::Lights since we do not have to support fixed function pipeline, and the lights are stored in a separate datastructure in world space since light calculations is done in world space in the shaders. An idea that I have is to add a drawcallback to the Drawable. In the callback I use RenderInfo::getState to retrieve the state for that instance. State::getInitialInverseMatrix combined with State::worldViewMatrix would give me the world matrix. The world matrix is used to transform the bounding sphere of the drawable and it can then be used for intersection tests. Im not really sure how to set the uniforms at this stage though. As I understand (from stepping trough the code) it is to late to change/add a stateset. I suppose that it would be possible to inject some OpenGL code, but this make me think that there might be a better solution. Is there a better way of achieving what I want than the idea i outlined above? You could add the position dependend StateSet directly to the Transforms (in osg every osg::Node can have its own StateSet). You could do this in an updateCallback. By the way: What does initial means in State::getInitialInverseMatrix)? /Andreas Lindmark Regards, Peter Hrenka -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::ref_ptr difficulties
Hi Vincent,
Vincent Bourdier schrieb:
Hi all,
I'm making some function to modify graph after some operation, and so I
need to call some simple actions in functions.
The problem is about ref_ptr :
I need to do this :
osg::ref_ptrosg::Group mygroup;
[..]
mygroup = NULL;
[...]
To do that in a function, I use someting like :
addonstack(mygroup, NULL); //prototype is :
addonstack(osg::ref_ptrosg::Group caller, osg::Node* arg1);
which did this :
osg::ref_ptrosg::Node nd = dynamic_castosg::Node*(caller.get());
if(nd.get()){
nd =arg1;
But, the problem is that it doesn't change anything... I need, without
making some modifications in the addonstack prototype, a way to put the
ref_ptr to NULL .
Any idea ?
Thanks.
The addonstack function gets its own copy of the ref_ptr,
so it cannot modify the original ref_ptr.
To change the original ref_ptr you must change the signature to
addonstack(osg::ref_ptrosg::Group caller, osg::Node* arg1);
But the code above (with the ref_ptr called nd) will still not
work, since this is yet another copy of caller. You use the
reference caller directly, e.g.
caller = arg1;
Regards,
Vincent.
Hope this helps
Peter
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Florian Geyer,
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Prof. Dr. Hanns Ruder
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] polytopeIntersector
Hi Gianloca, Gianluca Natale wrote: Hi, I went deeply in debug into my code, and I discovered that the problem is in OSG v.2.2. Actually it returns the object with the shortest node path among those in the intersection vector. Was it a known bug? No, I do not consider this a bug. As a polytope has no concept of near or far the order of the result is actually arbitrary. Of course the method-name getFirstIntersection is misleading... To overcome this shortcoming I introduced the concept of ReferencePlane to the PolytopeIntersector which probably does what you want but my modifications did not make it into OSG 2.2. If you must use 2.2, you could try to take the PolytopeIntersector from the current OSG dev Release, rename it to MyPolytopeIntersector and use with 2.2. Thanks in advance Gianluca Peter -- creating IT solutions Peter Hrenkascience + computing ag Software Solutions Hagellocher Weg 73 phone +49 7071 9457 263 72070 Tuebingen, Germany fax +49 7071 9457 511 [EMAIL PROTECTED] www.science-computing.de -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersection with osgUtil::PolytopeIntersector
Daniel Moos wrote: Hi everybody Hi Daniel, I have a question about intersection. I try to intersect lines with the osgUtil::PolytopeIntersector class. This works fine. Now how can i get the picked line from the picked geometry? I want to have the two vertices from the picked line... I do have a version that has an enhanced Intersection structure. I'll try to submit that version today. Thanks a lot! Daniel Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- creating IT solutions Peter Hrenkascience + computing ag Software Solutions Hagellocher Weg 73 phone +49 7071 9457 263 72070 Tuebingen, Germany fax +49 7071 9457 511 [EMAIL PROTECTED] www.science-computing.de -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil::PolytopeIntersector finding the closest intersection
Hi Michele, Michele Bosi wrote: Hi all, my program needs to select some lines, since osgViewer-computeIntersections is unable to pick lines I switched to osgUtil::PolytopeIntersector which is able to do so. Unfortunately PolytopeIntersector seems unable to tell me the intersection points/lines from which I would determine the closest object that I actually picked (among all the other that intersect the picking volume). Am I missing something? hope so. In the current state the PolytopeIntersector does not store intersection points or primitive indices. I do have a version that does so, but it needs some cleanup before I am willing to submit it. Right now I do not have much time but I hope that can submit a version next week. To sum up, is there a way to determine the closest object picked by a osgUtil::PolytopeIntersector (actually not the closest object but the one which has the closest intersection)? Or, are there other ways to pick a line object? That's exactly what my enhancement of the PolytopeIntersector does. It uses a reference plane and sorts the intersections according to the distance to that reference plane. Of course there are other ways to pick lines: One could use cylinders or cones which surround the pick-ray for intersecting lines but this is not implemented within OpenSceneGraph (yet). Regards, Michele Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- creating IT solutions Peter Hrenkascience + computing ag Software Solutions Hagellocher Weg 73 phone +49 7071 9457 263 72070 Tuebingen, Germany fax +49 7071 9457 511 [EMAIL PROTECTED] www.science-computing.de -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
