RE: [osg-users] Saving/Loading QuickTime ImageStreams
ImageStreams aren't currently supported by the ive reader/writer. They safely cast to Image, so the plugin treats them according to the osg::Image interface. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Weitz, Andrew C. Sent: Friday, July 13, 2007 1:05 PM To: osg users Subject: [osg-users] Saving/Loading QuickTime ImageStreams Hi, I'm using the QuickTime plugin to create a video texture. I'm having trouble saving/loading the video texture to/from an IVE file. The save process seems to work correctly. But when I load the IVE file, all I see is a single video frame. When I try to cast the loaded osg::Image to an osg::ImageStream, it fails. Does anyone know if it's even possible to do what I'm trying? Thanks, Andrew ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Get elements of osg::Matrix
osg::Matrix defines operator()(int row, int col) that you can use to extract specific entries. Row and column are zero based indices 4. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Catherine Peloquin Sent: Wednesday, July 11, 2007 11:49 AM To: osg users Subject: [osg-users] Get elements of osg::Matrix How does one get specific elements of an osg::Matrix? I need to write a transformation matrix to a .txt file, but cannot figure out how to access each element to write it. Does anyone have any suggestions? Thank you, Catherine Peloquin ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] IntersectionVisitor
You could inherit from the stock IntersectVisitor and implement getEyePoint et al. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lionel Lagarde Sent: Tuesday, July 10, 2007 8:35 AM To: osg users Subject: Re: [osg-users] IntersectionVisitor Thanks for the quick answer. mea culpa I've look at the intersection visitor code after sending the mail /mea culpa So, I'll stay with the old IntersectVisitor. Paul Martz wrote: So, how can it handle LODs ? If you would take a look at the IntersectionVisitor code, you'd see that IntersectionVisitor overrides apply(LOD), but the code is identical to apply(Group). So that should answer your question. Presumably, it overrides apply(LOD) because Robert intends to do something different with LODs in the future. But for now it just treats them like Groups. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] IntersectingBillboardswithosgUtil::IntersectionVisitor
Hi Daniel, I guess that the point_rot_eye stuff also depends on what your definition of Up is. We use a coordinate system where 0 rotations leave the camera looking down the x axis, y is to the left, and z is up. If you're orientations match OpenGL's, with -z forward, x right, and y up, then that's fine as well, and the eye_local and eye_pos will also be enough. Otherwise, this line in the POINT_ROT_EYE code will get ya ---Vec3 up(modelview(0,1), modelview(1,1), modelview(2,1)); Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Daniel Trstenjak Sent: Friday, July 06, 2007 1:45 AM To: osg users Subject: Re: [osg-users] IntersectingBillboardswithosgUtil::IntersectionVisitor Hi Chase, I just kind of threw it out there as a Here's what I did for my situation. No charge from me :). If your billboards aren't using POINT_ROT_EYE, then you should be able to remove all of the view matrix stuff. Also in this case I think it's unnecessary. Looking at the implementation of 'BillBooard::computeMatrix', the whole computation is done by the given eye_local and pos_local, the resulting transformation is then premultiplied by the given matrix. I don't want to be pedantic, just trying to find my problem. Regards, Daniel -- 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@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Intersecting BillboardswithosgUtil::IntersectionVisitor
Hi Daniel, Your right, in most cases the model matrix will be adequate. When I implemented that visitor, I was trying to make it intersect billboards using POINT_ROT_EYE mode, which assumes that computeRotation caller is passing a model view matrix in the form used by the CullVisitor. This made me add the view matrix kludge that circumvents the clone() operations. I'm pretty sure that my implementation also breaks a number of other use cases, such as graphs with camera nodes, so it's not usable in general. I just kind of threw it out there as a Here's what I did for my situation If your billboards aren't using POINT_ROT_EYE, then you should be able to remove all of the view matrix stuff. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Daniel Trstenjak Sent: Thursday, July 05, 2007 9:24 AM To: osg users Subject: Re: [osg-users] Intersecting BillboardswithosgUtil::IntersectionVisitor Hi Chase, I made a post a while back with a derived IntersectionVisitor which solves this problem. The post is named IntersectionVisitor with Eye/View information if you want to google for it. Thank you for your answer. But your version doesn't work for me. My problem might be somewhere else. I think it shouldn't be necessary to consider the view matrix during the computation of the billboard matrix. It should be enough to only consider the model matrix, because the view matrix is considered by the intersector (see e.g. LineSegmentIntersector::clone(IntersectionVisitor). Regards, Daniel -- Daniel Trstenjak Tel. +49 (0)7071-9457- 264 science + computing ag FAX +49 (0)7071-9457- 511 Hagellocher Weg 73 mailto: [EMAIL PROTECTED] computing.de D-72070 Tübingen WWW : http://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@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Intersecting Billboards withosgUtil::IntersectionVisitor
I made a post a while back with a derived IntersectionVisitor which solves this
problem. The post is named
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of Daniel Trstenjak
Sent: Wednesday, July 04, 2007 8:27 AM
To: osg-users@openscenegraph.net
Subject: [osg-users] Intersecting Billboards
withosgUtil::IntersectionVisitor
Hi all,
the current implementation (svn trunk) of
'IntersectionVisitor::apply(Billboard)'
is erroneous, because it ignores the transformation of the billboard.
So I tried to correct it by looking at
'IntersectionVisitor::apply(Transform)' and
'CullVisitor::apply(Billboard)':
void IntersectionVisitor::apply(osg::Billboard billboard)
{
if (!enter(billboard)) return;
osg::Vec3d eye_local = (! _modelStack.empty()
?
osg::Matrix::inverse(*_modelStack.back()).getTrans()
: osg::Vec3d(0.0f, 0.0f, 0.0f));
for(unsigned int i=0; ibillboard.getNumDrawables(); ++i)
{
const osg::Vec3 pos = billboard.getPosition(i);
osg::ref_ptrosg::RefMatrix matrix = _modelStack.empty() ? new
osg::RefMatrix() : new osg::RefMatrix(*_modelStack.back());
billboard.computeMatrix(*matrix, eye_local, pos);
pushModelMatrix(matrix.get());
push_clone();
intersect(billboard.getDrawable(i));
pop_clone();
popModelMatrix();
}
leave();
}
Unfortunately this version doesn't work. Any ideas?
Regards,
Daniel
--
Daniel Trstenjak Tel. +49 (0)7071-9457-
264
science + computing ag FAX +49 (0)7071-9457-
511
Hagellocher Weg 73 mailto: [EMAIL PROTECTED]
computing.de
D-72070 Tübingen WWW : http://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@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] Intersecting Billboards withosgUtil::IntersectionVisitor
Damn ctrl+enter send...
Daniel,
I made a post a while back with a derived IntersectionVisitor which solves this
problem. The post is named IntersectionVisitor with Eye/View information if
you want to google for it.
Chase
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of Daniel Trstenjak
Sent: Wednesday, July 04, 2007 8:27 AM
To: osg-users@openscenegraph.net
Subject: [osg-users] Intersecting Billboards
withosgUtil::IntersectionVisitor
Hi all,
the current implementation (svn trunk) of
'IntersectionVisitor::apply(Billboard)'
is erroneous, because it ignores the transformation of the billboard.
So I tried to correct it by looking at
'IntersectionVisitor::apply(Transform)' and
'CullVisitor::apply(Billboard)':
void IntersectionVisitor::apply(osg::Billboard billboard)
{
if (!enter(billboard)) return;
osg::Vec3d eye_local = (! _modelStack.empty()
?
osg::Matrix::inverse(*_modelStack.back()).getTrans()
: osg::Vec3d(0.0f, 0.0f, 0.0f));
for(unsigned int i=0; ibillboard.getNumDrawables(); ++i)
{
const osg::Vec3 pos = billboard.getPosition(i);
osg::ref_ptrosg::RefMatrix matrix = _modelStack.empty() ? new
osg::RefMatrix() : new osg::RefMatrix(*_modelStack.back());
billboard.computeMatrix(*matrix, eye_local, pos);
pushModelMatrix(matrix.get());
push_clone();
intersect(billboard.getDrawable(i));
pop_clone();
popModelMatrix();
}
leave();
}
Unfortunately this version doesn't work. Any ideas?
Regards,
Daniel
--
Daniel Trstenjak Tel. +49 (0)7071-9457-
264
science + computing ag FAX +49 (0)7071-9457-
511
Hagellocher Weg 73 mailto: [EMAIL PROTECTED]
computing.de
D-72070 Tübingen WWW : http://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@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] Bug: Autotransform and smallfeatureculling
You may want to try setting an initial bound on the auto-transform as well. I've run into problems in the past where the auto transform is culled because it begins with an invalid BSphere, making the culling visitor think it is small, so it gets skipped and the actual BSphere never gets computed. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, June 27, 2007 7:25 AM To: 'osg users' Subject: RE: [osg-users] Bug: Autotransform and smallfeatureculling This sounds familiar, I think I ran into it a while ago. If I remember correctly, we worked around it by disabling culling on AutoTransform children. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schmidt, Richard, SDGE1 Sent: Wednesday, June 27, 2007 5:08 AM To: osg-users@openscenegraph.net Subject: [osg-users] Bug: Autotransform and smallfeatureculling Hi, there is a bug when using the autotransform node in connection with small feature feature culling. We display icons on a globe using an autotransform node per icon. By default the icons scale/orient nicely when moving the camera. However when moving the manipulator into the home position, the icons get culled away. The problem is that the cullvisitor autotransform computes it's bounding box after computing the scale required to display the subgraph. Any ideas on that? Richard ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] OSGpagedLOD question
The LODs should be order from lowest to highest quality. The idea is to get something like: 1) 20KB lod : range = 200 to 1000 2) 100KB lod : range = 50 to 200 3) 5MB lod : range = 0 to 50 As you get closest to the center of the LOD, the pagedLOD node will make requests to load the next child. Because gaps aren't allowed in group nodes, all earlier nodes will be kept in memory up to the current. This means that the net memory usage for the above example would be 120KB when the second lod is visible and 5.12 MB when the highest LOD is visible. Also, if I'm interpreting the pager code correctly, none of the child LODs in a PagedLOD will get paged out until the PagedLOD is flagged as inactive. It looks as if the culling is used to set that flag, so unless the node is culled for one frame, it will remain inactive and keep all of its children paged in. This could cause problems if a lot of high quality children are ever paged in, but the PagedLOD node itself never gets culled. Even if only low quality children are visible, you'll still be paying the memory price on the higher LODs. Hopefully I'm wrong about that, and Robert can set me straight. Hope that helps, Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Alfero, Kristin Sent: Wednesday, June 27, 2007 2:43 PM To: osg users Subject: RE: [osg-users] OSGpagedLOD question Is there a certain way to set up the LOD's that go into the database? It seems that the LODs are taking up too much memory so when trying to load it crashes everything. I have more than enough memory and space to run the necessary database so that's not the issue. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, June 27, 2007 11:16 AM To: osg users Subject: Re: [osg-users] OSGpagedLOD question Hi Kristin, On 6/27/07, Alfero, Kristin [EMAIL PROTECTED] wrote: I have a question on the OSGpageLOD. I know that it is supposed to cut down on memory using the .ive files, but when I ran my database through it, it completely maxed out all 4 CPUs on my computer and all the memory. Is there something I can do to fix that? Do you mean your run the osgpagedlod example on your database? Or created a database using PagedLOD? The whole point of osg::PagedLOD and osgDB::DatabasePager is that they should help with enable the viewing of massive databases by paging it in rather than loading all in memory at once. If the database is poorly conditioned for paging then you won't get best results. In the case of the example its written to be an example of how to create and use PagedLOD nodes rather than something generally applied to databases, I wouldn't expect it work optimally - creating proper paged databases requires quite a bit of processing, well beyond the scope of simple example. W.r.t CPU's to get maxed out, how many screens/GPU are you using? Is vsync on? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Culling and performance scaling
To the best of my knowledge, osg has no real mechanism for determining if one node or subgraph completely occludes any other nodes. There's no way for it to know the geometry of a scene to detect holes, transparent sections of textures, or even per polygon depth checking without killing general performance. Per pixel depth checking is the graphics card's job. On the other hand, if you're willing to help it out and provide clues (perhaps you are sure that a wall is solid), then you can drop occluder nodes into the scene. Those help culling by allowing it to do simple ray tracing through the corners of the occluder and ignore nodes that fall entirely behind it from a given perspective. Emphasis on entirely though, otherwise we get back to the original problem of having to do effectively what the graphics card does on every frame. I don't have much experience with occluders, but I'm pretty sure that the gist of how they operate. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Paul Kahler Sent: Wednesday, June 27, 2007 6:29 PM To: osg-users@openscenegraph.net Subject: [osg-users] Culling and performance scaling I've been poking around on the OSG site and the mailing list and it's not clear to me how well OSG scales with geometric complexity (polygon count). I understand view frustum culling and back-face culling, but it's not clear to me if OSG can do more than that. For example, if I have an entire town modeled with terrain, buildings, furniture, under what conditions will OSG skip drawing a chair inside a room? Or more simply, what does OSG do to skip rendering objects obstructed by other objects? Speaking theoretically: back-face culling eliminates about 1/2 of all polygons. View frustum culling eliminates perhaps all but 1/4 of polygons in a large city viewed from the middle of town. From a time complexity standpoint this turns a O(n) problem where n is the number of polygons, into O(n/8) which is really just k*O(n) = O(n). A constant improvement but still linear. Does OSG do better? How? I understand that creating impostors and using LOD techniques can also improve performance, but my question is strictly in regard to methods that don't simplify geometry (i.e. culling). Thanks, Paul ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] performance of debug builds
Unless you need to step into the OSG code during debugging, you should be able to link your program against the release versions of OSG. You will have to modify the Runtime Library used by Code Generation to match what osg release uses (Multi-threaded DLL iirc), so you'll also lose some other assert notifications raised internally. However, you will be able to inspect your variables and achieve decent frame rates. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Stefan Kombrink Sent: Tuesday, June 19, 2007 9:13 AM To: osg users Subject: Re: [osg-users] performance of debug builds Well, thanks to everybody that helped in that thread, I will try the relwithdebinfo configuration another time. Last time the plugins didn't work in my app, but maybe I can find a workaround. The release builds seem to be the only way to get decent performance in my case. with regards, Stefan 8^) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] picking - what did I intersect?
The common solution here is to use node masks. What you do is disable bits on nodes that shouldn't respond to your particular type of intersection, then set the traversal mask on the intersect visitor so it has those bits. The only problem I've found with this is that it's hard to handle occlusions. In other words, if an uninteresting object is occluding an interesting object, and you use node masks to prevent intersecting against it, then the intersector could pass through the uninteresting object and still report a hit. Sometimes that's what you want though. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of sherman wilcox Sent: Tuesday, June 19, 2007 12:15 PM To: osg users Subject: [osg-users] picking - what did I intersect? I have some paged geometry that I'm trying to pick. I followed the osgpick example. This works just fine presently. However, what happens when I introduce other models to the scene? How do I distinguish between what I want to pick from the other geometry? The obvious way seems to be to name the nodes and cull away nodes that don't have the correct name. Problem is that my paged data isn't named. I suppose I could name the top-most node and walk the intersected data's parent list and see if I stumble across a parent with the correct name, but this seems like a terrible hack. Is there a more elegant way? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] performance of debug builds
Microsoft has no problems with doing a debug build that links against release versions of the crt libraries, or any library for that matter. The only time this poses a problem is when an application uses DLLs that link to different types of the same library, or when preprocessor defines like NDEBUG lead to header expansions that generate different method signatures. Usually, the DEBUG/NDEBEG macros aren't an issue, since the code they generate is inlined anyhow, but in some cases DEBUG will call methods that are undefined in the crt libraries (eg. heap debugging functions). In other words, there's no problem with making a debug build that uses release versions of osg, so long as it is consistent and only uses release versions of each of the osg libraries and crt. However, I wouldn't recommend getting into the habit of doing this, since it often leads to complicated build systems that are harder to maintain. As an example, opengl32 is a release library, but it works fine with debug builds because all of the modules that come together all use the same one. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Tuesday, June 19, 2007 12:00 PM To: osg users Subject: RE: [osg-users] performance of debug builds NO NO NO On Windows you should NEVER NOT mix Release and Debug libraries together, thanks to Microsoft this is simply not something you should do As to why this is in the OSG archives we covered this several times before on why you do NOT do this on windows... just Dont do it Best Regards Gordon __ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __ Telephone (Cell): (+1) 571-265-2612 -- Note New Number Telephone (Work): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bradford, Chase Sent: Tuesday, June 19, 2007 2:41 PM To: osg users Subject: RE: [osg-users] performance of debug builds Unless you need to step into the OSG code during debugging, you should be able to link your program against the release versions of OSG. You will have to modify the Runtime Library used by Code Generation to match what osg release uses (Multi-threaded DLL iirc), so you'll also lose some other assert notifications raised internally. However, you will be able to inspect your variables and achieve decent frame rates. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Stefan Kombrink Sent: Tuesday, June 19, 2007 9:13 AM To: osg users Subject: Re: [osg-users] performance of debug builds Well, thanks to everybody that helped in that thread, I will try the relwithdebinfo configuration another time. Last time the plugins didn't work in my app, but maybe I can find a workaround. The release builds seem to be the only way to get decent performance in my case. with regards, Stefan 8^) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Want to know how to get all of the vertexs of a model?
YangShiXing,
One method is to define a node visitor that stops on geodes, traverses the
geodes drawables, and adds the drawables to a vertex array. Below is an
example that only works with geometry drawables and Vec3Arrays (which are most
common I think).
I'm not positive that pointers are necessary for the Vec3Array without looking
at documentation.
Good Luck,
Chase
class VertexExtractor : public osg::NodeVisitor
{
public:
osg::ref_ptrosg::Vec3Array extracted_verts;
VertexExtractor() :
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
{
extracted_verts = new osg::Vec3Array;
}
void apply( osg::Geode geode )
{
// Cycle through all drawables, getting the vertex arrays from
geometries
// and adding those vertices to the member variable
extracted_verts
for( unsigned int i=0; i geode.getNumDrawables(); ++i )
{
osg::Geometry* geom = dynamic_castosg::Geometry(
geode.getDrawable(i) );
if( !geom )
continue;
osg::Vec3Array* verts = dynamic_castosg::Vec3Array*(
geom-getVertexArray() );
if( !verts )
continue;
// Add all of these vertices to my list of extracted
vertices.
extracted_verts-insert( extracted_verts-end(),
verts-begin(), verts-end() );
}
}
};
If my_model_node is the node you want vertices from, the do:
VertexExtractor ve;
my_model_node-accept(ve);
osg::Vec3Array* models_vertices = ve.extracted_verts-clone(
osg::CopyOp )
-Original Message-
From: [EMAIL PROTECTED] on behalf of ??
Sent: Sat 6/16/2007 3:05 AM
To: osg-users@openscenegraph.net
Subject: [osg-users] Want to know how to get all of the vertexs of a model?
Hi , I am sorry for my poor English, and I want to know how to get all of
the vertexs of a model , can you give me a tutorials~~ Best regards~
YangShiXing
winmail.dat___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] IntersectionVisitor with Eye/View information
Hey Robert,
After some investigation, I finally found a solution to our intersection
problems with the billboard nodes.
Below is my implementation of an intersection visitor that can give
feedback back to LOD nodes for proper active child traversal. This
implementation is only what serves our needs, and possibly breaks some
of the features that you've put in intersectors (such as proper
coordinate frame lookup). Nonetheless, I thought you might find it
useful if you have any plans to implement an intersection visitor that
can employ eye information for better interaction with LOD objects and
billboards that use the recent implementation of the POINT_ROT_EYE mode.
Regards,
Chase
#include osg/PagedLOD
#include osg/Billboard
#include osg/Transform
class LodIntersectionVisitor : public osgUtil::IntersectionVisitor
{
public:
LodIntersectionVisitor( const osg::Matrixd view, float lod_scale =
1.0, osgUtil::Intersector* intersector=0, ReadCallback* readCallback=0 )
: osgUtil::IntersectionVisitor( intersector, readCallback ),
lod_scale(lod_scale)
{
pushViewMatrix(new osg::RefMatrix(view));
eye = osg::Matrix::inverse(view).getTrans();
}
osg::Vec3 getEyePoint() const;
float getDistanceToEyePoint( const osg::Vec3, bool ) const;
float getDistanceFromEyePoint( const osg::Vec3, bool ) const;
void apply(osg::PagedLOD plod);
// Makes use of eyeposition information to produce a model matrix
and
// transform the intersector's space into the billboard's space.
void apply(osg::Billboard billboard);
private:
osg::Vec3 eye;
float lod_scale;
};
osg::Vec3 LodIntersectionVisitor::getEyePoint() const
{
// This code needs verification.
osg::Vec3 eye_point = eye;
if( getModelMatrix() ) eye_point = eye_point * osg::Matrix::inverse(
*getModelMatrix() );
return eye_point;
}
float LodIntersectionVisitor::getDistanceToEyePoint(const osg::Vec3
pos, bool with_scale) const
{
if (with_scale)
return (pos-getEyePoint()).length()*lod_scale;
else
return (pos-getEyePoint()).length();
}
float LodIntersectionVisitor::getDistanceFromEyePoint(const osg::Vec3
pos, bool with_scale) const
{
// Are getDistanceTo and getDistanceFrom really equivalent?
return getDistanceToEyePoint(pos, with_scale);
}
void LodIntersectionVisitor::apply(osg::PagedLOD plod)
{
// Treat PagedLODs as regular LODs, as the base apply() method for
// PagedLODs only acts upon the highest level of detail, regardless
of
// what is actually visible.
osg::LOD lod = plod;
osgUtil::IntersectionVisitor::apply(lod);
}
void LodIntersectionVisitor::apply(osg::Billboard billboard)
{
if (!enter(billboard)) return;
osg::Vec3 eye_local = getEyePoint();
osg::Matrixd model_view = getModelMatrix() ? *getModelMatrix() :
osg::Matrixd;
// ROT_TO_EYE mode expects a Model view matrix with something like M
= M1*M2*...*MN * View, so tack the view on
// before making the billboard compute its transformation. This
properly puts intersection data in the
// billboard's reference frame.
// getViewMatrix() is invariantly defined based on the rules of the
constructor.
model_view.postMult( *getViewMatrix() );
for(unsigned int i=0; ibillboard.getNumDrawables(); ++i)
{
osg::Matrixd bb_matrix(model_view);
const osg::Vec3 pos = billboard.getPosition(i);
billboard.computeMatrix( bb_matrix, eye_local, pos );
// Remove the view matrix from the model data.
bb_matrix.postMult( osg::Matrix::inverse( *getViewMatrix() ));
osgUtil::Intersector* intersector = getIntersector();
// Have to push the model matrix to ensure that the intersector
clone is properly placed into the
// Billboard's coordinate frame.
pushModelMatrix( new osg::RefMatrix(bb_matrix) );
// now push an new intersector clone transform to the new local
coordinates
push_clone();
intersect( billboard.getDrawable(i) );
// pop the clone.
pop_clone();
popModelMatrix();
}
leave();
}
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] Intersecting against Billboard
Hey Everyone,
I have a quad geometry attached to an OSG billboard configured with
axial rotation. I'm using a custom IntersectionVisitor that inherits
from the osgUtil::IntersectionVisitor and implements the getEyePoint,
getDistanceToEyePoint and getDistanceFromEyePoint using the same logic
as the CullVisitor. All other functionality in IntersectionVisitor is
the same.
The normal for the billboard with no rotation is 0, 1, 0, so the
bounding box for it is min = -5, -0.01, -5 max = 5, 0.01, 5. The
problem is that as I rotate around the billboard, the line segment never
gets transformed into the billboard's space. As a result, the
intersection is always incorrect unless the billboard is oriented to its
natural position.
I tried extending my IntersectionVisitor to have an
apply(osg::Billboard) that pushes the billboard's computed matrix, using
the eye position which is available to my visitor, but I can't seem to
get the code correct. I'm mostly guessing at how I should handle the
pushModelMatrix and pushClone methods, so maybe someone can tell me what
I'm doing wrong (efficiency aside)?
osg::Vec3 LodIntersectionVisitor::getEyePoint() const
{
// Const member access is not provided for get*Matrix for some insane
// reason, so cast away the const.
LodIntersectionVisitor* _this =
const_castLodIntersectionVisitor*(this);
osg::Vec3 eye_point = eye;
if( _this-getViewMatrix() ) eye_point = eye_point *
osg::Matrix::inverse( *_this-getViewMatrix() );
if( _this-getModelMatrix() ) eye_point = eye_point *
osg::Matrix::inverse( *_this-getModelMatrix() );
return eye_point;
}
void LodIntersectionVisitor::apply(osg::Billboard billboard)
{
if (!enter(billboard)) return;
for(unsigned int i=0; ibillboard.getNumDrawables(); ++i)
{
osg::ref_ptrosg::RefMatrix matrix = _modelStack.empty() ? new
osg::RefMatrix() : new osg::RefMatrix(*_modelStack.back());
billboard.computeMatrix( *matrix, getEyePoint(),
billboard.getPosition(i) );
pushModelMatrix(matrix.get());
// now push an new intersector clone transform to the new local
coordinates
push_clone();
intersect( billboard.getDrawable(i) );
// pop the clone.
pop_clone();
popModelMatrix();
}
leave();
}
Thanks,
Chase
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] osgProducer::Viewer - Window resize events
If this is for a Win32 application, the code in Producer (not osgProducer) that processes WM_SIZE events and triggers the callback to add the resize event to osgGA's event queue is currently commented out. When I uncomment it and rebuild Producer, mouse coordinate tracking gets messed up because the coordinates are normalized inside the Producer event processor and again in the osgGA, but as long as a resize event is never dispatched, osgGA assumes the window is a 1x1 screen. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, June 04, 2007 3:54 AM To: osg users Subject: Re: [osg-users] osgProducer::Viewer - Window resize events Hi Tommes, Producer does not generate resize events, it catches them internally and tracks. On each new frame you can query the window dimensions and do what you want with it. There are also some controls for the aspect ratio of the camera lens that you could try out. Alternatively you could look at the new osgViewer library, it does pass on window resize events that you can catch by attaching the event handling to the viewer. The Camera's on the window being resized will also be automatically be resized like in Producer, and there are also controls of how the projection matrix is adjusted on resize. Robert. On 6/4/07, Tommes [EMAIL PROTECTED] wrote: Hello, I need to handle window resize events in my application, which is based on osgProducer::Viewer. I want to avoid the viewer from automatically scaling the scene to fit in the new window (for example when toggling from fullscreen to window mode). What's the best way to do this? Where does Producer handle this event? Or is this done by the OS? Any advices appreciated. Tommes ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Collision detection
The BS tree that OSG uses for culling is accessible through the osg::Node-getBounds() method. For a node, N, N-getBounds() returns a minimal bounding sphere that holds all bounding boxes for drawables that are descendants of N. There are a few caveats to this though, with respect to AutoTransforms, LODs, and probably some other node types, where drawables' dimensions are adjusted as a function of the some other control, such as the eye. Raw bounding box information is not directly accessible through the interface provided by osg::Node. There was a topic that came up a few weeks ago where a NodeVisitor was used to compute a bounding box, so you may want to check that. If spheres are good enough, I'd recommend looking at getBounds() to see if that is adequate. As for the locality problem: trying to pair objects based off their spatial orientation is a high level task outside the scope of OSG. There might be an optimizer in the osgUtil library that can improve spatial organization, but I don't know of one since I haven't used them. Hope that help, Chase From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of The supervisor Sent: Wednesday, May 23, 2007 8:53 AM To: osg users Subject: Re: [osg-users] Collision detection i want to refine the question. We've been told , that when the cull function runs, it creates a BS tree which is similar to the tree we are willing to construct, if so , and the needed tree really exist, how can we find him and use him to help us do collision detection. On 5/23/07, Leo Vinnikov [EMAIL PROTECTED] wrote: We'd like to implement this structure, but if enough support already exists in OSG then it's better to use it. What is the best way, and what exactly does OSG provide to help us with this problem? On 5/23/07, Adrian Egli [EMAIL PROTECTED] wrote: Hi 2007/5/23, The supervisor [EMAIL PROTECTED]: Hello, We're trying to implement a Collision Detection algorithm. Our idea includes building a BB tree. It is a tree of hierarchies where the lowest hierarchy includes bounding boxes of the most basic objects in the scene. The one above includes BBs of pairs of BBs from below, and so on for all upper hierarchies. Note that while constructing the levels above, the pairs of the lower BBs must be chosen carefully, for the wrong choice will lead to a BB far larger than the BB that could be created by choosing BBs which are closer to each other. We've been told that a similar tree is being built in OSG for the purpose of culling. In order to help us build this tree we're searching for the source code of the function which does just that. If you could direct us to the right place in the source we'd be grateful. Alternately, if OSG provides access to his tree of this kind, how can we use it? i don't understand exactly what you need and like doing. Do you like to implement yourself a new structurs or do you like to expand the osg internal structurs to support hierarchical collision checks ? Many thanks. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] OSGA Plugin ignores CACHE_NONE option
Thanks a lot Robert. I understand why caching is necessary, it just seemed redundant to make both the plugin and the Registry responsible for adding archives to the cache. The archive count is a condition passed down from a higher processing step, which we don't really have much control over. As a result, we just need to make it work. My first guess for the access violation is that windows is imposing a limit on the amount of global space an application can use. That's a long shot guess though. I'd assume that even though the map's handle is on the global stack, its members would still be on the heap. Chase -Original Message- From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Thu 5/10/2007 1:15 AM To: osg users Subject: Re: [osg-users] OSGA Plugin ignores CACHE_NONE option Hi Brad, I have reviewed the code and added a options check into the .osga plugin. Could you do a svn update and see how you get on. W.r.t an archive adding itself to the cache, this is done so that future read calls can reference the cache without having to re-load it. The archive should be reasonably lightweight - its basically just a file index that you load, the actual models themselves are loaded on demand. Loading a compiling the index does take a little bit of time, so you don't want to keep loading the archive just to access one file from it. I'm suprised by two things, one that you have more than 508 archives in the first place, the idea of archives is that pack lots of files into a single archive so have small working set of archives at any one time, second that loading this many archives blows memory, it'd be interesting tracking down how much each loaded archive is taking, perhaps its being a bit inefficient somewhere along the line. Robert. On 5/9/07, Bradford, Chase [EMAIL PROTECTED] wrote: Hey Everyone, I've been working with some data that uses many osga files that hold PagedLODs, and I've found that if we ever exceed 508 osga files, subsequent calls to openArchive or readNodeFile fails. After some debugging, I've zeroed in on some issue where too many entries in the osgDB::Registry::archiveCache is causing Windows to generate a memory access error. I started setting the osgDB::Registry::Options objectCacheHint to CACHE_NONE, but the archive cache kept getting populated. It turns out that the osga plugin's readImage and readNode call addToArchiveCache directly regardless of the options used. When I comment out those line in the plugin code and use CACHE_NONE I can load all of my data with no issue. It seems like when caching is enabled, that call is redundant. Should the OSGA plugin really add itself to the cache? Thanks, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ winmail.dat___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] How do I get a Bounding Box for a model - notonederived from Bounding Sphere?
Robert and Paul Have either of you found a good way of writing a visitor for computing the bounding box that works on PagedLODs without children paged in? The only mildly acceptable method I've found is forcing a read on the first child then continuing traversal, but that's slow. I can also use the center and radius information when its available, but then I get bounding cubes. Chase From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, May 10, 2007 7:35 AM To: osg users Subject: Re: [osg-users] How do I get a Bounding Box for a model - notonederived from Bounding Sphere? Hi Mark and Paul, On 5/10/07, Paul Martz [EMAIL PROTECTED] wrote: Here's a bounding box NodeVisitor I've been using. It works well as long as all your Transforms are MatrixTransforms and all your Drawables are Geometry. Ooo difference type of answer to mine, looks like my speed reading to taking me off on a different tangent... BTW, there is now an osg::ComputeBoundsVisitor checked into SVN, see include/osg/ComputeBoundsVisitor, its been there for a month or two. Its addition came as part of the osgShadow work. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] OSGA Plugin ignores CACHE_NONE option
Hey Everyone, I've been working with some data that uses many osga files that hold PagedLODs, and I've found that if we ever exceed 508 osga files, subsequent calls to openArchive or readNodeFile fails. After some debugging, I've zeroed in on some issue where too many entries in the osgDB::Registry::archiveCache is causing Windows to generate a memory access error. I started setting the osgDB::Registry::Options objectCacheHint to CACHE_NONE, but the archive cache kept getting populated. It turns out that the osga plugin's readImage and readNode call addToArchiveCache directly regardless of the options used. When I comment out those line in the plugin code and use CACHE_NONE I can load all of my data with no issue. It seems like when caching is enabled, that call is redundant. Should the OSGA plugin really add itself to the cache? Thanks, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] const NodeVisitors
I'd appreciate a visitor framework that works on const nodes as well. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, May 09, 2007 3:35 PM To: 'osg users' Subject: [osg-users] const NodeVisitors Hi Robert -- I've just discovered I can't run a NodeVisitor from within a const member function or on a const Node. I have a custom node that needs to know when the bounding sphere changes so that it can run a NodeVisitor and compute a bounding box. As far as I know, the only way my node knows when the bounding sphere changes is to override computeBound() or add a compute bounding sphere callback. In either case, my node is const, which prevents me from calling apply() to run a NodeVisitor to compute the bounding box. My NodeVisitor doesn't change the structure of the scene graph or alter any data, it just collects info. So, I'm wondering if we might consider adding a constApply() method, declared as const, that would allow NodeVisitors to traverse the scene graph to collect data? If you have suggestions on how I can resolve this issue, I'd appreciate it. Perhaps I could compute my bounding box by computing the bounding sphere, then taking its radius and doing some algebra on it instead of running a NodeVisitor... Even if I do find a way to work around this, the concept of a const NodeVisitor seems like something that would have value. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] mouse picking problem
None of the below information applies to you, because Paul already
identified the issue, but I thought an explanation for bounding box
stuff might be useful. It's caused some bizarre behavior for us due to
special cases imposed by specific node types.
So, here goes...
Nodes keep track of their bounding boxes so that the information can be
reused on each cull phase. So, each node has a Boolean flag for
tracking it, and a BoundingBox member. Whenever a request to getBound
is made, the node will return the value of it's BoundingBox if dirty is
false, otherwise it recomputes it. You can force dirty to be set by
calling dirtyBound().
The computation method is virtual, so each node type does it
differently. In the case of groups, dirtyBound is called whenever a new
child is added, and during the compute process, the internal bounding
box is the bounding box for all children. Transforms also apply their
transformation to the BB. AutoTransforms always return the internal BB
regardless of the dirty state, since their bound can't be computed until
Cull Traversal; that's to take advantage of eye position. PagedLODs
work like normal groups, but if you call getBound() before any children
are loaded, the computed BB will be invalid. AutoTransforms and
PagedLODs have both caused trouble for me :)
Geodes traverse all their drawables and use the vertex information for
visible vertices to set its extents. So, if you add or remove vertices
after the bounds have been computed, you'll need to call setBound.
Billboards probably do something similar to AutoTransforms, but I'm not
exactly sure. I've never had to dig into their internals.
If you are ever worried about not getting a valid bounding box due to
problems raised by AutoTransforms and PagedLODs, you can use the
setInitialBound() method to explicitly set a bounding box, rather than
relying on the first call to computeBound to be successful.
Hope that clears stuff up.
Chase
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of alessandro
terenzi
Sent: Wednesday, April 18, 2007 7:03 AM
To: osg users
Subject: Re: [osg-users] mouse picking problem
Actually I don't call dirtyBound() at all...I do not modify my geometry,
so I guess I don't need that call, am I wrong? Anyway, since I'm new to
osg, I also tried to call that function just after I assign the pyramid
to the node representing the scene object, like this: (in the main...)
...
osg::ref_ptrosg::Node scene = createPyramid(50.0f, 50.0f);
scene-dirtyBound();
...
but I still have the same problem.
Maybe it is a stupid question, anyway I ask: am I supposed to
init/create in some way the bounding box of any geometry I create? I
mean, my createPyramid() function just creates some vertices and the
polygons that represent the pyramid faces, then it sets vertices colors
and texture cooridnates but it does nothing more than that...do I have
to compute the bounding box using some Node/Geode's method?
Thanks.
Alessandro
On 4/18/07, Andreas Goebel [EMAIL PROTECTED] wrote:
alessandro terenzi schrieb:
I cleaned up my code and here a simple example showing my problem:
...here's the handle method:
bool myEventHandler::handle( const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter aa )
{
osgViewer::Viewer* viewer = dynamic_castosgViewer::Viewer*( aa
);
if (!viewer)
return false;
switch( ea.getEventType() )
{
case osgGA::GUIEventAdapter::PUSH:
case osgGA::GUIEventAdapter::MOVE:
{
_mX = ea.getX();
_mY = ea.getY();
return false;
}
case osgGA::GUIEventAdapter::RELEASE:
{
if (_mX == ea.getX() _mY == ea.getY ())
{
if (pick( ea.getXnormalized(),ea.getYnormalized(), viewer
))
return true;
}
return false;
}
default:
return false;
}
}
...and here's the pick method:
bool myEventHandler::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);
if (picker-containsIntersections())
{
std::cout Found intersections...std::endl;
osg::NodePath nodePath =
picker-getFirstIntersection().nodePath;
unsigned int idx = nodePath.size();
while (idx--)
{
// look for osg::Geode object
osg::Geode* my_geode =
dynamic_castosg::Geode*(nodePath[idx]);
if(my_geode == NULL)
continue;
std::cout Picking successful...std::endl;
break;
}
}
else
{
std::coutPicking failed [no
RE: [osg-users] Can't build osgdb_pngd.lib from source
Hey Mark, The plugin libraries employ run-time linking and are loaded by the osgdb Registry when they are used, not at application startup. The other libraries that you see with the d.dll have associated .lib files for load-time linking, making them easier to build against since you won't need to worry about entry points and the use of LoadLibrary. A while back I saw a document on openscenegraph.net that details the work needed to link the osgdb plugins statically, but I can't remember it. If you want to see the explanation for why some dlls come with .lib files, the MSDN actually has a useful blurb. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc /base/dynamic_link_libraries.asp Chase From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark W Sent: Wednesday, April 18, 2007 2:11 PM To: [EMAIL PROTECTED] Subject: [osg-users] Can't build osgdb_pngd.lib from source Hey all, I'm attempting to build the osgdb_pngd.lib file from the osgPlugin png project. I'm working in visual c++ 2005 express edition (vc++ 8.0 basically). I'm compiling the project in debug settings. If I compile in static debug it will output osgdb_pngd_s.lib, but it does not output a .lib for any of the other build settings. The .dll's are also built normally. I'm guessing this might be a VC++ 8.0 question more than anything else... Can anyone tell me what might be going on? Thanks -Mark ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] LOD and file *.ive
It looks like your code is fine. Does the model appear correctly if you add it directly to the root and set the camera's position to 35 units from the root's center? Chase From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of christophe loustaunau Sent: Tuesday, April 10, 2007 8:45 AM To: osg-users@openscenegraph.net Subject: [osg-users] LOD and file *.ive Hello, I wan't to put an object read from a *.ive file into a LOD. First i have done a LOD with 3 sphere : no problems, then i put the object read from the file : nothing appears on the screens : the object and the sphere. here is a part of my code : . std::string file = earth.ive; osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFile( file ); osg::ref_ptrosg::LOD LOD ( new osg::LOD () ); LOD-addChild( sphere1.get(), 0.0f, 10.0f ); LOD-addChild( sphere2.get(),10.0f,20.0f); LOD-addChild( sphere3.get(),20.0f,30.0f); LOD-addChild( loadedModel.get(),30.0f,40.0f); root-addChild( LOD.get() ); . Maybe i can't do that because the object i read have already differents Level Of Detail. But i'm not sure, so if someone could tell me... Thanks a lot. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] osgUtil::SceneView cull() and draw() separated
I think you need to be careful not to make any major changes to the scene graph during the cull/draw cycle. If you can queue up changes from thread 2, so that thread 1 (the thread with sync, update and frame) processes all of them between calls to sync and frame, you'll be safe. The update callbacks that can be attached to nodes work this way. In the past, I've implemented a mutex controlled queue that gets populated with update callbacks by external threads and gets processed/cleared during the update phase of the thread 1. Chase -Original Message- From: [EMAIL PROTECTED] on behalf of Emmanuel Roche Sent: Thu 4/5/2007 2:34 AM To: OSG Users Subject: [osg-users] osgUtil::SceneView cull() and draw() separated Hello again, I have another question concerning multithreading issues: for example, is it possible to : 1) lock a scene graph in thread 1 2) perform cull() with a sceneView 3) unlock the graph 4) lock the graph in thread 2 5) modify somthing (could be anything: a nodemask, an osgText::Text color, an attitude, etc...) 6) unlock the graph 7) lock the graph again in thread 1 8) perform draw() with the previous sceneView 9) unlock the graph ... this is the whole story of my life in fact... So any explanation on why this is safe or unsafe would be really helpful :-) regards, Emmanuel. winmail.dat___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Window resize events + Mouse position
Hey Eron, The code inside Producer::RenderSurface_Win32 that used to dispatch that event is commented out (I'm not sure why). When I uncomment it, the mouse coordinates get messed up because producer normalizes them before dispatching the mouse event to the osgGA KeyboardMouse callback, and the osgGA event queue also normalizes them against the window dimensions. Since the window dimensions default to 1x1, the normalize calculation in osgGA::EventQueue is a no-op, unless it gets the window resize event and updates the window dimension (perhaps that's why the resize event is no longer dispatch?). Hope that convoluted explanation helps :p Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Eron Steger Sent: Thursday, April 05, 2007 12:17 PM To: osg-users@openscenegraph.net Subject: [osg-users] Window resize events + Mouse position Hello, I'm currently working with latest stable release of OSG (1.1), using osgProducer to render the scene. I would like to know if there is a way to determine when the window has been resized. I've tried handling the 'osgGA::GUIEventAdapter::RESIZE' event, but it doesn't appear to actually be called. Is this something that is (or planned to be) used in the SVN version with osgViewer? Also, when getting mouse events, it appears as though the maximum and minimum x/y positions are always 1 and -1. Is this different if you have multiple views of the same scene? Ideally I would like these coordinates to be in pixel space, but if that is no the intent I suppose I can still get the pixel using osgProducer::computePixelCoords. Thanks - Eron ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Performance issue with PagedLODs
Robert, By hierarchy of PagedLOD's, do you mean PagedLODs that have descendants that are also paged lods? Something like: scene_root-nodes-PagedLOD-nodes-PagedLOD I had thought about possibly setting up a scenegraph like that (mostly from a what-if perspective), but I couldn't think of a way to register the paged lods with the activePagedLod list in the database pager. I assume I would need to call registerPagedLods whenever a file is read from disk, but I don't know how to detect that. Is it possible? Thanks, Chase On 3/10/07, Robert Osfield [EMAIL PROTECTED] wrote: HI Glenn, When doing paging you should also aim to create a hierarchy of PagedLOD's not a flat structure. This also applies to LOD scene graphs, but do to the paging required its more important with PagedLODs as the paging itself will have t run for each group. One really needs to decide upon the granularity of your scene graph too, too fine and your trying to paging into too many separate tiles, too large and each tile will take too long to load into memory and to download to the GPU. Robert. On 3/9/07, Glenn Waldron [EMAIL PROTECTED] wrote: Hi, I was experimenting with the osgpagedlod example and ran into some strange behavior: I have a database that contains about 2500 buildings, each under its own LOD as the sole child with a range of 0-2 or so. No terrain, just buildings divided into groups of ~50 buildings each. There are no hierarchical LODs. This runs at a nice 60Hz. I then ran osgpagedlod --makeAllChildrenPaged on the database, ending up with a master file and 2500 subfiles as expected. When I fired it up, it would page in about one building every second. While data paged in, the stats showed an average cull time of about 750ms and a frame rate of 1.x fps. At first I though it was a texture sharing problem (all buildings have the same one texture) but I removed the texture file and the behavior is the same. Is there an issue with processing this many (non-hierarchical) PagedLOD's at a time? What accounts for the massive cull time? Thanks for an insight anyone can provide. -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com winmail.dat___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] bad_alloc in DatabasePager thread
Thanks Robert, I agree completely that handling memory issues should be performed by the application, not the pager. I just wanted to double check that the pager didn't already have an error reporting convention before I start hacking away at it. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, March 23, 2007 1:57 AM To: osg users Subject: Re: [osg-users] bad_alloc in DatabasePager thread Hi Brad, Adding a catch in osgDB::Registry might be something you could explore. A custom Registry::ReadFileCallback could allow you to do this without making intrusive changes to Registry or the DatabasePager. Generating an error message and returning NULL would be sensible. As for trying to add extra intelligence in DatabasePager to try and cope with out of memory conditions, I don't personally think that this is worth the effort, it'd add a lot of complexity and in the end will be always kicking a solid wall - the problem is still there, and stemming from elsewhere in the overall application/database set up. The problem without running out of memory really has fixed at a high level, you need to profile you app and database to find out why its running out of memory. Typically paged databases run at quite lower overhead as they are able to load balance, if you are running out of memory then something is wrong somewhere. Robert. On 3/22/07, Bradford, Chase [EMAIL PROTECTED] wrote: So, if something happens that causes a bad allocation, the database pager thread will die, because it doesn't handle the bad_alloc exception thrown by operator new. Unfortunately, all of the information you gave me about NULL return values is moot because unless new is called with a nothrow argument, you won't get a return value on a bad allocation. Would it be possible to make the pager report an error instead of unwinding out of run()? That way we make attempts to free. In most cases, I don't think insufficient memory would be catastrophic because if I had some way of knowing about the error, then I could pause the pager for a bit, free some cached objects, decrease cache sizes, force extra culling, etc, then make a second shot at loading models. If nothing else, I would at least be able to log the error before my application fails completely. Keep in mind From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Thursday, March 22, 2007 11:13 AM To: osg users Subject: RE: [osg-users] bad_alloc in DatabasePager thread The new will return NULL when ever a fail to alloc the memory and typically if your not catching this with a try/catch block or simple if Pointer = null test then your app may run until you use the pointer ( or it may not simply die) or you have bad allocs set to throw an exception in your compiler Typically in scenegraph a try and catch blocks are rearly used due to the over head they can introduce, so you paying Peter to rob Paul sort of thing, your shooting for speed and hit a bad alloc typically means you process/app is doomed at that point ( not always but mostly) Best Regards Gordon __ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __ Telephone (Cell): (+1) 214-477-8914 Telephone (Work): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bradford, Chase Sent: Thursday, March 22, 2007 12:49 PM To: osg users Subject: [osg-users] bad_alloc in DatabasePager thread Hi Everyone, I'm trying to find out what happens when the new operator fails in a reader plugin due to insufficient memory. I don't see any catches for std::bad_alloc, or std::exception even, so if something like that happens, will the call stack unwind until DatabasePager::run() is left? I'm assuming that there are some guards against a failure like that, but I don't see any, and I'm worried that it might cause problems for us given the size of the scenegraph we are trying to load. Thanks, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net
[osg-users] bad_alloc in DatabasePager thread
Hi Everyone, I'm trying to find out what happens when the new operator fails in a reader plugin due to insufficient memory. I don't see any catches for std::bad_alloc, or std::exception even, so if something like that happens, will the call stack unwind until DatabasePager::run() is left? I'm assuming that there are some guards against a failure like that, but I don't see any, and I'm worried that it might cause problems for us given the size of the scenegraph we are trying to load. Thanks, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] bad_alloc in DatabasePager thread
So, if something happens that causes a bad allocation, the database pager thread will die, because it doesn't handle the bad_alloc exception thrown by operator new. Unfortunately, all of the information you gave me about NULL return values is moot because unless new is called with a nothrow argument, you won't get a return value on a bad allocation. Would it be possible to make the pager report an error instead of unwinding out of run()? That way we make attempts to free. In most cases, I don't think insufficient memory would be catastrophic because if I had some way of knowing about the error, then I could pause the pager for a bit, free some cached objects, decrease cache sizes, force extra culling, etc, then make a second shot at loading models. If nothing else, I would at least be able to log the error before my application fails completely. Keep in mind From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Thursday, March 22, 2007 11:13 AM To: osg users Subject: RE: [osg-users] bad_alloc in DatabasePager thread The new will return NULL when ever a fail to alloc the memory and typically if your not catching this with a try/catch block or simple if Pointer = null test then your app may run until you use the pointer ( or it may not simply die) or you have bad allocs set to throw an exception in your compiler Typically in scenegraph a try and catch blocks are rearly used due to the over head they can introduce, so you paying Peter to rob Paul sort of thing, your shooting for speed and hit a bad alloc typically means you process/app is doomed at that point ( not always but mostly) Best Regards Gordon __ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __ Telephone (Cell): (+1) 214-477-8914 Telephone (Work): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bradford, Chase Sent: Thursday, March 22, 2007 12:49 PM To: osg users Subject: [osg-users] bad_alloc in DatabasePager thread Hi Everyone, I'm trying to find out what happens when the new operator fails in a reader plugin due to insufficient memory. I don't see any catches for std::bad_alloc, or std::exception even, so if something like that happens, will the call stack unwind until DatabasePager::run() is left? I'm assuming that there are some guards against a failure like that, but I don't see any, and I'm worried that it might cause problems for us given the size of the scenegraph we are trying to load. Thanks, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Overcoming osga 4GB limit ?
From what I've read about this problem, the limit on istream is
implementation dependant. To figure out what your limit is, use
sizeof(std::streamoff). I'm pretty sure the default is 8 bytes for gcc
3.4 and later. Visual Studio 8 uses 4 bytes for the 32 bit compiler and
8 for the 64 bit.
Chase
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of Alan Harris
Sent: Friday, March 16, 2007 11:38 AM
To: osg users
Subject: Re: [osg-users] Overcoming osga 4GB limit ?
Hi
It doesn't cure the limit problem, but when I was having crashes with
a
large database I modified the function:
ReaderWriter::WriteResult OSGA_Archive::write(const WriteFunctor
writeFunctor)
to have the following after the file write.
if (result.success())
{
addFileReference(position, size, writeFunctor._filename);
// ensure output file is correct to this point
writeIndexBlocks();
_output.flush();
}
The lack of index writes otherwise makes the database pretty useless
after a crash.
Cheers
Alan Harris
Zach Deedler wrote:
Hi Wojtek,
The limit for a process on win32 is 2GB. There are ways to up it to
3GB, though, if you haven't tried that.
http://msdn2.microsoft.com/en-us/library/ms791558.aspx
On 64-bit windows the process limit is 7,152GB
Zach
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of
*Wojciech
Lewandowski
*Sent:* Friday, March 16, 2007 06:01
*To:* osg users
*Subject:* [osg-users] Overcoming osga 4GB limit ?
Hi everybody,
We hit 4GB limit in OSGA archive generated from osgdem. Did anyone
try
building larger archives on 64 bit systems ? I suspect that 64 bit
Linux will be Ok but we work in Windows environment. Did anyone try
passing 4GB limit on 64 bit Windows ? Do I need to recompile OSG for
64 bit code ?
Does anyone know if there is a way to extract ive files from this
uncompleted 4GB OSGA archive ? OSGDEM have worked for 3 days till it
crashed at level 9 ... we would like to see if earlier levels look
right.
Thanks in advance for all feedback,
Cheers,
Wojtek Lewandowski
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] Vector cross product and operator precedence
-Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Eric Sokolowsky Sent: Friday, February 23, 2007 1:38 PM To: osg users Subject: Re: [osg-users] Vector cross product and operator precedence Gazi Alankus wrote: I recently discovered a bug in my code that made me question the choice of the operator chosen for vector cross product in osg. The bitwise xor operator (^) has a lower precedence than addition operator (+) in C++. So, addition is done before cross product, which is not intuitive and is not the case in mathematics. I decided to stop using the ^ operator for cross product, but I couldn't find a function version for it - the operator looks like the only choice. I know I can write one myself, but I just wanted to point this issue out since it probably will lead to bugs in many other people's code. My apologies if I'm missing something. In C++, the ^ operator is nothing more than an overloaded operator^() that takes the right arguments. Therefore, instead of writing: a ^ b You can write: operator^(a, b) And since function calls have a very high precedence (and the comma operator has a very low precedence) this might achieve your goal. Well likewise, you can make it explicit with something like (a^b) + c, but that doesn't solve the fundamental problem of doing what comes naturally and getting a different response. I've been bit by this before. I think Gazi brings up a good point. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Converting node types
It's not so much copying the children I'm worried about. It's ensuring that all other fields get copied, such as the StateSet, node mask, name, and all other member variables that accumulate through the inheritance tree. I'm worried that if I try to code the copying myself, then I might omit some key information. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, February 19, 2007 1:37 AM To: osg users Subject: Re: [osg-users] Converting node types Hi Chase, I'd create a new MatrixTransfrom and set its matrix up to the same value as the PositionAttitudeTransform then copy across the children. Rather than deep copy I'd recommend sharing as much as possible - ideally just adding the PAT's children directly to the MatrixTransform. Robert. On 2/18/07, Bradford, Chase [EMAIL PROTECTED] wrote: Hi Everyone, I was wondering if there is a safe technique for converting between node types. I would like to substitute all PAT nodes with MatrixTransforms, but I can't think of any elegant way of ensuring that all data defined in their common base (ie. Transform), gets copied in full. Essentially, I don't care about data specific to the PAT, other than the position and attitude, which is very easy to translate with special code. What I want is a way to deep copy all data that they both inherit from their common ancestors (descriptions, statesets, reference frame, etc.), then I can explicitly translate the info of interest from the PAT to the MatrixTransform. I'm sure C++ doesn't have any builtin ways of doing this, but I thought I might see if something like this has been added to OSG. Thanks, Chase Bradford ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Converting node types
Hi Everyone, I was wondering if there is a safe technique for converting between node types. I would like to substitute all PAT nodes with MatrixTransforms, but I can't think of any elegant way of ensuring that all data defined in their common base (ie. Transform), gets copied in full. Essentially, I don't care about data specific to the PAT, other than the position and attitude, which is very easy to translate with special code. What I want is a way to deep copy all data that they both inherit from their common ancestors (descriptions, statesets, reference frame, etc.), then I can explicitly translate the info of interest from the PAT to the MatrixTransform. I'm sure C++ doesn't have any builtin ways of doing this, but I thought I might see if something like this has been added to OSG. Thanks, Chase Bradford ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Node tag field
Hi Everyone,
I was wondering if it would be feasible to add a Referenced* member
variable to osg::Node in the OSG base that could be used for arbitrary
information tagging?
I'm currently developing a project where picking specific nodes in the
scene needs to trigger specific actions in our GUI, and building the
connections between the node and the GUI is quite difficult. The
application is broken down into a system where some classes (call them
Foos) own nodes, and changes to the nodes are triggered through the Foo
interface. When a specific node is clicked, I want to notify its Foo.
I've tried implementing this with event callbacks and global maps from
nodes to Foos, but both of those solutions seem overly cumbersome.
We modified our version of OSG to have a tag field in osg::Node. For
simplicity, we only fill this field with types based of OsgTag
(inherited from osg::Referenced), which is a class we defined just for
this problem.
To pull it off, we added this chunk of code to the end of osg::Node's
class description:
public:
void setTag( osg::Referenced* tag ) { _tag = tag; }
osg::Referenced* getTag() { return _tag.get(); }
const osg::Referenced* getTag() const { return _tag.get(); }
private:
osg::ref_ptrosg::Referenced _tag;
I think this is a small change that won't impact too many other aspects
of the library, but can be very powerful if used cautiously. Also, when
I would rather not change the OSG code if I can help it, and if it's in
future releases, I won't have to.
Thanks,
Chase Bradford
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] Culling Per Camera
It looks like the scene data is held by the SceneView, which the cameras don't know about. How can I tell a Producer::Camera to start drawing from a specific node in the scene graph, when it doesn't know anything about OSG? _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, January 03, 2007 10:49 AM To: 'osg users' Subject: RE: [osg-users] Culling Per Camera For your HUD camera, add a scene graph that is a top level Group with two children, the first child is your scene, and the second child is your HUD subtree. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bradford, Chase Sent: Wednesday, January 03, 2007 11:31 AM To: 'osg users' Subject: [osg-users] Culling Per Camera Is it possible to cull objects per camera? I want to add a HUD display to my scene that is only visible to a single camera. My idea was to make bit 16 in the node mask my HUD bit, then camera 1's mask would be all 0x and camera 2 would have mask 0x7FFF. The HUD would have the mask 0x8000. From what I can tell though, the cull mask is managed by the Camera Group, so the same mask is applied to all cameras. Does anyone know how to work around this, or have a better way of adding HUDs to the scene that are shown on specific cams? Thanks, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Possible bug in osgDB::Registry::ReadObject()
When computing an 'and' Boolean statement, the compiler will stop processing the condition as soon as the first false is found, since it will immediately cause the entire statement to be false. So, if rf == 0, then the second condition won't be evaluated. The same rule applies to 'or', if a true condition is found, the others are ignored and the conditional returns true. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Purvis Sent: Wednesday, November 29, 2006 9:40 AM To: osg users Subject: [osg-users] Possible bug in osgDB::Registry::ReadObject() Hi, While attempting to track down the oddity I posted earlier about loading GLSL programs from .osg files, I've been digging around the source for the .osg loading mechanism (It has taken a while but I think I've finally gotten my head around how the code works), I spotted what I believe to be a potentially fatal bug on line 890 of osgDB::Registry.cpp in the v1.2 source. The line and its previous read: [889] DotOsgWrapper::ReadFunc rf = mitr-second-getReadFunc(); [890] if (rf (*rf)(*obj,fr)) iteratorAdvanced = true; In the event the function pointer rf is set to NULL on line 889; I believe the if statement on the next line will cause a null pointer dereference. Should this not be written as: [890] if (rf) if ((*rf)(*obj,fr)) iteratorAdvanced = true; ...in order to protect from this problem? Alan. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Possible bug in osgDB::Registry::ReadObject()
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.pdf On page 90, look at 6.5.13, bullet 4 -Original Message- From: [EMAIL PROTECTED] on behalf of Alan Purvis Sent: Wed 11/29/2006 4:08 PM To: osg users Subject: Re: [osg-users] Possible bug in osgDB::Registry::ReadObject() Hmmn, are you sure? I would have though this an optional optimisation or perhaps an artifact of a specific compiler implementation. Does this old true across all compilers? I'm fairly sure I've learnt from past mistakes to create nested ifs in situations like this. I could be wrong though. On 29 Nov 2006, at 18:18, Bradford, Chase wrote: When computing an 'and' Boolean statement, the compiler will stop processing the condition as soon as the first false is found, since it will immediately cause the entire statement to be false. So, if rf == 0, then the second condition won't be evaluated. The same rule applies to 'or', if a true condition is found, the others are ignored and the conditional returns true. From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Alan Purvis Sent: Wednesday, November 29, 2006 9:40 AM To: osg users Subject: [osg-users] Possible bug in osgDB::Registry::ReadObject() Hi, While attempting to track down the oddity I posted earlier about loading GLSL programs from .osg files, I've been digging around the source for the .osg loading mechanism (It has taken a while but I think I've finally gotten my head around how the code works), I spotted what I believe to be a potentially fatal bug on line 890 of osgDB::Registry.cpp in the v1.2 source. The line and its previous read: [889] DotOsgWrapper::ReadFunc rf = mitr-second-getReadFunc(); [890] if (rf (*rf)(*obj,fr)) iteratorAdvanced = true; In the event the function pointer rf is set to NULL on line 889; I believe the if statement on the next line will cause a null pointer dereference. Should this not be written as: [890] if (rf) if ((*rf)(*obj,fr)) iteratorAdvanced = true; ...in order to protect from this problem? Alan. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ application/ms-tnef___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] LODs and releaseGLObjects
Hi Everyone, Ive been playing around with the osgviewer loading very large scenes that uses LODs. Ive noticed that after flying around the scene, forcing each LOD to load each of its children once, and then returning to my initial state, my frame rate drops to about 15% of its original. Im pretty sure its the textures using all of the graphics cards memory, because if I traverse the entire scene graph releasing all objects, the frame rate fixes itself. After looking at the code for LODs and PagedLODs, I cant determine when the GL objects for inactive children are released. Im sure there is a performance benefit to not immediately releasing them once a child is disabled, but I dont see how they are ever being released. Can someone explain how the LODs manage GPU resources that persist through frames? Thanks, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] LODs and releaseGLObjects
Unfortunately, the test path falls under common usage, so the performance is an issue. When the scene initially loads, the camera is far enough away from all of the models to only use the lowest quality LODs. If I'm using PagedLODs, then the draw times are a steady 30ms, because I'm still using the version that always loads all levels of detail before settling on the proper range. With regular LODs, the draw times are steady at 5ms until I fly around; then it goes to 30ms. If I forcibly release all the GL objects, the draw time returns to 5ms. How is a texture or drawable queued for deletion? Is it possible to set the expiry time for objects in the DatabasePager? Thanks for the info, Chase -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, November 10, 2006 7:17 AM To: osg users Subject: Re: [osg-users] LODs and releaseGLObjects Hi Brad, On 11/10/06, Bradford, Chase [EMAIL PROTECTED] wrote: I've been playing around with the osgviewer loading very large scenes that uses LODs. I've noticed that after flying around the scene, forcing each LOD to load each of its children once, and then returning to my initial state, my frame rate drops to about 15% of its original. I'm pretty sure it's the textures using all of the graphics card's memory, because if I traverse the entire scene graph releasing all objects, the frame rate fixes itself. Is this test of yours a path and speed that end users might take with the application, or is it your stress test? If you leave the camera at the start point for a while does framerate alter? There is a delay in the GL objects deletion when paging that is there to facilitate resue of texture objects, display lists. This should ordinarily improve performance. After looking at the code for LODs and PagedLODs, I can't determine when the GL objects for inactive children are released. I'm sure there is a performance benefit to not immediately releasing them once a child is disabled, but I don't see how they are ever being released. Can someone explain how the LODs manage GPU resources that persist through frames? LOD's don't know anything about OpenGL state, its a per cull mechansim. PagdLOD's are more complicated, although don't directly address state, their is an automatic child expriy mechansim. The DatabasePager has controls for how long no longer active children will kept around for. The osg::Texture and osg::Drawable headers also have functions for controlling how long OpenGl objects that have been queued for deletion and kept around. Any new osg::Texture's that look to create a new texture object can check this list first to see if it can reuse an existing texture objects. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] LODs and releaseGLObjects
Fair enough. Thanks for your explanation on the texture and drawable stuff. I think it will be enough for me to go on. It looks like attaching a cull callback to the expensive LODs that specially handles the GPU resources should suffice. Chase -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, November 10, 2006 8:27 AM To: osg users Subject: Re: [osg-users] LODs and releaseGLObjects Hi Chase, It sounds like you usage of forcing the loading of all LODs is probably the problem. Do you mean PagedLOD's here?I dont' quit what you mean by loading all levels of detail in the context of LODs on there own. Also forcing loading of all PagedLOD's is pretty well against the whole idea of PagedLODs. It really sounds to me that you need to pull pack from the way you are doing what you are doing and manage the scene graph in a way that doesn't overload the graphics hardware. Perhaps just using compressed textures would help? Perhaps using a texture atlas? There is plenty that you can do to keep things moving efficiently, and plenty of things you might be doing that are abusing things. I can't diagnose all these remotely and not on the time I have available for free support. Robert. On 11/10/06, Bradford, Chase [EMAIL PROTECTED] wrote: Unfortunately, the test path falls under common usage, so the performance is an issue. When the scene initially loads, the camera is far enough away from all of the models to only use the lowest quality LODs. If I'm using PagedLODs, then the draw times are a steady 30ms, because I'm still using the version that always loads all levels of detail before settling on the proper range. With regular LODs, the draw times are steady at 5ms until I fly around; then it goes to 30ms. If I forcibly release all the GL objects, the draw time returns to 5ms. How is a texture or drawable queued for deletion? Is it possible to set the expiry time for objects in the DatabasePager? Thanks for the info, Chase -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, November 10, 2006 7:17 AM To: osg users Subject: Re: [osg-users] LODs and releaseGLObjects Hi Brad, On 11/10/06, Bradford, Chase [EMAIL PROTECTED] wrote: I've been playing around with the osgviewer loading very large scenes that uses LODs. I've noticed that after flying around the scene, forcing each LOD to load each of its children once, and then returning to my initial state, my frame rate drops to about 15% of its original. I'm pretty sure it's the textures using all of the graphics card's memory, because if I traverse the entire scene graph releasing all objects, the frame rate fixes itself. Is this test of yours a path and speed that end users might take with the application, or is it your stress test? If you leave the camera at the start point for a while does framerate alter? There is a delay in the GL objects deletion when paging that is there to facilitate resue of texture objects, display lists. This should ordinarily improve performance. After looking at the code for LODs and PagedLODs, I can't determine when the GL objects for inactive children are released. I'm sure there is a performance benefit to not immediately releasing them once a child is disabled, but I don't see how they are ever being released. Can someone explain how the LODs manage GPU resources that persist through frames? LOD's don't know anything about OpenGL state, its a per cull mechansim. PagdLOD's are more complicated, although don't directly address state, their is an automatic child expriy mechansim. The DatabasePager has controls for how long no longer active children will kept around for. The osg::Texture and osg::Drawable headers also have functions for controlling how long OpenGl objects that have been queued for deletion and kept around. Any new osg::Texture's that look to create a new texture object can check this list first to see if it can reuse an existing texture objects. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Release 1.2 or current CVS?
Hi Everyone, My group is updating our OSG project, and we want to bring it up to date with the best version of OSG to date. So, should we use what is currently CVS or just release 1.2? We know there have been some changes to the library since September, but we arent sure of the risk vs. reward. Thanks Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Attaching an arbitrary callback to nodes.
Hi Everyone, I have a scenegraph that contains some elements that need to respond specially to clicks. The elements are usually composed of many nodes (geodes and transforms usually) are managed by classes which preserve handles to the scenegraph nodes to manipulate them directly. When one of these objects gets clicked, I need to notify the corresponding manager. I'm currently using a hack that associates the address of the osg Node that registers the intersect with the corresponding manager. This way, when the intersect visitor hits a node with the proper mask, I can use the map to activate the manager. I would prefer to attach a callback object (or any other sort of tag) that can notify the manager directly without the use of this map system. Also, I don't want to make this manager inherit from an existing node type because of issues with the visitor pattern. Thanks for any help, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Depth shadowing on large scenes
Ive been playing with the depth shadow demo quite a bit lately, and I tried extending it to a large scene built from many PagedLODs (20 or more models). The results have been pretty bad so far. To make the transition easy, I just create one texture and apply it to the entire scene, which causes a lot of stretching since Im limited to a 2048x2048 texture. As a result, areas that shouldnt be shaded are and vice versa. Is there an elegant solution that would allow me to use depth shadowing despite the texture size limitation? Im not worried about frame rates at this point. I just want to see a properly rendered scene. Thanks, Chase ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
