Re: [osg-users] Need help finding examples with osgUtil::LineSegmentIntersector and osgUtil::IntersectionVisitor
Nguyen Tien Dat wrote: Dear all, Which example in OpenSceneGraph 2.8.2 is using these classes? 22:36|me...@juggle2:~/c/osg/svn/trunk grep LineSegmentIntersector examples/*/*.cpp examples/osgcompositeviewer/osgcompositeviewer.cpp: osgUtil::LineSegmentIntersector::Intersections intersections; examples/osgcompositeviewer/osgcompositeviewer.cpp: osgUtil::LineSegmentIntersector::Intersection intersection = *intersections.begin(); examples/osgforest/osgforest.cpp:#include osgUtil/LineSegmentIntersector examples/osgforest/osgforest.cpp: osg::ref_ptrosgUtil::LineSegmentIntersector intersector = examples/osgforest/osgforest.cpp:new osgUtil::LineSegmentIntersector(tree-_position,tree-_position+osg::Vec3(0.0f,0.0f,size.z())); examples/osgforest/osgforest.cpp: osgUtil::LineSegmentIntersector::Intersections intersections = intersector-getIntersections(); examples/osgforest/osgforest.cpp: for(osgUtil::LineSegmentIntersector::Intersections::iterator itr = intersections.begin(); examples/osgforest/osgforest.cpp:const osgUtil::LineSegmentIntersector::Intersection intersection = *itr; examples/osgintersection/osgintersection.cpp:#include osgUtil/LineSegmentIntersector examples/osgintersection/osgintersection.cpp: osg::ref_ptrosgUtil::LineSegmentIntersector intersector = new osgUtil::LineSegmentIntersector(s, e); examples/osgintersection/osgintersection.cpp: osgUtil::LineSegmentIntersector* lsi = dynamic_castosgUtil::LineSegmentIntersector*(intersector_itr-get()); examples/osgintersection/osgintersection.cpp: osgUtil::LineSegmentIntersector::Intersections intersections = lsi-getIntersections(); examples/osgintersection/osgintersection.cpp: for(osgUtil::LineSegmentIntersector::Intersections::iterator itr = intersections.begin(); examples/osgintersection/osgintersection.cpp: const osgUtil::LineSegmentIntersector::Intersection intersection = *itr; examples/osgintersection/osgintersection.cpp: osg::ref_ptrosgUtil::LineSegmentIntersector intersector = new osgUtil::LineSegmentIntersector(start, end); examples/osgintersection/osgintersection.cpp: osgUtil::LineSegmentIntersector::Intersections intersections = intersector-getIntersections(); examples/osgintersection/osgintersection.cpp: for(osgUtil::LineSegmentIntersector::Intersections::iterator itr = intersections.begin(); examples/osgintersection/osgintersection.cpp:const osgUtil::LineSegmentIntersector::Intersection intersection = *itr; examples/osgkdtree/osgkdtree.cpp:#include osgUtil/LineSegmentIntersector examples/osgkdtree/raytrace.cpp:#include osgUtil/LineSegmentIntersector examples/osgkdtree/raytrace.cpp: osg::ref_ptrosgUtil::LineSegmentIntersector intersector; examples/osgkdtree/raytrace.cpp: osgUtil::LineSegmentIntersector::Intersections intersections; examples/osgkdtree/raytrace.cpp: osgUtil::LineSegmentIntersector::Intersections::iteratorisec_itr; examples/osgkdtree/raytrace.cpp:intersector = new osgUtil::LineSegmentIntersector(p, L); examples/osgkdtree/raytrace.cpp: osg::ref_ptrosgUtil::LineSegmentIntersector intersector; examples/osgkdtree/raytrace.cpp: osgUtil::LineSegmentIntersector::Intersections intersections; examples/osgkdtree/raytrace.cpp: osgUtil::LineSegmentIntersector::Intersections::iteratorisec_itr; examples/osgkdtree/raytrace.cpp:intersector = new osgUtil::LineSegmentIntersector(osg::Vec3f(), osg::Vec3f()); examples/osgkeyboardmouse/osgkeyboardmouse.cpp:#include osgUtil/LineSegmentIntersector examples/osgkeyboardmouse/osgkeyboardmouse.cpp: osg::notify(osg::NOTICE)Using LineSegmentIntersectorstd::endl; examples/osgkeyboardmouse/osgkeyboardmouse.cpp: osgUtil::LineSegmentIntersector* picker; examples/osgkeyboardmouse/osgkeyboardmouse.cpp:picker = new osgUtil::LineSegmentIntersector( osgUtil::Intersector::PROJECTION, ea.getXnormalized(),ea.getYnormalized() ); examples/osgkeyboardmouse/osgkeyboardmouse.cpp:picker = new osgUtil::LineSegmentIntersector( osgUtil::Intersector::WINDOW, mx, my ); examples/osgkeyboardmouse/osgkeyboardmouse.cpp: osgUtil::LineSegmentIntersector::Intersection intersection = picker-getFirstIntersection(); examples/osglauncher/osglauncher.cpp: osgUtil::LineSegmentIntersector::Intersections intersections; examples/osglauncher/osglauncher.cpp: for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr = intersections.begin(); examples/osgmovie/osgmovie.cpp: osgUtil::LineSegmentIntersector::Intersections intersections; examples/osgmovie/osgmovie.cpp:const osgUtil::LineSegmentIntersector::Intersection intersection = *(intersections.begin()); examples/osgmovie/osgmovie.cpp:
Re: [osg-users] Intersect.
Danny Lesnik wrote:
I'm trying to use intersect for primitive collision detection.
I load one 3DS file into my scene and test whether this object has any intersections. The problem is following: Although ,there is only one object in my scene, I can clearly see that this object intersects with something.
This is the code I'm using:
tankNode = osgDB::readNodeFile(c:\\3.3DS);
osg::Vec3d intersection;
osg::BoundingSphere bs = tankNode-getBound();
osg::Vec3 start = bs.center() + osg::Vec3d(bs.radius(),0.0,0.0);
osg::Vec3 end = bs.center() ;
osg::ref_ptrosgUtil::LineSegmentIntersector lsi = new
osgUtil::LineSegmentIntersector(start,end);
osgUtil::IntersectionVisitor iv(lsi.get());
tankNode-accept(iv);
if (lsi-containsIntersections())
{
intersection = lsi-getIntersections().begin()-getWorldIntersectPoint();
}
While I'm running this code in debugger,the values are following:
bs.center = (0,0,0);
bs.radius = 43.0
start = (43.0,0.0,0.0)
end= (0,0,0)
intersects = (12.5,0,0) and this is weird. Am I missing somthing?
It's not an unexpected result, actually. You shoot a line along the X
axis, so any intersection you're going to find is going to be (value, 0,
0) in this case.
Note that the bounding sphere is usually not very tight in OSG, so your
model might easily be intersected at X=12.5.
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersect.
Danny Lesnik wrote:
I just can't realize I have only one object its bs radius os 43. what is the object that I can intersect with on x =12,5?
There supposed to be nothing.
Thank you!
The only suggestion I have is to check out what is really going on by
writing a small OSG app that shows both your model and the bounding
sphere (using e.g. osg::Sphere and an osg::ShapeDrawable). Here, let me
do it for you :) (see attachement)
Paul
/* Show the bouding sphere for a given scenegraph
*
* Paul E.C. Melis (p.e.c.me...@alumnus.utwente.nl),
* August 2009
*
* g++ -g -o ob osgbound.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ -losg -losgDB -losgViewer -losgUtil -losgGA -losgText
*/
#include osg/PolygonMode
#include osg/Shape
#include osg/ShapeDrawable
#include osgDB/ReadFile
#include osgViewer/Viewer
class UpdateBoundCallback : public osg::NodeCallback
{
public:
UpdateBoundCallback(osg::Sphere* s)
{
sphere = s;
}
virtual void operator()(osg::Node *node, osg::NodeVisitor *nv)
{
osg::BoundingSphere bound = node-getBound();
sphere-set(bound.center(), bound.radius());
}
osg::ref_ptrosg::Sphere sphere;
};
int
main(int argc, char *argv[])
{
osg::ref_ptrosg::Node model;
osg::ref_ptrosg::Group root;
if (--argc != 1)
return 0;
model = osgDB::readNodeFile(argv[1]);
root = new osg::Group;
root-addChild(model.get());
osg::BoundingSphere bs = model-getBound();
osg::Sphere *sphere = new osg::Sphere(bs.center(), bs.radius());
osg::ShapeDrawable *shape = new osg::ShapeDrawable(sphere);
shape-setUseDisplayList(false);
model-setUpdateCallback(new UpdateBoundCallback(sphere));
osg::Geode *geode = new osg::Geode;
geode-addDrawable(shape);
osg::PolygonMode *polymode = new osg::PolygonMode;
polymode-setMode(osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE);
geode-getOrCreateStateSet()-setAttributeAndModes(polymode, osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON);
root-addChild(geode);
osgViewer::Viewer viewer;
viewer.setSceneData(root.get());
viewer.realize();
return viewer.run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersect.
Danny Lesnik wrote: Hi, I'm trying to use intersect for primitive collision detection. I load one 3DS file into my scene and test whether this object has any intersections. The problem is following: Although ,there is only one object in my scene, I can clearly see that this object intersects with something. Now that I reread your post I'm wondering if you misunderstand the LineSegmentIntersector, which has nothing to do with collision detection, per se. The LineSegmentIntersector does not test objects against each other, it tests if the line segment you specify intersects any of the polygons in the model you test against. And as you are shooting the line straight through the center of your model's bounding sphere you are very likely to get intersections. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersect.
Danny Lesnik wrote: Thank you for your help. I think I understand now what LineSegmentIntersector is doing. What might be the correct approach to test wether bounding sphere intrsect with any other project? That depends on how coarse/precise you want the intersections to be. Testing bounding spheres against each other is easy, but you might still need an acceleration structure to avoid testing every bounding sphere against every other (depending on the number of objects to test you will have). If you want to test a bounding sphere against a polygonal mesh then I'm not sure there is currently anything in OSG that will do that. Depending on how much stuff you want to write yourself to do this with the classes OSG provides you might want to look at existing collision detection libraries. For example, GIMPACT (http://gimpact.sourceforge.net/reference_html/index.html) might be of use for your case. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate three tagged
Laurens Voerman wrote: Paul Melis wrote: Jason Daly wrote: Paul Melis wrote: Okay, can you give me some pointers how to make it work then? I have VS8 sp1, have downloaded the corresponding debug package from the OSG website and have a really small test application that forces OSG to use some freed memory. If I build (in debug mode of course) and then run the test from VS with F5 it nicely catches the error, but in the stack trace none of the OSG dlls show any symbols... I think the problem is that OSG is using /Zi instead of /Z7, but at the same time, the .pdb files aren't being distributed in the packages. Right, that is what I originally suspected. So is there any point to the debug packages *in their current form*? As 2.8.2 is probably released pretty soon it might be a good point in time to fix this? My guess is that the extra size comes from optimizations being turned off (the default in Debug mode), but I don't make the packages, so I'm not sure. Is there any way to test for a given dll if there is debug information in it, e.g. with some MSVC tool? Paul Hi Paul, Heeej :) Does this help? %VCINSTALLDIR%\bin\dumpbin.exe /PDBPATH:VERBOSE osg55-osgd.dll Well, not really, as it merely seems to check if there is a .pdb file available that matches the given dll (which are not found for the dll's in the OSG debug package). However, the option /HEADERS produces more interesting results as it lists a Debug directories, which for osg55-osgd.dll refers to a .pdb file d:\Prog\Libs\OpenSceneGraph\bin\osg55-osgd.pdb. So that's probably the location on the original package creator's system (whoever that was). So this indeed seems to confirm that the dll's in the OSG VS8sp1 debug package on the website do not contain debug information for OSG itself, but can merely be used to build an application in debug mode. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate three tagged
Jean-Sébastien Guay wrote: Hi Paul, Right, that is what I originally suspected. So is there any point to the debug packages *in their current form*? Yes, they allow you to compile your own project in debug mode. They don't allow you to debug into the OSG itself, but otherwise they're required to get your own apps to compile and run in debug mode at all. Don't you just ha^H^H love windows... As 2.8.2 is probably released pretty soon it might be a good point in time to fix this? I'm not sure what the pdb files were not included (or the debug info was not embedded into the DLLs), but I would expect someone interested in debugging into OSG would have no problem compiling OSG themselves... If they want to debug into it, it's probable that they'll need to make a fix somewhere... And compiling OSG is pretty painless nowadays. But yes, we could either embed debug info or provide the pdb files (perhaps as a separate download for people who need it). Providing the .pdb's as a separate package might be a nice option, yes Is there any way to test for a given dll if there is debug information in it, e.g. with some MSVC tool? The only way I've seen is when debugging the app in Visual Studio it will say in the output window dll name (no debug information) or something like that. Then if you want to load the pdb file manually if you have it, you can go to the Modules window, right-click on the DLL and click Load Symbols. Same thing when you're stopped at a breakpoint, in the Call Stack window you can right-click on the grayed out lines and click Load Symbols. I don't know of a standalone tool that will tell you if a DLL contains debug info. See Laurens Voerman's reply for a step in the right direction Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate three tagged
Jason Daly wrote: Paul Melis wrote: Okay, can you give me some pointers how to make it work then? I have VS8 sp1, have downloaded the corresponding debug package from the OSG website and have a really small test application that forces OSG to use some freed memory. If I build (in debug mode of course) and then run the test from VS with F5 it nicely catches the error, but in the stack trace none of the OSG dlls show any symbols... I think the problem is that OSG is using /Zi instead of /Z7, but at the same time, the .pdb files aren't being distributed in the packages. Right, that is what I originally suspected. So is there any point to the debug packages *in their current form*? As 2.8.2 is probably released pretty soon it might be a good point in time to fix this? My guess is that the extra size comes from optimizations being turned off (the default in Debug mode), but I don't make the packages, so I'm not sure. Is there any way to test for a given dll if there is debug information in it, e.g. with some MSVC tool? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] infitec stereo
Garry Keltie wrote: Last weekend I had the pleasure of seeing Ice Age 3 in 3D. I highly recommend it not only for the animated hoot but the stereo effect is definitely the most comfortable I have seen in a cinema. I'm wondering if anyone knows much about the method? Has quite a few pluses to it. It's pretty much done with wheels and filters in the cinema but it strikes me that unless its protected with patents, might be an attractive method, with a bit of work, for commodity (non quad buffering) graphics. A quick trawl fished up some links below. http://en.wikipedia.org/wiki/Stereoscopy#Infitec_glasses http://www.dolby.com/uploadedFiles/zz-_Shared_Assets/English_PDFs/Professional/Dolby_3D_Digital_Cinema.pdf http://www.dolby.com/professional/motion_picture/technologies/dolby-3ddigital-specifications.html http://www.infitec.net/infitec_english.pdf Infitec has been around for some time now, I think I saw it at siggraph a couple of years ago. It is quite a nice method, but people seem to complain mostly about the slight differences in color between the eyes (due to the different spectra used). But the eye separation is much better than when using simple polarized glasses. Interesting how Dolby 3D uses a filter wheel in front of the normal cinema projector. That makes it easy to 'augment' existing digital cinemas with 3D capabilities. But I guess you need quite a stable rotation to not get out of sync. You could always use two projectors and give them a filter each, to get a conventional passive stereo set. I believe the Infitec stuff is cheaper than active stereo gear, but still not very cheap. I remember seeing somewhere that even the glasses were around E50,- per pair. I guess they didn't let you keep those after the movie? :) Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] infitec stereo
Paul Melis wrote: Garry Keltie wrote: Last weekend I had the pleasure of seeing Ice Age 3 in 3D. I highly recommend it not only for the animated hoot but the stereo effect is definitely the most comfortable I have seen in a cinema. I'm wondering if anyone knows much about the method? Has quite a few pluses to it. It's pretty much done with wheels and filters in the cinema but it strikes me that unless its protected with patents, might be an attractive method, with a bit of work, for commodity (non quad buffering) graphics. A quick trawl fished up some links below. http://en.wikipedia.org/wiki/Stereoscopy#Infitec_glasses http://www.dolby.com/uploadedFiles/zz-_Shared_Assets/English_PDFs/Professional/Dolby_3D_Digital_Cinema.pdf http://www.dolby.com/professional/motion_picture/technologies/dolby-3ddigital-specifications.html http://www.infitec.net/infitec_english.pdf Infitec has been around for some time now, I think I saw it at siggraph a couple of years ago. It is quite a nice method, but people seem to complain mostly about the slight differences in color between the eyes (due to the different spectra used). But the eye separation is much better than when using simple polarized glasses. Interesting how Dolby 3D uses a filter wheel in front of the normal cinema projector. That makes it easy to 'augment' existing digital cinemas with 3D capabilities. But I guess you need quite a stable rotation to not get out of sync. You could always use two projectors and give them a filter each, to get a conventional passive stereo set. Oh yeah, another advantage: at least you don't need a silver screen with infitec, as there's no polarization to preserve :) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] infitec stereo
Garry Keltie wrote: Hi, Last weekend I had the pleasure of seeing Ice Age 3 in 3D. I highly recommend it not only for the animated hoot but the stereo effect is definitely the most comfortable I have seen in a cinema. I'm wondering if anyone knows much about the method? Has quite a few pluses to it. It's pretty much done with wheels and filters in the cinema but it strikes me that unless its protected with patents, might be an attractive method, with a bit of work, for commodity (non quad buffering) graphics. BTW, in case you don't want to use quad-buffering you would still need to synchronize your image generation with the filter wheel. I suspect that might not even be that easy to accomplish. It would be easier (but not cheaper) to go for a quad-buffer setup with two projectors. Or, you could use a dual-output gfx card and set up your application to render over both outputs (xinerama style), using one eye per output. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate three tagged
Jason Daly wrote: Jean-Sébastien Guay wrote: Well the name old-style might also mean that there are drawbacks to using that option... I wouldn't know if the only effect is that the debug information is embedded instead of in a separate file. We develop with SCons (which uses the MSVC compiler on Windows), and we use the /Z7 option all the time, because it allows us to compile code in parallel without any worries of conflicts. With the normal /Zi option, you get conflicts when two or more processes are trying to write to the .pdb file at the same time. You can still make use of just-in-time and source-level debugging with the old-style debug info. I do it all the time. The only drawback that I know of is that the embedded debug info makes the final object (.exe or .dll) larger, and it might increase loading time a bit. Okay, can you give me some pointers how to make it work then? I have VS8 sp1, have downloaded the corresponding debug package from the OSG website and have a really small test application that forces OSG to use some freed memory. If I build (in debug mode of course) and then run the test from VS with F5 it nicely catches the error, but in the stack trace none of the OSG dlls show any symbols... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate three tagged
Paul Melis wrote: Jason Daly wrote: Jean-Sébastien Guay wrote: Well the name old-style might also mean that there are drawbacks to using that option... I wouldn't know if the only effect is that the debug information is embedded instead of in a separate file. We develop with SCons (which uses the MSVC compiler on Windows), and we use the /Z7 option all the time, because it allows us to compile code in parallel without any worries of conflicts. With the normal /Zi option, you get conflicts when two or more processes are trying to write to the .pdb file at the same time. You can still make use of just-in-time and source-level debugging with the old-style debug info. I do it all the time. The only drawback that I know of is that the embedded debug info makes the final object (.exe or .dll) larger, and it might increase loading time a bit. Okay, can you give me some pointers how to make it work then? I have VS8 sp1, have downloaded the corresponding debug package from the OSG website and have a really small test application that forces OSG to use some freed memory. If I build (in debug mode of course) and then run the test from VS with F5 it nicely catches the error, but in the stack trace none of the OSG dlls show any symbols... Just noticed the line Loaded '[...]\bin\osg55-osgd.dll', No symbols loaded. in the debug output in VS. The debug DLL is 5.4 Mb, while osg55-osg.dll from the release package is 1.8 Mb, suggesting that the debug DLL *does* contain extra information (I wouldn't expect that large a difference in code size alone). Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting System time, milliseconds
Robert Osfield wrote: Is it just that you need to multiple the number of seconds my 1000 to get milliseconds? This does seem a bit of trivial answer so I do wonder if your actually after something else. I guess the OP wants millisecond precision? Paul Robert. On Thu, Jul 16, 2009 at 7:05 PM, Kelly Fieldskelly.br...@jhuapl.edu wrote: Hi, I am new to Delta3d and have a question about getting system time (or local time - really any form of time). I am accessing time, but even though the seconds is a float, it does not contain information for milliseconds. How would I get that? Here is my code... dtUtil::DateTime time; time.SetTimeType(dtUtil::DateTime::TimeType::SIMULATION_TIME); time.SetToLocalTime(); double winTime = time.GetTimeInSeconds(); Please help!! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15043#15043 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting System time, milliseconds
Kelly Fields wrote: Yes, sorry - I need millisecond precision. So I need a number to be like 3.234 seconds rather than 3 seconds But aren't those methods you used from the Delta3D API? Are you sure these methods are in OSG? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting System time, milliseconds
J.P. Delport wrote:
In OSG you could do something like:
osg::Timer *globalHighResTimer=osg::Timer::instance();
uint64_t currentTimeNanoSec()
{
osg::Timer_t timer_t=globalHighResTimer-tick();
return (uint64_t)(timer_t *
globalHighResTimer-getSecondsPerTick() * 10);//timerTick *
secondsPerTick * secondsToNanoSeconds
}
This is win32-specific code right? There's no way you're going to get
nanosecond precision on e.g. Linux where gettimeofday() is used by
osg::Timer.
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting System time, milliseconds
Paul Melis wrote:
J.P. Delport wrote:
In OSG you could do something like:
osg::Timer *globalHighResTimer=osg::Timer::instance();
uint64_t currentTimeNanoSec()
{
osg::Timer_t timer_t=globalHighResTimer-tick();
return (uint64_t)(timer_t *
globalHighResTimer-getSecondsPerTick() * 10);//timerTick *
secondsPerTick * secondsToNanoSeconds
}
This is win32-specific code right? There's no way you're going to get
nanosecond precision on e.g. Linux where gettimeofday() is used by
osg::Timer.
Ok ok, it would give valid results on non-windows, but give a false
sense of nanosecond precision. And the OP needed only milliseconds...
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting System time, milliseconds
J.P. Delport wrote:
For Linux, play with this:
#ifndef WIN32
/// High resolution timers for Linux.
#define NSEC_PER_SEC 10LL
inline uint64_t timespec_to_ns(const struct timespec *ts)
{
return ((uint64_t) ts-tv_sec * NSEC_PER_SEC) + ts-tv_nsec;
}
/// Returns nanoseconds since epoch.
inline uint64_t currentTimeNanoSec()
{
struct timespec timestamp_ts;
//clock_gettime(CLOCK_MONOTONIC, timestamp_ts);
clock_gettime(CLOCK_REALTIME, timestamp_ts);
return timespec_to_ns(timestamp_ts);
}
inline uint64_t clockResNanoSec()
{
struct timespec timestamp_ts;
//clock_getres(CLOCK_MONOTONIC, timestamp_ts);
clock_getres(CLOCK_REALTIME, timestamp_ts);
return timespec_to_ns(timestamp_ts);
}
#if 0
int main(void)
{
printf(%lld, %lld\n, currentTimeNanoSec(), clockResNanoSec());
printf(%lld, %lld\n, currentTimeNanoSec(), clockResNanoSec());
}
#endif
#else
Interesting, I had compared different ways of doing timing on Linux some
time ago and was certain that clock_gettime() didn't work for me.
But now I tested it again it at least seems to provide enough precision.
Ah well, I'll probably never figure out what happened :)
Thanks,
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate three tagged
Robert Osfield wrote: I have another OpenSceneGraph 2.8.2 release candidate for you, just a couple fixes since 2.8.2-rc2: # Build fixes for: * Building of dicom plugin with ITK under Linux. # Crash fixes to: * crash during window destruction under Windows when using closing a MFC based GraphicsWindow * deadlock under Windows due threading issues with atomic operations in Win32 Barrier implementation * OpenFlight plugin not handling spaces at the end of option strings You can grab the source code from: source package : OpenSceneGraph-2.8.2-rc3.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.2-rc3 OpenSceneGraph My plan is tag the the final OpenSceneGraph-2.8.2 release this week so please pull down the source and test it on as many platforms and of your own applications as possible so we can make sure we can catch as many problems prior to going gold. A collegue and I where wondering some time ago if the binary windows packages provided on the website are usable for debugging. Even though there are separate release and debug distributions the debug ones (at least the VS8 ones) don't seem to contain any .pdb files. I remember him trying to debug some OSG application but he could not get any symbol info for the OSG dlls. I've been out of windows development for a long time so don't really have the overview anymore. Can you have debug information in .lib files on windows or are .pdb files always required? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate three tagged
Jason Daly wrote: Paul Melis wrote: A collegue and I where wondering some time ago if the binary windows packages provided on the website are usable for debugging. Even though there are separate release and debug distributions the debug ones (at least the VS8 ones) don't seem to contain any .pdb files. I remember him trying to debug some OSG application but he could not get any symbol info for the OSG dlls. I've been out of windows development for a long time so don't really have the overview anymore. Can you have debug information in .lib files on windows or are .pdb files always required? You can have embedded debug info (pass /Z7 to the compiler instead of the usual /Zi). I'm not sure if that's how the OSG debug packages work, but it is possible. Interesting, VS9's cl.exe reports that /Z7 option as enable old-style debug info. I guess progress isn't everything if you want integrated debug information :) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText Chopping Letters
Mike Hall wrote: I have attached an image showing the issue. Try increasing the resolution of the glyph textures, with setFontResolution(). When you have a low resolution the artifacts will stand out more. I've done some hacking to dump the glyph textures that are actually used. There's no obvious clipping going on there, they look spot on (see attached files, and yes, they're upside down). So the clipping comes from using texture coordinates that are slightly off, which might explain why using an integer position might lead to better results (although I don't really see a difference versus non-integer positions myself). That's a bit of a shame though, having good glyph textures that get mangled a bit somewhere in the process... Paul attachment: glyph-0-131x173.pngattachment: glyph-2-105x131.pngattachment: glyph-5-126x180.pngattachment: glyph-7-110x131.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ffmpeg stdint on Windows?
Hi,
Tanguy Fautre wrote:
A bit OT, but which part of the C standard says that all uninitialized
variables shall default to 0? The only zero initialization guarantee
of the C standard I know of is related to static variables (which MSVC
supports).
I'm pretty sure even GCC doesn't zero-initialize variables by default, e.g.
13:31|p...@tabu:~/acgt/webservices-svn cat t.c
#include stdio.h
int main()
{
int i;
printf(%d\n, i);
}
13:38|p...@tabu:~/acgt/webservices-svn gcc -o t -std=c99 t.c
13:38|p...@tabu:~/acgt/webservices-svn ./t
134513588
If what you say about FFmpeg expected C behaviour is true, it sounds
to me that FFmpeg is relying on a non-standard extensions of GCC.
If you don’t mind, I’ll take your email as an opportunity to express
my biggest complain about the FFmpeg project: its portability.
On the current situation of FFmpeg on Windows, IMHO the FFmpeg dev
team has abslolutely no valid reasons for not making FFmpeg portable.
In fact, it looks like they took several decisions with the sole
purpose of making FFmpeg a GCC-only / MSVC-incompatible product.
Reading their rant about MSVC on the official website tends to confirm
that some of their choices are mainly motivated by anti-microsoft
political reasons rather than technical.
From the FFMPEG FAQ (http://ffmpeg.org/faq.html#SEC9)
4.3 Is Microsoft Visual C++ supported?
No. Microsoft Visual C++ is not compliant to the C99 standard and does
not - among other things - support the inline assembly used in FFmpeg.
If you wish to use MSVC++ for your project then you can link the MSVC++
code with libav* as long as you compile the latter with a working C
compiler. For more information, see the Microsoft Visual C++
compatibility section in the FFmpeg documentation.
There have been efforts to make FFmpeg compatible with MSVC++ in the
past. However, they have all been rejected as too intrusive, especially
since MinGW does the job adequately. None of the core developers work
with MSVC++ and thus this item is low priority. Should you find the
silver bullet that solves this problem, feel free to shoot it at us.
We strongly recommend you to move over from MSVC++ to MinGW tools.
The second paragraph is interesting, as it suggests that people have at
least tried in the past to get ffmpeg to be MSVC-compatible. But if they
made the decision to use C99 (which does have some nice additions
compared to the older C standards) then MSVC is indeed left in the rain :)
- They’ve chosen to rely on the C99 standard, which is not as widely
as supported as C89 and C++98. GCC is the only widely-used compiler
that comes close to having a full C99 support (followed by the Intel
compiler), but even GCC is still missing several features
(http://gcc.gnu.org/c99status.html). MSVC and Borland have little C99
support.
- They use the ATT assembly syntax for x86/x86-64 assembly code
instead of using the Intel assembly syntax or Intel intrinsics.
These two decisions alone mean that one would have to rewrite most of
FFmpeg to get it compiling on any compiler that is not a GCC-clone.
While there is nothing close to FFmpeg on the market (open or closed
source), while I’m a huge supported of FFmpeg and related projects,
such poor decisions are ridicule from a software engineering point of
view and ultimately hurts FFmpeg.
Bottom line: I think the ffmpeg devs only care about Linux (and other
unices). Windows folks are more used to having libraries available in
binary form so it takes just one guy to build FFMPEG using MinGW and
make it available for the rest to use.
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ffmpeg stdint on Windows?
Garrett Potts wrote: [...] Honestly I have not read up on the C standard and only took what they said as being true. They said they adhere to the C99 standard and they sent me a cut and past from the C99 standard that said variables are to be initialized to 0 but honestly can't remember if that is for static or non static or both. Looks like only static variables are zero-initialized: ISO/IEC 9899:TC2 draft, section 6.7.8, item 10: 10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then: — if it has pointer type, it is initialized to a null pointer; — if it has arithmetic type, it is initialized to (positive or unsigned) zero; — if it is an aggregate, every member is initialized (recursively) according to these rules; — if it is a union, the first named member is initialized (recursively) according to these rules. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Consistent lighting across different cameras
Julian Looser wrote: Hi Ulrich, (The model and lightsource are a shared graph, right?) Yes, that's right. With regards to the different lighting, how is your model tessellated? If it's coarsely tessellated and/or you're using face normals then the lighting calculation might only be done on the corner vertices and interpolated from there. The model is a simple box with no further tessellation, and just face normals. However, the effect is the same with more complicated and higher-tessellated models. I think the detail of the model shouldn't effect the lighting in this case... all the cameras are looking at the same lit scene from the same point, just with slight offsets in the projection and view matrices. Other than possibly subtle differences in specular highlights, I wouldn't think the scene should be lit any differently in each of the views. I realise the lighting won't look great on a low-tessellated model, but I think it should be consistent. I figure it's like taking multiple photos and stitching them together into a panorama... the world doesn't get lit completely differently just because you turn left and right a bit. :-( FYI, you probably got a good suggestion from Terry Welsh (try enabling GL_LIGHT_MODEL_LOCAL_VIEWER), but his reply doesn't seem to have been added to this thread... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Consistent lighting across different cameras
Julian Looser wrote: Hi, I am using OSG in a multi-wall stereo rendering environment. We have three walls, and we render both a left and right eye view for each wall. To do this, in my application I create six osg::Cameras and update their projection and view matrices each frame based on head-tracking. I add the same subgraph under each camera, and I get a seamless 3D scene across the three walls. So far so good. My problem is with lighting. Although the 3D geometry is rendered in the right place, it isn't lit correctly. For example, sometimes the left view might be much brighter than the center view, which in turn is brighter than the right view. This has me confused because all six cameras are rendering the exact same scene, and the light is part of the scene (rather than a head-light of the viewer for example). Can you give more detail on the sometimes? Does that mean that the lighting varies over different runs of your software, or that the lighting is incosistent during a single run for some head positions? If the latter, it sounds like the head transformation isn't applied consistently to the light position. And is there some position for which the lighting does seem to be correct? Bye, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate two tagged
Robert Osfield wrote: Hi All, I’ve have now tagged the OpenScneGraph-2.8.2 release candidate 2, and as very few problems were reported in testing of 2.8.2-rc1 there is just a couples of changes required: * fix of the parsing of ascii floating point numbers in plugins and env var parsing so that it always uses the ‘.’ decimal place convention, regardless of the OS/application set locales. * workaround to threading issues in the osgShadow::ParallelSplitShadowMap and osgShadow::ShadowVolume by making osgshadow select SingleThreaded for these shadow techniques. The source code to 2.8.2-rc2 can be found at: source package : OpenSceneGraph-2.8.2-rc2.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.2-rc2 OpenSceneGraph Please test this rc2 on as many platforms as you can get your hands on. If testing goes well we will move to a full release of 2.8.2 in the next few days. Just a quick note to say that there does not seem to be a check for poppler being installed during cmake configuration. I was missing some of the headers (specifically the glib bindings), but cmake did not complain. Compilation then failed during building of the pdf plugin (this is with latest 2.8 svn, btw). Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to deploy osg application
Jason Daly wrote: Garrett Potts wrote: Hello All: I have used this in the past: http://www.dependencywalker.com/ Should have a free download. It helps to see how and what dependency DLL's load given an applicaiton or another DLL. Try running the app agains osgviewer.exe and you should see the dll's that are missing or if none are missing it should help to see what dll's are loaded within the search path. Alena, The specific error message you posted indicates that you probably do have a mix of debug and release dependencies. Dependency Walker (Garret's link above) is a good way to check. If you run Dependency Walker on your app and look at the module list at the bottom, you should see either MSVCR80.DLL or MSVCR80D.DLL, but not both. I think this exact same tool is included with VS, at least the more recent versions. Somewhere under Common/Tools/bin/depends.exe I believe. Saves a download.. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Forum 20 Second Search Wait
Chris 'Xenon' Hanson wrote: Kawicki, Ryan H wrote: Maybe something is wrong with my browser, but I am trying to search the forum for a particular item. Every time I try to move to the next page, I keep getting the following statement: For safety reasons the search is only possible 1 times within 20 seconds. If this number was exceeded, you must wait now X seconds, until you can implement the next search procedure. I just want to move to the next page within my current search. Can someone please look into this so that moving to new pages do not cause a 20 second wait time penalty to incur? Thanks. I've seen this before on other forums, and it always turned out to be some sort of configuration in the browser, not something on the forum's side. The message displayed is listed in the forum HTML code. It does not come from the browser. From the phpBB documentation (http://www.phpbb.com/support/documentation/3.0/adminguide/acp_general.php#acp_server_search): *General Search Settings [...] * * User search flood interval: This value indicates the number of seconds that your users have to wait between consecutive searches. This value is checked independently for each user. All positive integers are valid values. If you want to disable checking for search intervals for users, set this value to 0. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Forum 20 Second Search Wait
Chris 'Xenon' Hanson wrote: Paul Melis wrote: The message displayed is listed in the forum HTML code. It does not come from the browser. Yes, but it's a situation that occurs on the client-side that causes the problem -- not a misconfiguration of the forum. That's why most users don't encounter it. It could be caused by an aggressive pre-fetcher, either in the browser or a proxy. Ah, that's what you meant. Sounds plausible indeed... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] a bug in vpb
Jean-Sébastien Guay wrote: Hi Ulrich, You're right that what you (and Robert) note is an error (i.e. assigning an iterator from one container to an iterator from another container). But... I don't believe this is the problem. The 'it = container.erase(it)' construct is correct. It seems that according to the standard, it is, but some (many?) versions of gcc don't support it (perhaps it was added late in the standardization process or whatever). I've run across the same problem as Wang Rui - map::erase(iterator) returns void on some common compilers. So it's not portable code (by gcc's fault but still...). According to the spec I have here (ISO C++ 1998 draft) std::map::erase(it) should return void (and same for std::set). Only for sequential containers (vector, list, deque) is an iterator returned in case of erase()ing. Makes sense too, as associative containers are usually not implemented as a simple list of elements, so returning the next item after the one just erased could be tricky. Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cygwin Compile Question OSG 2.8.1
Christopher Wang wrote: Hi, That didn't either. Maybe I missing some step in the setup. What I did was: Ran Cygwin's setup.exe to install OpenGl, Cygwin, GCC, and several of the pre-reqs I unzipped the latest source (2.8.1) into /home/username/OpenSceneGraph-2.8.1 I made a folder /home/username/buildOSG Did ccmake ../OpenSceneGraph-2.8.1 Did a configure Fixed the OpenGL path to it pointed to the parent of the folder GL Did another configure Did a generate Did a make Then it fails about 15% on make!! I ideas what step I'm missing? ... Thank you! In case you get tired of this and are not specifically tied to cygwin try MinGW. I've had more success with OSG and MinGW in the past... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] a bug in vpb
Paul Melis wrote: Jean-Sébastien Guay wrote: Hi Ulrich, You're right that what you (and Robert) note is an error (i.e. assigning an iterator from one container to an iterator from another container). But... I don't believe this is the problem. The 'it = container.erase(it)' construct is correct. It seems that according to the standard, it is, but some (many?) versions of gcc don't support it (perhaps it was added late in the standardization process or whatever). I've run across the same problem as Wang Rui - map::erase(iterator) returns void on some common compilers. So it's not portable code (by gcc's fault but still...). According to the spec I have here (ISO C++ 1998 draft) std::map::erase(it) should return void (and same for std::set). Only for sequential containers (vector, list, deque) is an iterator returned in case of erase()ing. Makes sense too, as associative containers are usually not implemented as a simple list of elements, so returning the next item after the one just erased could be tricky. Interestingly, the c0x draft I could find indeed lists std::map::erase(it) (and for set as well) as returning an interator. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cygwin Compile Question OSG 2.8.1
Christopher Wang wrote: Hi, Sadly everyone else is using cygwin, so for compatibility sake I need to keep to that. ... But doesn't that give you more than one reference to figure out how they compiled OSG with cygwin? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] a bug in vpb
Hey, Jean-Sébastien Guay wrote: According to the spec I have here (ISO C++ 1998 draft) std::map::erase(it) should return void (and same for std::set). The version I have is dated October 2008. Here's a link: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2798.pdf From here: http://www.open-std.org/JTC1/SC22/WG21/ See page 838: iterator erase(const_iterator position); size_type erase(const key_type x); iterator erase(const_iterator first, const_iterator last); So yeah, it was probably added later. The inconsistency in void - iterator return type seems to have been marked as defect (DR 130) shortly after the previous C++ spec was published in 1998. DR 130 is dated March 1990: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130 The DR proposes to change erase() from returning void to returning an iterator. Anyways, the result is that some (all? I'm not sure) versions of gcc don't support the version that return an iterator, and return void instead. VC++ does. Does this mark the first time VC++ is more up-to-date than gcc with regards to standards? :-) From what I can find about this is that Dinkumware STL (which is what VS is using) has chosen to return iterators for erase(). I guess you could say that any conforming code using erase() must ignore the return value, as it is prescribed to be void. An STL implementation that differs in return type will also work with conforming code, as the result value is ignored anyway. So perhaps it is code using Dinkumware STL (VS) that expects an iterator as result value that is non-conforming... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors with 2.8.1
Ulrich Hertlein wrote: Hi John, On 4/6/09 7:24 PM, John Kelso wrote: After downloading 2.8.1 and typing cmake, I got this error: The end of a CMakeLists file was reached with an IF statement that was not closed properly. Within the directory: /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion The arguments are: OSG_MAINTAINER Are all bets off from this point, or can this be safely ignored? I plowed ahead anyway and the make died a horrible death. Before I waste time figuring out why, I'm wondering if I could get some advice about the relevance and importance of the cmake message. You're probably using a version of cmake that is too old (maybe 2.4?) The toplevel CMakeLists.txt contains IF(WIN32) CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR) ELSE(WIN32) IF(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR) ELSE(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR) ENDIF(APPLE) ENDIF(WIN32) so either these checks are not strict enough and your version of CMake is screwing up, or something else is going on. What version of CMake do you use? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors with 2.8.1
Paul Melis wrote: Paul Melis wrote: John Kelso wrote: Hi, cmake 2.4-patch 8, that came with CentOS release 5.3. Our systems have been upgraded since my last OSG build, so I'll see if there's any relationship. If I get stuck I'll mail again. Should I see if our system guy can install a newer cmake? First, try this: In applications/osgversion/CMakeLists.txt change ENDIF() to ENDIF(OSG_MAINTAINER) That line looks fishy. If that solves it for you then I don't know how it ever got through the release candidate testing. The ENDIF() was introduced in rc4, and even that was followed by rc5. Perhaps it's only CMake 2.4 that stumbles over this. Checking... Indeed, no warning with 2.6, while 2.4 DOES warn (but continues with configuring). Robert, I fixed this on the 2.8 branch (r10313). Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors with 2.8.1
John Kelso wrote: Hi, cmake 2.4-patch 8, that came with CentOS release 5.3. Our systems have been upgraded since my last OSG build, so I'll see if there's any relationship. If I get stuck I'll mail again. Should I see if our system guy can install a newer cmake? One thing cmake 2.6 has over 2.4 is that it seems to be smarter when it comes to linking. With 2.4 you get some kind of relinking stage when doing 'make install', which doesn't occur with 2.6 I can't say anything about the other differences between 2.4 and 2.6 Paul Thanks again, John On Thu, 4 Jun 2009, Paul Melis wrote: Ulrich Hertlein wrote: Hi John, On 4/6/09 7:24 PM, John Kelso wrote: After downloading 2.8.1 and typing cmake, I got this error: The end of a CMakeLists file was reached with an IF statement that was not closed properly. Within the directory: /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion The arguments are: OSG_MAINTAINER Are all bets off from this point, or can this be safely ignored? I plowed ahead anyway and the make died a horrible death. Before I waste time figuring out why, I'm wondering if I could get some advice about the relevance and importance of the cmake message. You're probably using a version of cmake that is too old (maybe 2.4?) The toplevel CMakeLists.txt contains IF(WIN32) CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR) ELSE(WIN32) IF(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR) ELSE(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR) ENDIF(APPLE) ENDIF(WIN32) so either these checks are not strict enough and your version of CMake is screwing up, or something else is going on. What version of CMake do you use? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak problem
Andoni Mujika wrote: Hi Robert, Sorry for not being very precise. I also tried osg::ref_ptr. Now, the code looks like this: osg::ref_ptrosg::Vec3Array m_geom; /m_geom = (osg::Vec3Array*) ((dynamic_castosg::Vec3Array*// (m_NewGeom)-clone(osg::CopyOp::DEEP_COPY_ARRAYS))); the memory grows and grows... / Are you developing on Linux? If so, you might want to give valgrind a try and specifically its 'massif' tool. This allows you to track memory usage during a programs run and can (in principle) provide you with information where all the memory you're seeing was allocated. Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Access vertices and faces after load the model
Thrall, Bryan wrote:
Paul Martz wrote on Thursday, May 28, 2009 4:50 PM:
You use a NodeVisitor to walk your scene graph and look for Geodes,
then iterate over the Drawables that are attached to the Geodes, using
dynamic_cast to access the Drawable as a Geometry.
Even better, I notice osg::Drawable has asGeometry(), which is cheaper
than dynamic_cast :)
Wow, I wasn't expecting the difference to be this large, as virtual
function calls aren't completely free either:
16:51|p...@tabu:~ cat t.cpp
// g++ -o t t.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ -losg -losgDB
#include osgDB/ReadFile
#include sys/time.h
float
timediff(struct timeval t0, struct timeval t1)
{
return 1000 * (t1.tv_sec - t0.tv_sec) + (t1.tv_usec - t0.tv_usec) /
1000.0;
}
int main()
{
osg::Group* cow = (osg::Group*)osgDB::readNodeFile(cow.osg);
osg::Geode* geode = (osg::Geode*)cow-getChild(0);
osg::Drawable *draw = geode-getDrawable(0);
boolisgeom = true;
int i;
struct timeval t0, t1, t2;
const int N = 10;
gettimeofday(t0, NULL);
for (i = 0; i N; i++)
isgeom = isgeom (draw-asGeometry() != NULL);
gettimeofday(t1, NULL);
for (i = 0; i N; i++)
isgeom = isgeom (dynamic_castosg::Geometry*(draw) != NULL);
gettimeofday(t2, NULL);
printf(%d\n, isgeom); // need to use isgeom, as otherwise it
might be optimized away
printf(asGeometry(): %.3f ms\n, timediff(t0, t1));
printf(dynamic_cast(): %.3f ms\n, timediff(t1, t2));
}
16:52|p...@tabu:~ g++ -o t t.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/
-losg -losgDB
16:52|p...@tabu:~ ./t
1
asGeometry(): 1.181 ms
dynamic_cast(): 3.945 ms
16:52|p...@tabu:~ g++ -O3 -o t t.cpp -I ~/osg2.8/include/ -L
~/osg2.8/lib/ -losg -losgDB
16:52|p...@tabu:~ ./t
1
asGeometry(): 0.839 ms
dynamic_cast(): 3.611 ms
16:52|p...@tabu:~
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Attack the PrimitiveSet
Hi,
Maxime BOUCHER wrote:
For anyone who would read this thread an d reproduce the same, don't.
It seems the DrawArrayLengths contains a single number representing in a way I
don't understand the primitives EVEN IF you can access the primitives the same
way than for a DrawElementsUthing.
It's not that hard to understand. Take, for example, the cow.osg sample
file (check the file in a text editor). There's a Geometry node in there
with 1 primitive set, which is a DrawArrayLengths. The type of this
primitive set is TRIANGLE_STRIP, so it defines multiple triangle strips.
The numbers (3, 3, 10, 14, 5, 5) represent the number of vertices
user *per triangle strip*. So the DrawArrayLengths defines a triangle
strip of 3 vertices (i.e. a single triangle), and then another strip of
3 vertices, etc. The vertices are simply used in order from the vertex
array. So the first triangle strip is defined with vertices 0, 1 and 2;
the second triangle strip by vertices 3, 4 and 5, etc.
In total, the DrawArrayLengths primitive set defines 984 triangle strips.
Geometry {
DataVariance DYNAMIC
[...]
useDisplayList TRUE
Primitives 1
{
DrawArrayLengths TRIANGLE_STRIP 0 984
{
3
3
10
14
5
5
}
}
VertexArray 7772
{
4.76334 -1.36791 3.02949
4.85496 -1.36297 3.09889
4.73514 -1.38955 3.08412
4.92619 0.143477 2.29847
4.98236 0.0975301 2.31196
4.94471 0.136714 2.27932
...
}
HTH,
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Test post, very strange
Robert Osfield wrote: On Wed, May 27, 2009 at 5:22 AM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: I'm posting to see if this message shows up. Oddly, a message I've tried to send to the list three times over the past few weeks, refuses to appear here. But my other replies seem to show up. Is there any sort of content-based filtering that might be eating my message? There isn't any content based filtering. The only filtering done presently is the rejection of email addresses that aren't subscribed to the osg-users list. Some mail clients silently don't display your own posts, perhaps this is something that is happening. Note that there is also a mailman setting to specify if you want to receive your own post or not. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Attack the PrimitiveSet
Hi, Maxime BOUCHER wrote: I'm currently attacking the primitives of my scene and I would like to remove some of them from my one of my PrimitiveSets. [...] Isn't there a way to do a classical remove method like the one from the std::vector (for example) ? What kind of PrimitiveSet do you want to erase elements from? E.g. all DrawElementsXXX classes derive from std::vector, so you should be able to use the methods from vector on those. Paul A very ugly and heavy solution would be to copy the existing one but the indices I want to remove . As I say, it's very ugly and as I want to remove a lot of primitives it would quickly become very heavy. Thank you! Cheers, Maxime -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13040#13040 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Attack the PrimitiveSet
Maxime BOUCHER wrote:
Thanks for replying!
Paul Melis wrote:
What kind of PrimitiveSet do you want to erase elements from? E.g. all
DrawElementsXXX classes derive from std::vector, so you should be able
to use the methods from vector on those.
OK, it's interesting.
I mainly work on DrawArrayLength. What can I do with it?
From include/osg/PrimitiveSet:
class OSG_EXPORT DrawArrayLengths : public PrimitiveSet, public
VectorGLsizei
{
public:
[...]
where VectorGLsizei is (basically) std::vectorGLsizei. So you can just do
osg::DrawArrayLengths *arr = new osg::DrawArrayLengths();
arr-push_back(5);
arr-erase(arr-begin()+10, arr-begin()+20);
wrote:
What exactly do you mean attacking, are you trying to remove primitive from primitive sets.
Indices are deprecated and they are not encouraged to be used anymore. The dirty way is the
classical way.
Yes, I want to remove primitives removing their indices.
Can I ask you since which version indices are deprecated?
Have you an example of the dirty way? I don't get what you mean.
With indices do you mean OpenGL indices here (as in drawing primitives
by index), or do you mean indices in the DrawArrayLengths array? Rabbi
means the former is generally not recommended for performance reasons.
The latter is something completely different and is no problem.
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged
Hi,
Regarding rev 10233:
---
osg/Vec?b:
Also changed
typedef char value_type;
to
typedef signed char value_type;
In the case of a simple char, SWIG assumes a string.
Using signed char instead of char does not change
the behaviour of the class.
---
Transforming char to signed char obviously changes the behaviour, as you
can no longer store values in same range anymore. E.g.
14:37|me...@juggle2:~/c/osg/svn/branches-2.8 cat t.cc
#include osg/Vec3b
#include cstdio
int main()
{
osg::Vec3b col;
col.x() = 255;
printf(%d\n, col.x());
}
14:37|me...@juggle2:~/c/osg/svn/branches-2.8 g++ -o t t.cc -I
~/osg2.8/include/
14:37|me...@juggle2:~/c/osg/svn/branches-2.8 ./t
-1
This seems like a bad idea, as I suspect people are more likely to use
Vec3b for storing colors values, instead of values in the -127..128 range.
I would suggest reverting the change and make Vec?b store char's once more.
Regards,
Paul
Robert Osfield wrote:
Hi All,
I've just tagged another release candidate, this time we've hit
2.8.1-rc5. Fingers crossed this will be our latest rc and we can
quickly move on to tagging 2.8.1 and get some new binaries posted.
http://www.openscenegraph.org/projects/osg/wiki/Downloads
Source Code: ¶
source package : OpenSceneGraph-2.8.1-rc5.zip
svn tag: svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.1-rc5
OpenSceneGraph
Could users please test out this latest rc5 this afternoon/evening and
if things look good on the major platforms I'll tag 2.8.1 tomorrow
morning.
Thanks for your assistance,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged
Paul Melis wrote:
Hi,
Regarding rev 10233:
---
osg/Vec?b:
Also changed
typedef char value_type;
to
typedef signed char value_type;
In the case of a simple char, SWIG assumes a string.
Using signed char instead of char does not change
the behaviour of the class.
---
Transforming char to signed char obviously changes the behaviour, as
you can no longer store values in same range anymore. E.g.
14:37|me...@juggle2:~/c/osg/svn/branches-2.8 cat t.cc
#include osg/Vec3b
#include cstdio
int main()
{
osg::Vec3b col;
col.x() = 255;
printf(%d\n, col.x());
}
14:37|me...@juggle2:~/c/osg/svn/branches-2.8 g++ -o t t.cc -I
~/osg2.8/include/
14:37|me...@juggle2:~/c/osg/svn/branches-2.8 ./t
-1
This seems like a bad idea, as I suspect people are more likely to use
Vec3b for storing colors values, instead of values in the -127..128
range.
I would suggest reverting the change and make Vec?b store char's once
more.
Hmm, there's a Vec4ub class, but not a Vec3ub one. So perhaps it would
be more appropriate to add a Vec3ub to store 0..255 values as an
alternative...
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] All Forum Users, PLEASE READ IT!
Robert Osfield wrote: Hi Ed, You don't seem to have the threads on this topic. The names are key to tracking who's saying what over time. If you can't do this then you can properly hold a conservation. If you are in crowded room and you wish to address someone you don't just shout out to everybody, you specifically address who you want to talk to, you need a name to do. Also when someones says something in this crowded room and you don't know who said it how are you to reply? How are you to remember what they've said previously or what you've said to them previously. Once you loose names you loose a fundamental part of how communication works, it breaks down. This is what are trying to do is stopping communication breaking down, prevent it from becoming too difficult to us to use. And please don't go adopting a name that takes the mikey. If you can't be civil then it only take me a minute to unsubscribe you. WTF? Are you now threatening to unsubscribe people because they choose to go by a first name and e-mail address only, while otherwise being civil in their communications?? This is getting ridiculous... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] All Forum Users, PLEASE READ IT!
Don't let this slip into something childish, please. If the main problem here is that it is expected of mailing list/forum users to have some form of name by which they can be addressed I personally couldn't give a hoot if it is their real full name, first name only, a completely fake name, some goofy nickname or whatever. And this is a graphics community after all, so people actually have a habit of using goofy nicknames. Paul o...@celticblues.com wrote: take mic to to address Mr. Paul Melis and others who wish to listen Ridiculous Indeed! Agreed! How can anyone say I was being un-civil? /take mic to to address Mr. Paul Melis and others who wish to listen Quoting Paul Melis p...@science.uva.nl: Robert Osfield wrote: Hi Ed, You don't seem to have the threads on this topic. The names are key to tracking who's saying what over time. If you can't do this then you can properly hold a conservation. If you are in crowded room and you wish to address someone you don't just shout out to everybody, you specifically address who you want to talk to, you need a name to do. Also when someones says something in this crowded room and you don't know who said it how are you to reply? How are you to remember what they've said previously or what you've said to them previously. Once you loose names you loose a fundamental part of how communication works, it breaks down. This is what are trying to do is stopping communication breaking down, prevent it from becoming too difficult to us to use. And please don't go adopting a name that takes the mikey. If you can't be civil then it only take me a minute to unsubscribe you. WTF? Are you now threatening to unsubscribe people because they choose to go by a first name and e-mail address only, while otherwise being civil in their communications?? This is getting ridiculous... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Time to remove Christer Wigren??
Philip Taylor wrote: Jose, The OSG list server is still bouncing emails to Christer Wigren which result in an automated response stating that he no longer works for the Swedish Defence Agency. Any chance of getting his name /email address removed from the list server? I'm sure the SDA would also appreciate the removal. Ditto from me, I've got dozens of bounce mails myself Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ray tracing using OSG
ami guru wrote: Hello Forum, I was wondering if there is anyone have done ray tracing using OSG. I once made a very quick and dirty example that merely uses OSG's KD-tree support to do ray tracing. See this thread: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014399.html Regards, Paul So far i have got from the forum Jean-Sébastien Guay did his Masters thesis on that domain and it would be really nice if he provide the link to the report, at least it would be a starting point for me. What do you think Jean? Regards Sajjad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Virtual Planet Builder
michael.schm...@l-3com.com wrote: Hello, I thought I would take a look at virtual planet builder, but I’m having difficulty figuring out how to build osgdem. Step 2 on the “osgdem Quick Step by Step Guide” seems like it might be out of date. Any help would be appreciated. To increase the chances of getting an answer, please specify *exactly* what you find is out of date... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Virtual Planet Builder
michael.schm...@l-3com.com wrote: Step 2 says make a copy of Make/dependencies. Where is Make/dependencies? Did you see this page? http://www.openscenegraph.org/projects/VirtualPlanetBuilder The build instructions there seem to be very recent (March 2009)... Paul -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Melis Sent: Tuesday, March 31, 2009 8:57 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Virtual Planet Builder michael.schm...@l-3com.com wrote: Hello, I thought I would take a look at virtual planet builder, but I'm having difficulty figuring out how to build osgdem. Step 2 on the osgdem Quick Step by Step Guide seems like it might be out of date. Any help would be appreciated. To increase the chances of getting an answer, please specify *exactly* what you find is out of date... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Fwd: Mesa and gldirect]
Cory Riddell wrote: J.P. Delport wrote: What always bothers me is the whole multiple window, multiple context thing. Correct me if I'm wrong, but I've always thought DirectX caters more for the single fullscreen 3D window case (games?). Is this not why CAD apps favour OpenGL? If DX can't do multiple windows/contexts nicely the wrapper won't be able to fix this. For specific cases the wrapper might be OK. I don't believe multiple windows/contexts is a problem anymore (was it ever?). I think CAD apps traditionally favored OpenGL simply because of their history. Way back (when SGI was relevant), the only place to get decent graphics performance was on very expensive Unix workstations. These days, the best performing graphics cards are for Windows and they are relatively inexpensive. I think that's why some CAD packages are dropping OpenGL support (Autodesk- I'm looking at you). Are they dropping OpenGL support for their 3D modeling packages as well (especially Maya)? Or just the autocad stuff? Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performing zooming and other navigations on geocentricvirtual earch?
Paul Martz wrote: (Posting this for about the 1000th time...) Zooming merely changes the field of view without changing the view position. Think of a photographer changing lenses on a camera without changing his physical location. You change the projection matrix to change the field of view, not the modelview matrix. But that's *your* definition of zooming... If you want to move the view position closer to a location, or further away from a location, then you would change the modelview matrix (Camera view) for that. Which is what the OP asks about (he does not ask about the projection matrix) Regards, Paul (#2) See the OpenGL red book. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- Subject: [osg-users] Performing zooming and other navigations on geocentricvirtual earch? Hi, I have created geocentric(spherical) virtual earth and wanted to do navigate around the earth using keyboard including zooming-in and out. As I m new to OSG I want to understand dat could it be done by setting viewmatrixAsLookAt of views' cameramanipulator? Plz get me some ideas how it can be done??? ... Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9054#9054 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performing zooming and other navigations on geocentricvirtual earch?
Paul Martz wrote: Zooming merely changes the field of view without changing the view position. Think of a photographer changing lenses on a camera without changing his physical location. You change the projection matrix to change the field of view, not the modelview matrix. But that's *your* definition of zooming... No, it's the computer graphics industry definition of zoom, as defined by Foley and Van Dam, the Real-Time Rendering book, and the OpenGL red book. It's a word that has its root in photography, which shares the same definition. Zooming magnifies an image; it does not affect the view position. Words mean things. Programming is a very precise activity and we should select our words carefully when describing what we are trying to do. I would be doing the OP a disservice if I did not correct his usage and inform him. Sorry for yapping about this, I'm having a bad day (and can't really figure out what is the real issue in my head...) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Insert custom Open GL code
Claudio Arduino wrote: Hi, i Need to insert custom OpenGl code like this: glBegin(GL_TRIANGLE_STRIP); glColor3f(1.0, 0.0, 1.0); glVertex3i(0,0,0); glColor3f(1.0, 0.0, 1.0); glVertex3i(2000,2000,0); glVertex3i(0, 2000,0); glEnd(); glFlush(); See the osgteapotexample (as suggested in the FAQ on the OSG website) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] osgdem issue
labrosse wrote: Hello, I work with OSG 2.6.1, GDAL 1.5.3 and VirtualPlanetBuilder r924 (compatible with OSG 2.6.1) on a virtual machine (fedora 10) to use osgdem. Do you mean virtual machine as in image running with VMWare? Paul All compile correctly, but when I want to use osgdem with this command for example : osgdem -d ps_height_1k.tif -t ps_texture_1k.tif -o out.ive I get this error, and I don't know what to do. I tried with the last version of OSG and VPB and I obtain the same error. Here is my error : -d ps_height_1k.tif -t ps_texture_1k.tif -o out.ive Adding terrainTile DataSet::_run() 0 0 DataSet::assignDestinationCoordinateSystem() : assigning first source file as the destination coordinate system started DataSet::createDestination(30) DataSet::assignDestinationCoordinateSystem() : assigning first source file as the destination coordinate system AR=1.00 C1=1 R1=1 createNewDestinationGraph Time for _destinationGraph-computeMaximumSourceResolution() = 0.013825 Time for createDestinationGraph 0.080615 Time for after_computeNeighbours 0.029995 Time for consolodateRequiredResolutions 0.03 Time for after_reproject 0.000576 Time for after_sort 0.000568 completed DataSet::createDestination(30) There are 2 contributing source files: ps_height_1k.tif ps_texture_1k.tif Error: Unable to open display :0.0. Error: Unable to open display :0.0. Error: Unable to create graphis context, problem with running osgViewer-2.6.1, cannot run compression. Precisions : - I connect to my Virtual machine with a console (ssh -X 192.168.x.x). - I think what the third error is blocking. Sorry about my English. Best Regards. Fabien Labrosse -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=8922#8922 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] osgdem issue
labrosse wrote: I think the OpenGL is supported by my VM, as the osg examples run correctly. But how do I do to test OpenGL ? Thanks you for your help, I try to install OSG and VPB on my host machine. You do not need to be root for that, btw. A normal user account should be enough... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] osgdem issue
labrosse wrote: Ok, I'm compiling OSG, and I'll try to install VPB. I know your stuff. No, you dont' ;-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenCL: democracy for GPU computing?
Martin Beckett wrote: Following OpenGL3 I'm not holding my breath for a standard developed by Khronos. It was actually developed by Apple, who submitted it to the Khronos Group (although they probably fiddled with the original spec, of course). The bit about OpenCL not just being for GPUs but also for CPUs and Cell worries me - it sounds like a 'grand plan' - it supports manufacturers extentions so if you have an OpenCL app that needs Nvidia extentions why not just use Cuda? Finally are there any real competitors to Nvidia in this space? Are you about to run heavy weight physics simualtions on an embedded Intel chipset? Would you rather be forced to always use NVidia's stuff through Cuda than possibly have the option of using a different backend through OpenCL? Only time will tell if there are going to be serious competitors, of course... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Operation lags
Hi Robert,
Robert Osfield wrote:
I have never seen problems like yours when using
OperationThread/Operatons, but on a second review I see that your
OpenThread never sleeps, it just churns away as effectively a spin
lock on the CPU. If your machine doesn't have sufficient cores to
handle a thead using 100% of the CPU core then you'll get frame stalls
like you have.
More general, is what follows a good summary of how to use an
osg::Operation (looking at the osgtext example for reference)? You
subclass it and implement your action in the call operator. Then you add
an instance of the operation class to a separate thread (starting it so
it calls the operation in the background), plus you add the same
instance to a osgViewer::Viewer instance. The only argument to the call
operator is used to distinguish who makes a call on the operation and
therefore what action you need to take. Is that a good summary?
Ignoring having to call yield once in a while, is the below test roughly
the way to do it (I used the osgtext example as a second source)? Is the
mutex in the call operator necessary?
Doh, lots of question marks above :)
Paul
// g++ -g -o op operation.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/
-losg -losgDB -losgViewer
#include cstdio
#include osg/OperationThread
#include osgViewer/Viewer
#include osgDB/ReadFile
class UpdateOperation : public osg::Operation
{
public:
UpdateOperation():
Operation(UpdateOperation, true)
{
}
virtual void operator() (osg::Object* callingObject)
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(_mutex);
printf(operator(): obj = 0x%08x\n, callingObject);
}
virtual void release()
{
printf(release()\n);
}
protected:
OpenThreads::Mutex _mutex;
};
int
main()
{
osg::ref_ptrUpdateOperation updateOperation = new UpdateOperation();
osgViewer::Viewer viewer;
osg::ref_ptrosg::OperationThread operationThread = new
osg::OperationThread;
operationThread-add(updateOperation.get());
operationThread-startThread();
viewer.addUpdateOperation(updateOperation.get());
viewer.setSceneData(osgDB::readNodeFile(cow.osg));
viewer.run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transforming normals
Paul Melis wrote: Can Hosgor wrote: I'm writing a simple nodevisitor to compute the lightmap of a given node. This nodevisitor treats transforms and geodes specially, so that each vertex in the geometry is multiplied with the most recent transform matrix in order to obtain world coordinates. So far the above code works well except that i don't know how to transform the normals. Can I obtain the normal matrix directly from the transformation matrix, if so how? If M is your transformation matrix then (M^-1)^T transforms your normals (that's the transposed inverse of M). You might have to rescale your normals so they become unit length again, after using the above matrix Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transforming normals
Can Hosgor wrote: I'm writing a simple nodevisitor to compute the lightmap of a given node. This nodevisitor treats transforms and geodes specially, so that each vertex in the geometry is multiplied with the most recent transform matrix in order to obtain world coordinates. So far the above code works well except that i don't know how to transform the normals. Can I obtain the normal matrix directly from the transformation matrix, if so how? If M is your transformation matrix then (M^-1)^T transforms your normals (that's the transposed inverse of M). Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Units in an IVE File
Geoff wrote:
I am having a little bit of an issue with some of my files. I have a
database that is in FLT format. I can load it into my program, and it
takes a while, but when I query the height at a given x,y location, I
get the proper values.
Now, i have taken this file and converted it using the osgconv.exe
into an IVE file for better performance. This works well when loading
it into my viewer, but when I try and query the height at a given x,y,
the values I get back are erratic and not remotely close to what i am
looking for.
is there some way that the units in the ive could be getting messed up
(or does it even have a notion of units) and if not, what do I need to
do to make sure the number that I get returned is in Feet?
The openflight plugin seems to support a number of options related to
units and conversion (see below).
Perhaps osgconv -O noUnitsConversion file.flt file.ive is what you want...
Paul
osgconv --formats
[...]
Plugin /home/paul/osg2.6/lib/osgPlugins-2.6.1/osgdb_openflight.so
{
ReaderWriter : FLT Reader/Writer
{
extensions : .fltOpenFlight
format
options: billboardCenter Import option
options: clampToEdge Import option
options: convertToFeet Import option
options: convertToInches Import option
options: convertToKilometers Import option
options: convertToMeters Import option
options: convertToNauticalMiles Import option
options: dofAnimationImport option
options: keepExternalReferences Import option
options: lighting=ON|OFF Export
option: Specifies a default enable/disable state for lighting, for Nodes
in the exported scene graph that don't set it explicitly. By default,
the exporter assumes lighting is enabled (GL_LIGHTING ON). Set this to
either ON or OFF. Example: lighting=OFF.
options: noTextureAlphaForTransparancyBinningImport option
options: noUnitsConversion Import option
options: preserveFaceImport option
options: preserveObject Import option
options: readObjectRecordDataImport option
options: stripTextureFilePathExport
option: If present in the Options string, the exporter strips the path
from texture file names, and writes only the texture file name to the
FLT Texture Palette. By default, the exporter doesn't strip the path,
and the name written to the Texture Palette is taken directly from the
osg::Image object referenced by the osg::Texture2D StateAttribute.
options: tempDir=dir Export
option: Specifies the directory to use for creation of temporary files.
If not specified, the directory is taken from the file name. If the file
doesn't contain a path, the current working directory is used.
Applications should set this to the name of their app-specific temp
directory. If the path contains spaces, use double quotes to ensure
correct parsing. Examples: tempDir=/tmp, tempDir=C:\My Temp Dir.
options: units=units Export
option: Specifies the contents of the Units field of the OpenFliht
header record. Valid values include INCHES, FEET, METERS, KILOMETERS,
and NATICAL_MILES. Default is METERS. Example: units=METERS.
options: validateExport
option: If present in the Options string, the plugin does not write an
OpenFlight file. Instead, it returns an indication of the scene graph's
suitability for OpenFlight export.
options: version=ver Export
option: Specifies the version of the output OpenFlight file. Supported
values include 15.7, 15.8, and 16.1. Default is 16.1. Example:
version=15.8.
}
ReaderWriter : ATTR Image Attribute Reader/Writer
{
extensions : .attr OpenFlight texture attribute format
}
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Forum users rare uses signatures, which is a pain tracking who's who
Art Tevs wrote: Hi folks, I've setted up a Rule-page http://forum.openscenegraph.org/rules.php describing the etiquette of forum/mailing list use. I have Hmmm, the rules page seems unaccessible (just like the rest of the forum): *Warning*: mysql_connect() [function.mysql-connect http://forum.openscenegraph.org/function.mysql-connect]: Host 'alpha.ip.elowar.com' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' in */var/www/tevs.eu/subdomains/osgforum/httpdocs/db/mysql4.php* on line *48* *Warning*: mysql_error(): supplied argument is not a valid MySQL-Link resource in */var/www/tevs.eu/subdomains/osgforum/httpdocs/db/mysql4.php* on line *330* *Warning*: mysql_errno(): supplied argument is not a valid MySQL-Link resource in */var/www/tevs.eu/subdomains/osgforum/httpdocs/db/mysql4.php* on line *331* phpBB : *Critical Error* Could not connect to the database Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Forum users rare uses signatures, which is a pain tracking who's who
OT: why are all the posts in this thread coming from the forum not threading correctly? It seems the mails don't have an in-reply-to header. Was this always the case for posts coming from the forum? Regards, Paul Art Tevs wrote: Hi Robert, I've registered for you, you should recieve an activation mail. Please change the password as soon as you activated your account. If you would like to have different name, then let me know, I change it. As soon as you have activated this, I will give you admin/moderator rights, so that you are can perform moderation tasks whenever you like. As to the Name issue, you are right, we should have some kind of First Last Name approach, however I am not sure if everybody would like this, because maybe somebody do like staying anonymous. I have already let users with strange names knows, that their account will be deactivated if they do not change their real name. Let's see what happens in the next days. cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=8685#8685 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::readFontFile returns NULL on valid argument
Jesper D. Thomsen wrote: Hi all, I have a rather strange problem. I'm using osgText in my project, but I'm getting null as return from this method: osgText::Font* t_font = osgText::readFontFile(fonts/arial.ttf); If you set the environment variable OSG_NOTIFY_LEVEL to DEBUG (tip: run in a dos box) you should be able to see in which locations the font file is being searched Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multithreading crash due toosgDb::Registry::instance()
Robert Osfield wrote:
2009/3/17 Schmidt, Richard richard.schm...@eads.com
mailto:richard.schm...@eads.com
http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf
http://www.cs.wustl.edu/%7Eschmidt/PDF/DC-Locking.pdf
Could you explain what the above document is all about...
I just read it an it describes a pattern where you use a mutex to guard
access to the singleton's _instance value, but in such a way that the
mutex is only needed when _instance == NULL, i.e.
class Singleton
{
public:
static Singleton *instance (void)
{
// First check
if (instance_ == 0)
{
// Ensure serialization (guard constructor acquires lock_).
GuardMutex guard (lock_);
// Double check.
if (instance_ == 0)
instance_ = new Singleton;
}
return instance_;
// guard destructor releases lock_.
}
private:
static Mutex lock_;
static Singleton *instance_;
};
This should give you thread-safe access to Singleton-instance() at all
times combined with correct initialization.
Quite neat actually,
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Forum users rare uses signatures, which is a pain tracking who's who
Art Tevs wrote: Hi Robert, all. I think adding another approval system to let users approve that they have to follow some kind of etiquette wouldn't have big success. Users would just click on Yes, I agree as soon as they see that button. Hence, I am not sure if this is needed at all. [...] All this kind of forcing correct real name wouldn't however change the way how users are posting. I think there is even a difference in the way of posting between forum and mailing list users from the psychological point of view. eMail feels like they are slower and not editable and hence communication is get more informative. Forums are faster in use and postings could be edited and hence the discussion there becames often a chat like and therefor users forget to add signatures or even to say Hello. I definitely agree with this observation. Forums are more chat-like. So, the problem of etiquette is hard to solve, because it depends only on the users. As for the using real names, I think I could write some kind of a system for the admins/moderators to manage users with non-informative real names. As you say, the problem of etiquette is hard to solve and I don't think much will change. I personally have more problems with folks that post to the list (either directly or through the forum) and seem to demand an immediate answer from somebody than with posts that don't have a signature. The latter is more annoying when there's also no e-mail address for that poster due to him/her posting through the forum. Perhaps we should see the forum-list gateway as an experiment and shouldn't be afraid to sever the link when it turns out that the two forms of community are not compatible enough... The problem with the email addresses used as sender's email (default osgfo...@tevs.eu) is hard to solve without making some changes also to the mailing list itself, which is not doable for me. What I could try is to change email header in the way, so that it looks like it was sent from the mail of the user, however using default's forum email in the header. However, I am not sure how mailman (osg's mailing list software) would react on this, because this is actually a way how spammers handle. Robert didn't mention this problem in his original mail and as such might not have high priority. It was merely something I noticed and occassionaly run into, but we've got to remember that this is not something the forum users are responsible for. It's merely a technical thingy due to the way the forum gateway works. Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openscenegraph-all-2.8.0-win32-x86-vc90sp1-Debug.tar.gz decompression is error!
xh wrote: Address:http://www.openscenegraph.org/downloads/stable_releases/OpenSceneGraph-2.8/binaries/Windows/VisualStudio9/; The file indeed seems to be corrupt: 16:01|p...@tabu:~ gzip -t openscenegraph-all-2.8.0-win32-x86-vc90sp1-Debug.tar.gz gzip: openscenegraph-all-2.8.0-win32-x86-vc90sp1-Debug.tar.gz: unexpected end of file openscenegraph-all-2.8.0-win32-x86-vc90sp1-Debug.tar.gz decompression is error! Are you this? Thx. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=8494#8494 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Forum users rare uses signatures, which is a pain tracking who's who
Robert Osfield wrote: With the advent of forum.openscenegraph.org http://forum.openscenegraph.org developed ably by Art Tevs we have a great new avenue for users to choice whether they prefer forum or mailing list for support... which is great but... for mailing list users the posts from forum members have become rather impersonal, with all too cryptic usernames, something that can happen with emails too but is happening far more readily with forum members. Once postings starting loose who they are from they also loose the self regulating and personal nature to them, and it makes bad tempered posts more likely, either at original source, or in response. Another thing with the forum is that all senders have the same e-mail (osgfo...@tevs.eu), so in effect you can't send somebody a personal reply without first lookup up their real e-mail address on the forum. CC-ing them is also not possible. I assume the forum-list gateway uses the From: name to match up a post on the list with a user on the forum? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RecordCameraPathHandler where is the saved_animation.path file?
Felix Ilbring wrote: Hi Robert I have done it. I put it to new osgViewer::RecordCameraPathHandler(C:\\ETC.path); but it was never there. Note that you need to add the handler to the correct osgViewer::View and also have to use the 'z' key to start recording... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RecordCameraPathHandler where is the saved_animation.path file?
Felix Ilbring wrote: thanks Paul the thing ist, that the recording works. it starts with 'z' and stops with 'Z' afterwards it plays the scene again and again. console promts: Recording camera Path. Writing camera file: ETC.path AnimationPath Completet in XXX so i guess it is the right viewer, but the file is nowhere to be found.. Hmm, and you can't locate it using a search in the file explorer? Another tool you could use is this one (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) which allows you to trace file activity of a process (read/write/create/etc). Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in RenderBin (?)
Christof Krüger wrote: I'm using the current 2.8.0 stable release. I used the 'Browse Source' to check the current trunk version of RenderBin.cpp and I see no change since. The actual crash occurs later in static object destruction when s_renderBinPrototypeList is destructed itself. I don't understand enough of osg to know what's exactly wrong. However, the s_registerDepthSortedBinProxy doesn't release the object it created and this looks very suspicious to me. The fact that two different instances of RenderBin get registered under the same name indeed smells fishy :) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in RenderBin (?)
Robert Osfield wrote:
HI David Christof et. al,
On Thu, Mar 12, 2009 at 10:13 AM, David Callu led...@gmail.com wrote:
What is smells fishy is the use of proto-className() to identify the
renderBin prototype to remove in removeRenderBinPrototype();
Well spotted David, the addRenderBinPrototype() correctly uses
binName, while the removeRenderBinProtoype() attempts to use the
className() as it's binName. The later is definitely a bug, and one
that is easy to fix...
Instead, in void RenderBin::removeRenderBinPrototype(RenderBin* proto) we
need something like this
code
void RenderBin::removeRenderBinPrototype(const std::string binName,
RenderBin* proto)
{
RenderBinPrototypeList* list = renderBinPrototypeList();
if (list proto)
{
RenderBinPrototypeList::iterator itr = list-find(binName);
if (itr != list-end()) list-erase(itr);
}
}
/code
Thought ?
There is no need to use the binName, one just needs to search for the
pointer in the map by hand, and remove it.
But as the RenderBin instances are still stored *by name* in
addRenderBinPrototype() doesn't this mean that one of the two instances
is lost when the second one is added?
Or is that intended?
Paul
I'm just tested the following code and it looks to be working properly :
void RenderBin::removeRenderBinPrototype(RenderBin* proto)
{
RenderBinPrototypeList* list = renderBinPrototypeList();
if (list proto)
{
for(RenderBinPrototypeList::iterator itr = list-begin();
itr != list-end();
++itr)
{
if (itr-second == proto)
{
list-erase(itr);
return;
}
}
}
}
I've attached the modified file. Christof could you test this and let
me know how you get on. If things look fine I'll check the changes
into svn/trunk and OSG-2.8 branch.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in RenderBin (?)
Paul Melis wrote:
Robert Osfield wrote:
HI David Christof et. al,
On Thu, Mar 12, 2009 at 10:13 AM, David Callu led...@gmail.com wrote:
What is smells fishy is the use of proto-className() to identify the
renderBin prototype to remove in removeRenderBinPrototype();
Well spotted David, the addRenderBinPrototype() correctly uses
binName, while the removeRenderBinProtoype() attempts to use the
className() as it's binName. The later is definitely a bug, and one
that is easy to fix...
Instead, in void RenderBin::removeRenderBinPrototype(RenderBin*
proto) we
need something like this
code
void RenderBin::removeRenderBinPrototype(const std::string binName,
RenderBin* proto)
{
RenderBinPrototypeList* list = renderBinPrototypeList();
if (list proto)
{
RenderBinPrototypeList::iterator itr = list-find(binName);
if (itr != list-end()) list-erase(itr);
}
}
/code
Thought ?
There is no need to use the binName, one just needs to search for the
pointer in the map by hand, and remove it.
But as the RenderBin instances are still stored *by name* in
addRenderBinPrototype() doesn't this mean that one of the two
instances is lost when the second one is added?
Or is that intended?
Oops, never mind, the names are different of course...
Paul
Paul
I'm just tested the following code and it looks to be working properly :
void RenderBin::removeRenderBinPrototype(RenderBin* proto)
{
RenderBinPrototypeList* list = renderBinPrototypeList();
if (list proto)
{
for(RenderBinPrototypeList::iterator itr = list-begin();
itr != list-end();
++itr)
{
if (itr-second == proto)
{
list-erase(itr);
return;
}
}
}
}
I've attached the modified file. Christof could you test this and let
me know how you get on. If things look fine I'll check the changes
into svn/trunk and OSG-2.8 branch.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in RenderBin (?)
Robert Osfield wrote: Hi David, On Thu, Mar 12, 2009 at 10:46 AM, David Callu led...@gmail.com wrote: What about the case of register two prototype with the same name. There are any warning message for the user. I fix this like that There is only ever supposed to be one prototype per binName, and the std::mapbinname,prototype ensures this is the case. If you attach two different bins under the same binName then the first will be replaced by the second one and the first one will automatically be unref'd. What was the use case for the bin names again? I mean, as there are already bin numbers that uniquely identify a bin are the names merely descriptive? Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VBOs not actually used?
Hi,
While trying to debug a collegue's code that uses a dynamically updated
color array on a Geometry that uses VBOs I'm getting confused about VBO
support in OSG 2.8.
Given the attached simple .osg file (a single colored quad, flagged to
not use display lists, but to use VBOs) I can see with an OpenGL tracer
(bugle) that no VBO is actually used on my nvidia FX5200 system. The
quad is simply drawn using glVertex() and friends. Are there limitations
to when VBOs can be used? And, if so, is there a way to have OSG loudly
complain when a request for VBOs can not be satisfied?
Similarly, the attached c++ test case is more in line with our original
code. It uses a color array that is updated each frame. The array is
flagged as dirty with a call to dirty(), but here also, no VBOs seem to
get used.
Regards,
Paul
PS glxinfo reports GL_ARB_vertex_buffer_object is supported, OpenGL
version is 2.1.0 NVIDIA 96.43.01
Geode {
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
useDisplayList FALSE
useVertexBufferObjects TRUE
PrimitiveSets 1
{
DrawArrays QUADS 0 4
}
VertexArray Vec3Array 4
{
0 0 0
0 1 0
1 1 0
1 0 0
}
NormalBinding PER_PRIMITIVE
NormalArray Vec3Array 1
{
0 0 1
}
ColorBinding PER_VERTEX
ColorArray Vec4Array 4
{
1 0 0 1
1 0 0 1
1 0 0 1
1 0 0 1
}
}
}
// g++ -o vbo vbo.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib -losg -losgViewer
#include osg/Geometry
#include osg/Array
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
int main()
{
osg::Vec3Array *verts = new osg::Vec3Array;
verts-push_back(osg::Vec3(0, 0, 0));
verts-push_back(osg::Vec3(0, 0, 1));
verts-push_back(osg::Vec3(1, 0, 1));
verts-push_back(osg::Vec3(1, 0, 0));
osg::Vec4Array *colors = new osg::Vec4Array;
colors-push_back(osg::Vec4(1,0,0,1));
colors-push_back(osg::Vec4(1,0,0,1));
colors-push_back(osg::Vec4(1,0,0,1));
colors-push_back(osg::Vec4(1,0,0,1));
osg::Vec3Array *normals = new osg::Vec3Array;
normals-push_back(osg::Vec3(0, -1, 0));
osg::Geometry *geom = new osg::Geometry;
geom-setVertexArray(verts);
geom-setColorArray(colors);
geom-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geom-setNormalArray(normals);
geom-setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE);
geom-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::QUADS, 0, 4));
geom-setUseVertexBufferObjects(true);
geom-setUseDisplayList(false);
geom-setDataVariance(osg::Object::DYNAMIC);
osg::Geode* geode = new osg::Geode;
geode-addDrawable(geom);
osgViewer::Viewer viewer;
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
viewer.setSceneData(geode);
viewer.realize();
int frame = 0;
while (!viewer.done())
{
viewer.frame();
colors-at(0) = osg::Vec4(0,(frame%250)/250.0,0,1);
colors-at(1) = osg::Vec4(0,(frame%250)/250.0,0,1);
colors-at(2) = osg::Vec4(0,(frame%250)/250.0,0,1);
colors-at(3) = osg::Vec4(0,(frame%250)/250.0,0,1);
colors-dirty();
//geom-setColorArray(colors);
frame++;
}
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBOs not actually used?
Paul Melis wrote: Similarly, the attached c++ test case is more in line with our original code. It uses a color array that is updated each frame. The array is flagged as dirty with a call to dirty(), but here also, no VBOs seem to get used. Forgot to mention that the original symptom we had was that the dirty() call on the color array did not update the rendering. There are fairly recent posts on osg-users that suggest that that call should be enough, but we could not get it to work, hence the simplified test case. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBOs not actually used?
Paul Melis wrote: Paul Melis wrote: Similarly, the attached c++ test case is more in line with our original code. It uses a color array that is updated each frame. The array is flagged as dirty with a call to dirty(), but here also, no VBOs seem to get used. Forgot to mention that the original symptom we had was that the dirty() call on the color array did not update the rendering. There are fairly recent posts on osg-users that suggest that that call should be enough, but we could not get it to work, hence the simplified test case. And to rule out that the opengl tracer is at fault here I just tried a very simple VBO example (http://www.songho.ca/opengl/gl_vbo.html) and when run the call trace indeed show relevant OpenGL VBO calls... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBOs not actually used?
Thrall, Bryan wrote: Paul Melis wrote on Thursday, March 12, 2009 9:33 AM: Hi, While trying to debug a collegue's code that uses a dynamically updated color array on a Geometry that uses VBOs I'm getting confused about VBO support in OSG 2.8. Given the attached simple .osg file (a single colored quad, flagged to not use display lists, but to use VBOs) I can see with an OpenGL tracer (bugle) that no VBO is actually used on my nvidia FX5200 system. The quad is simply drawn using glVertex() and friends. Are there limitations to when VBOs can be used? And, if so, is there a way to have OSG loudly complain when a request for VBOs can not be satisfied? Similarly, the attached c++ test case is more in line with our original code. It uses a color array that is updated each frame. The array is flagged as dirty with a call to dirty(), but here also, no VBOs seem to get used. Regards, Paul PS glxinfo reports GL_ARB_vertex_buffer_object is supported, OpenGL version is 2.1.0 NVIDIA 96.43.01 Binding PER_PRIMITIVE forces OSG out of fast path rendering, so I don't think it can use VBOs. Using OVERALL or PER_VERTEX instead allowed VBOs on my system. DANG! That's it, thanks... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converting large obj file with osgconv
Crampman wrote: I'm using a 64 bit linux system, with 2GB of ram and ~10GB of swap. The conversion failed after ~12 hours, and the obj model doesn't have any textures. How much geometry is there in your model? The OSG .obj plugin isn't very efficient. But .obj is very easy to parse (although things like groups might make conversion slightly more difficult), so you could try to do it yourself and directly construct the necessary OSG objects from c++ while reading in the .obj file... Paul Marcin Prus a écrit : Hi, do you have problem with not enough free memory or do you hit 2GB per 32 bit process limit in MS Windows? In second case, if you use Visual Studio, you can enable LARGEADDRESSAWARE linker flag for osgconv. As an addition you will need /3GB in boot.ini for 32 bit Windows XP. This will extend memory available for 32 bit process. Otherwise, you might consider using 64bit OSG. Also, you can try to do conversion in 2 steps, first with -O noTexturesInIVEFile and then convert resulting .ive into second one with textures inside. I used this approach some time ago and it worked for some of my large models. Best, Marcin Crampman pisze: Hi, I'm having problems when I try to convert a lagre obj file (~600MB) into a ive file using osgconv : the conversion took ages and eventually failed after eating the whole swap. Is there any solution or workaround ? Thanks! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converting large obj file with osgconv
Crampman wrote: Thanks for your quick replies, My model contains 8,726,464 vertexes and 17,377,292 tris That's not as much as I was expecting. I'm pretty sure I loaded models with similar sizes in OSG (which also took quite some time). I would say check out Robert's suggestion first (disabling the tri stripper) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vec3d - Vec3 bug under Linux ?
Robert Osfield wrote: Hi Vincent, I can't work out exactly what to bug is in your instance, from the contents of your email it sounds like windows and linux compilers are evaluating the conversion of types in a different order and getting different results, or that their is a compiler bug. The fact that adding an explicit Vec3d() into your code suggests to me Isn't that an explicit cast to Vec3f()? As osg::Vec3 defaults to Vec3f... Paul that it's not likely to be an OSG issue, rather a compile one. Robert. On Thu, Feb 26, 2009 at 2:25 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, I was thinking about posting in osg submission, but I don't have nothing to submit. I just had a little bug, solved now, but I thing this can be an interessting point for OSG to notice. To make a special geometry, I did a function returning a new vertex Array. In the code, all was based on Vec3d, including the return data (osg::ref_ptrosg::Vec3dArray ) Under windows, no problem for nothing. Under Linux, 2 of the 9 Vec3d of the array were wrong, and not constant (sometinme a wrong value, sometimes an other wrong value). to solve the problem, I just use vertices-push_back(osg::Vec3(ptA + decal - x*2.0 + z*1.5 + x*0.5 ))) instead of vertices-push_back(ptA + decal - x*2.0 + z*1.5 - x*0.5) and now all is good. Is there any unsafe conversion from Vec3d to vec3 ? I solve the problem for my application, but maybe someone have any explanation ... or maybe a bug is here... don't know.. Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] slight problem of image distortion with osgVolume
David Michéa wrote: Hi, for information : on the screen captures attached, you can see that the regular hexahedric volumes I have generated with my data are slightly distorted following the point of view. Just curious, what resolution is your volume data? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG build - xulrunner -nooby question
Hi, Alasdair Campbell wrote: Hi all, I am new to this list but was inspired to join the mailing list following your landmark release of 2.8.0 Congratulations to all Welcome! A point of nettique though: please don't start a new subject by replying to existing post, but simply make a new post to the list. In this case you replied to a thread on memory leak detection on windows, to which you post has nothing to add. While I have been building OSG from way back, I have noticed a couple of unresolved dependancies with respect to xulrunner. Namely that OSG has a dependacy on xulrunner=1.8.9, while the current version is 1.9 OSG's gecko plugin is meant to be used with xulrunner 1.8. There have been API changes in 1.9 that make it incompatible with the current plugin. Also, I find a dependancy on xulrunner-js which does not exist on my system. The package naming can be different among Linux distributions, so we need to keep track of which distro uses which package name. Note that the naming is probably 1.8-specific, as with 1.9 it seems to be called libxul-... OSG will build OK, but I wonder if I am losing out by not having these dependencies resolved. Any help would be gratefully recieved. You probably don't have a gecko plugin as a result of not having XUL 1.8. Check your lib/osgPlugins-2.8.0 directory for a osgdb_gecko.so file. If you don't have it it means you can't run, for example, the osgbrowser example. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG build - xulrunner -nooby question
Alasdair Campbell wrote: On Thu, 2009-02-12 at 12:55 -0500, Paul Speed wrote: Alasdair Campbell wrote: On Thu, 2009-02-12 at 18:16 +0100, Paul Melis wrote: Hi, Alasdair Campbell wrote: Hi all, I am new to this list but was inspired to join the mailing list following your landmark release of 2.8.0 Congratulations to all Welcome! A point of nettique though: please don't start a new subject by replying to existing post, but simply make a new post to the list. In this case you replied to a thread on memory leak detection on windows, to which you post has nothing to add. Hi Paul, thank you for replying, but I have no idea what you are talking about with respect to nettique (sic). As sure as I am living, I did not reply to any post, and simply started a new thread. There is absolutely no reference to any other post in my email, well not that I can see?? Am I crazy, or what? Can anyone on this list support Paul's view, and if so explain what I did to offend. How did you start a new thread? What e-mail client are you using? The message you submitted had as reference the following message IDs in its header: 20090211143545.0360f.403984.r...@web09-winn.ispmail.private.ntl.com 4992ed99.8000...@cm-labs.com 4992f614.3030...@codeware.com 4992fad9.4000...@cm-labs.com 10cf64e606897b4999da59c84ed149682a2...@oxfadc001.aristechnologies.com 7ffb8e9b0902120431j1341290eq20fec810c936b...@mail.gmail.com 006c01c98d13$4f486790$edd936...@com op.uo8qoc0urh8...@sukender1 10cf64e606897b4999da59c84ed149682a2...@oxfadc001.aristechnologies.com Which happen to be the message IDs from all of the messages in the memory leak thread. So, it looks to all of us who use threaded e-mail clients that you simply had the last message in that thread selected and hit the Reply button. Thus it looks like you are continuing that thread instead of starting a new one. Unless your mail client is doing something very strange. -Paul Oh my goodness, mea culpa. I did say I was newbie. I simply chose a message and changed the subject. This has worked for me on countless mailing lists without complaint. So sorry, please advise correct procedure for starting a new thread on this list. Sorry Paul M. Don't worry about it ;-) Paul M ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Server migration
Roland Smeenk wrote: is the server migration complete? Two notes: - I am missing a link to Recent Changes in the top right corner of the Wiki. You need to log on, which will then give you the Timeline button, which will shows wiki edits. The Recent Changes function is probably disabled. - The Wiki now works by registering and the user osg no longer is available. The page that describes this however can not be changed. See http://www.openscenegraph.org/projects/osg/wiki/Community/WikiLogIn Oops :) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc5 tagged, please test
Martin Beckett wrote:
SVN doesn't update any files when I switch from rc4 to rc5?
Complete revision 9758 is rc5 but no changes.
They are different:
9:46|p...@tabu:~/c svn co -q
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc4/
rc4
9:48|p...@tabu:~/c svn co -q
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/
rc5
9:50|p...@tabu:~/c diff -ur --exclude=.svn rc4 rc5 | head -n 30
diff -ur --exclude=.svn rc4/CMakeLists.txt rc5/CMakeLists.txt
--- rc4/CMakeLists.txt 2009-02-11 09:44:00.0 +0100
+++ rc5/CMakeLists.txt 2009-02-11 09:45:29.0 +0100
@@ -33,7 +33,7 @@
# set to 0 when not a release candidate, non zero means that any generated
# svn tags will be treated as release candidates of given number
-SET(OPENSCENEGRAPH_RELEASE_CANDIDATE 4)
+SET(OPENSCENEGRAPH_RELEASE_CANDIDATE 5)
SET(OPENSCENEGRAPH_VERSION
${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION})
@@ -293,13 +293,12 @@
FIND_PACKAGE(Jasper)
FIND_PACKAGE(OpenEXR)
FIND_PACKAGE(COLLADA)
+FIND_PACKAGE(ZLIB)
FIND_PACKAGE(Xine)
FIND_PACKAGE(OpenVRML)
FIND_PACKAGE(Performer)
-FIND_PACKAGE(ZLIB)
FIND_PACKAGE(GDAL)
FIND_PACKAGE(CURL)
-FIND_PACKAGE(ZLIB)
FIND_PACKAGE(ITK)
FIND_PACKAGE(LibVNCServer)
FIND_PACKAGE(OurDCMTK)
diff -ur --exclude=.svn rc4/CMakeModules/FindCOLLADA.cmake
rc5/CMakeModules/FindCOLLADA.cmake
--- rc4/CMakeModules/FindCOLLADA.cmake 2009-02-11 09:43:46.0 +0100
+++ rc5/CMakeModules/FindCOLLADA.cmake 2009-02-11 09:45:17.0 +0100
[...]
BTW, I get 403 errors when trying to check out from the rc5 tag, each
time with slightly different error messages:
9:45|p...@tabu:~/c svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/
rc51
svn: PROPFIND request failed on
'/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5'
svn: PROPFIND of
'/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5': 403 Forbidden
(http://www.openscenegraph.org)
9:45|p...@tabu:~/c svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/
rc51
svn: PROPFIND request failed on '/svn/osg/!svn/vcc/default'
svn: PROPFIND of '/svn/osg/!svn/vcc/default': 403 Forbidden
(http://www.openscenegraph.org)
9:45|p...@tabu:~/c svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/
rc51
svn: PROPFIND request failed on '/svn/osg/!svn/vcc/default'
svn: PROPFIND of '/svn/osg/!svn/vcc/default': 403 Forbidden
(http://www.openscenegraph.org)
9:45|p...@tabu:~/c svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/
rc51
svn: PROPFIND request failed on '/svn/osg/!svn/bln/9758'
svn: PROPFIND of '/svn/osg/!svn/bln/9758': 403 Forbidden
(http://www.openscenegraph.org)
Is this a server misconfiguration?
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc5 tagged, please test
Jose Luis Hidalgo wrote: Hi Paul, On Wed, Feb 11, 2009 at 9:49 AM, Paul Melis p...@science.uva.nl wrote: BTW, I get 403 errors when trying to check out from the rc5 tag, each time with slightly different error messages: 9:45|p...@tabu:~/c svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/ rc51 svn: PROPFIND request failed on '/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5' svn: PROPFIND of '/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5': 403 Forbidden (http://www.openscenegraph.org) 9:45|p...@tabu:~/c svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/ rc51 svn: PROPFIND request failed on '/svn/osg/!svn/vcc/default' svn: PROPFIND of '/svn/osg/!svn/vcc/default': 403 Forbidden (http://www.openscenegraph.org) 9:45|p...@tabu:~/c svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/ rc51 svn: PROPFIND request failed on '/svn/osg/!svn/vcc/default' svn: PROPFIND of '/svn/osg/!svn/vcc/default': 403 Forbidden (http://www.openscenegraph.org) 9:45|p...@tabu:~/c svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/ rc51 svn: PROPFIND request failed on '/svn/osg/!svn/bln/9758' svn: PROPFIND of '/svn/osg/!svn/bln/9758': 403 Forbidden (http://www.openscenegraph.org) Is this a server misconfiguration? I've seen this before, are you behind a proxy? Nope, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc5 tagged, please test
Paul Melis wrote: Jose Luis Hidalgo wrote: Hi Paul, On Wed, Feb 11, 2009 at 9:49 AM, Paul Melis p...@science.uva.nl wrote: BTW, I get 403 errors when trying to check out from the rc5 tag, each time with slightly different error messages: 9:45|p...@tabu:~/c svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/ rc51 svn: PROPFIND request failed on '/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5' svn: PROPFIND of '/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5': 403 Forbidden (http://www.openscenegraph.org) 9:45|p...@tabu:~/c svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/ rc51 svn: PROPFIND request failed on '/svn/osg/!svn/vcc/default' svn: PROPFIND of '/svn/osg/!svn/vcc/default': 403 Forbidden (http://www.openscenegraph.org) 9:45|p...@tabu:~/c svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/ rc51 svn: PROPFIND request failed on '/svn/osg/!svn/vcc/default' svn: PROPFIND of '/svn/osg/!svn/vcc/default': 403 Forbidden (http://www.openscenegraph.org) 9:45|p...@tabu:~/c svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc5/ rc51 svn: PROPFIND request failed on '/svn/osg/!svn/bln/9758' svn: PROPFIND of '/svn/osg/!svn/bln/9758': 403 Forbidden (http://www.openscenegraph.org) Is this a server misconfiguration? I've seen this before, are you behind a proxy? Nope, Oh, and I've never had these kinds of errors before with OSG and SVN... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] packages questions
Sukender wrote: Hi Robert, hi all, Sorry to push this topic up, but I think this may be important for the 2.8.0. I re-write in a shorter manner what was important in my post: 1. How Cygwin/MinGW/nmake packages are named (= the name of the compiler)? 2. Do Cygwin and MinGW have the same compiler and generate same binaries? I'm fairly certain they generate different binaries. Cygwin executables are dependent on the cygwin runtime, while Mingw executables use the standard MSVC runtime. There does seem to be a mingw-compatibility option to cygwin (-mno-cygwin), which seems to remove the dependency of executables on the cygwin compatibility layer (cygwin1.dll). I think the library formats are also incompatible, although I seem to recall there are some tools to do conversions and such. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak false positives on Windows
Jean-Sébastien Guay wrote: Hi Cory, I don't think anybody has questioned the design of OSG. Yes, Neil has said that perhaps we should consider restructuring to avoid the false positives. This comes down to changing the design. I also agree with you that making code concessions to accommodate tools is unfortunate, but it happens all the time. Yes, the coding changes to accomodate tools. But the design will stay the same. It's the implementation that changes. That's what I was talking about. On the other hand, I'd like to know if code that explicitly unloads OSG would ever be accepted into the repository. I'm getting the sense that it would be if it were sufficiently transparent, simple and inexpensive. Yes, Robert said in this thread that he would accept something that unloads/unrefs all singletons / static objects, but it might be hard to get to all singletons since some exist in the implementation files only. (btw, has anyone compiled valgrind for Windows?) valgrind is Linux only. I suspect it's not Linux-specific, but more gcc/g++ specific, and so might be buildable on cygwin or mingw? If it is, then it might be usable for Windows executables... From http://valgrind.org/info/platforms.html: In particular Windows is not under consideration here because porting to it would require so many changes it would almost be a separate project. There have been people that have run their windows executable under wine under valgrind (or should that be under valgrind under wine, hmmm :)). Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN 403 error
Jean-Claude Monnin wrote: Hi all, I'm trying to checkout OpenSceneGraph-2.8.0-rc4. It fails on a 403 Forbidden error (I tried multiple times since yesterday). I'm using TortoiseSVN 1.5.7 on windows. I was able to access the osg svn server in the past. Could this be a problem with the new server? Anyone else have this problem with anonymous snv access at the moment? Or is it a problem on my side? Here is the message from TortoiseSVN: Checkout from http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc4, Can you access this URL in your browser? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN 403 error
Jean-Claude Monnin wrote: On Tue, 10 Feb 2009 15:43:39 +0100, Paul Melis p...@science.uva.nl said: Jean-Claude Monnin wrote: Hi all, I'm trying to checkout OpenSceneGraph-2.8.0-rc4. It fails on a 403 Forbidden error (I tried multiple times since yesterday). I'm using TortoiseSVN 1.5.7 on windows. I was able to access the osg svn server in the past. Could this be a problem with the new server? Anyone else have this problem with anonymous snv access at the moment? Or is it a problem on my side? Here is the message from TortoiseSVN: Checkout from http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc4, Can you access this URL in your browser? Paul Yes, I can access that URL in the browser. Are you behind a proxy? For what it's worth: I can currently access the above URL and do an svn checkout ... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc3 tagged, please test
Hi Robert, Robert Osfield wrote: I would very much like to make the final 2.8.0 release tomorrow, so if rc3 compiles and runs well across platforms I'll make no further changes other than release dates, and resetting the release candidate number back to 0 to signify a final stable release. I saw you updated NEWS.txt in svn. I made some minor textual changes to the release notes on the wiki yesterday. Should I sync the svn version with the one in the 2.8 branch? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
Robert Osfield wrote: Hi All, I'm ready to tag the 2.8.0. Feedback on the 2.8 branch and 2.8.0-rc2 has been positive so far, so it looks like the code is pretty ready. Do you agree/disagree that we are ready to tag? Now is your last opportunity to report a show stopper! Did you see the message about rev 9722 not being in the branch yet? Paul Unless there is a show stopper reported I'll tag 2.8.0 at 1500hrs GMT today. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please give approval if you feel OpenSceneGraph-2.8 is ready ; -)
Robert Osfield wrote: On Mon, Feb 9, 2009 at 2:10 PM, Paul Melis p...@science.uva.nl wrote: Did you see the message about rev 9722 not being in the branch yet? It arrived just after I pressed send :-) So yes have spotted it, currently waiting on the server. Good ;-) BTW, you asked Stephan if he had committed it to the trunk, but I thought only you had permission to commit there? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc2 tagged, please test
Robert Osfield wrote:
We've all been busy testing out 2.8.0-rc1 and uncovered a few more
bugs, build problems and warnings that our now fixed - testing really
is paying dividends ;-)
I noticed that two empty lines in an osgText::Text are not rendered
correctly (it only shows one empty line), see the attached test.
However, I ran this test a few times now and I get a segfault at exit a
small percentage of the time. The traceback is
#0 0xb7888576 in glDrawBuffer () from
//usr//lib/opengl/nvidia/lib/libGL.so.1
(gdb) bt
#0 0xb7888576 in glDrawBuffer () from
//usr//lib/opengl/nvidia/lib/libGL.so.1
#1 0xb757e68d in osgUtil::RenderStage::drawInner (this=0x80899c0,
renderin...@0xb6518d30, previo...@0xb65190d4, docopytextu...@0xb6518d57)
at /home/melis/c/osg/svn/branches-2.8/src/osgUtil/RenderStage.cpp:830
#2 0xb7581226 in osgUtil::RenderStage::draw (this=0x80899c0,
renderin...@0x8088664, previo...@0xb65190d4) at
/home/melis/c/osg/svn/branches-2.8/src/osgUtil/RenderStage.cpp:1108
#3 0xb7589bd6 in osgUtil::SceneView::draw (this=0x8088608) at
/home/melis/c/osg/svn/branches-2.8/src/osgUtil/SceneView.cpp:1540
#4 0xb7bdc248 in osgViewer::Renderer::draw (this=0x8087ec8) at
/home/melis/c/osg/svn/branches-2.8/src/osgViewer/Renderer.cpp:451
#5 0xb7bd5998 in osgViewer::Renderer::operator() (this=0x8089ab4,
context=0x8088798) at
/home/melis/c/osg/svn/branches-2.8/src/osgViewer/Renderer.cpp:693
#6 0xb7dd557a in osg::GraphicsContext::runOperations (this=0x8088798)
at /home/melis/c/osg/svn/branches-2.8/src/osg/GraphicsContext.cpp:688
#7 0xb7ddbfad in osg::RunOperations::operator() (this=0x80c71e8,
context=0x8088798) at
/home/melis/c/osg/svn/branches-2.8/src/osg/GraphicsThread.cpp:134
#8 0xb7ddc0a5 in osg::GraphicsOperation::operator() (this=0x80c71e8,
object=0x8088798) at
/home/melis/c/osg/svn/branches-2.8/src/osg/GraphicsThread.cpp:50
#9 0xb7e24c59 in osg::OperationThread::run (this=0x80c6fc8) at
/home/melis/c/osg/svn/branches-2.8/src/osg/OperationThread.cpp:413
#10 0xb7ddc117 in osg::GraphicsThread::run (this=0x80c6fc8) at
/home/melis/c/osg/svn/branches-2.8/src/osg/GraphicsThread.cpp:38
#11 0xb792e1bd in OpenThreads::ThreadPrivateActions::StartThread
(data=0x80c6fd4) at
/home/melis/c/osg/svn/branches-2.8/src/OpenThreads/pthreads/PThread.c++:170
#12 0xb791818b in start_thread () from /lib/libpthread.so.0
#13 0xb79f409e in clone () from /lib/libc.so.6
I'm not modifying the text in the viewer loop, it's all set up before
the viewer is even constructed. I'm not using ref_ptr because
everything is constructed in main(), is that the problem here?
Paul
// g++ -o txt text.cpp -I ~/osg2.8/include -L ~/osg2.8/lib -losg -losgText
-losgViewer -losgDB -losgUtil -losgGA
#include osgViewer/Viewer
#include osgText/Text
#include osg/Camera
// lines 5 and 6 (both empty) are rendered as a single emtpy line
const char *s = Line 1\nLine 2\n\nLine 4\n\n\nLine 7\nLine 8\n;
int
main()
{
osgText::Text *t = new osgText::Text();
t-setFont(fonts/arial.ttf);
t-setText(s);
t-setCharacterSize(32.0);
t-setPosition(osg::Vec3(100, 600, 0));
osg::Geode *g = new osg::Geode();
g-addDrawable(t);
osg::Camera *c = new osg::Camera();
c-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
c-setProjectionMatrixAsOrtho2D(0, 1280, 0, 1024);
c-setViewMatrix(osg::Matrix::identity());
c-setClearMask(GL_DEPTH_BUFFER_BIT);
c-addChild(g);
c-getOrCreateStateSet()-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
osgViewer::Viewer *v = new osgViewer::Viewer();
v-setSceneData(c);
v-realize();
v-run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc2 tagged, please test
Paul Melis wrote: Robert Osfield wrote: We've all been busy testing out 2.8.0-rc1 and uncovered a few more bugs, build problems and warnings that our now fixed - testing really is paying dividends ;-) I noticed that two empty lines in an osgText::Text are not rendered correctly (it only shows one empty line), see the attached test. However, I ran this test a few times now and I get a segfault at exit a small percentage of the time. The traceback is #0 0xb7888576 in glDrawBuffer () from //usr//lib/opengl/nvidia/lib/libGL.so.1 (gdb) bt #0 0xb7888576 in glDrawBuffer () from //usr//lib/opengl/nvidia/lib/libGL.so.1 #1 0xb757e68d in osgUtil::RenderStage::drawInner (this=0x80899c0, renderin...@0xb6518d30, previo...@0xb65190d4, docopytextu...@0xb6518d57) at /home/melis/c/osg/svn/branches-2.8/src/osgUtil/RenderStage.cpp:830 #2 0xb7581226 in osgUtil::RenderStage::draw (this=0x80899c0, renderin...@0x8088664, previo...@0xb65190d4) at /home/melis/c/osg/svn/branches-2.8/src/osgUtil/RenderStage.cpp:1108 #3 0xb7589bd6 in osgUtil::SceneView::draw (this=0x8088608) at /home/melis/c/osg/svn/branches-2.8/src/osgUtil/SceneView.cpp:1540 #4 0xb7bdc248 in osgViewer::Renderer::draw (this=0x8087ec8) at /home/melis/c/osg/svn/branches-2.8/src/osgViewer/Renderer.cpp:451 #5 0xb7bd5998 in osgViewer::Renderer::operator() (this=0x8089ab4, context=0x8088798) at /home/melis/c/osg/svn/branches-2.8/src/osgViewer/Renderer.cpp:693 #6 0xb7dd557a in osg::GraphicsContext::runOperations (this=0x8088798) at /home/melis/c/osg/svn/branches-2.8/src/osg/GraphicsContext.cpp:688 #7 0xb7ddbfad in osg::RunOperations::operator() (this=0x80c71e8, context=0x8088798) at /home/melis/c/osg/svn/branches-2.8/src/osg/GraphicsThread.cpp:134 #8 0xb7ddc0a5 in osg::GraphicsOperation::operator() (this=0x80c71e8, object=0x8088798) at /home/melis/c/osg/svn/branches-2.8/src/osg/GraphicsThread.cpp:50 #9 0xb7e24c59 in osg::OperationThread::run (this=0x80c6fc8) at /home/melis/c/osg/svn/branches-2.8/src/osg/OperationThread.cpp:413 #10 0xb7ddc117 in osg::GraphicsThread::run (this=0x80c6fc8) at /home/melis/c/osg/svn/branches-2.8/src/osg/GraphicsThread.cpp:38 #11 0xb792e1bd in OpenThreads::ThreadPrivateActions::StartThread (data=0x80c6fd4) at /home/melis/c/osg/svn/branches-2.8/src/OpenThreads/pthreads/PThread.c++:170 #12 0xb791818b in start_thread () from /lib/libpthread.so.0 #13 0xb79f409e in clone () from /lib/libc.so.6 I'm not modifying the text in the viewer loop, it's all set up before the viewer is even constructed. I'm not using ref_ptr because everything is constructed in main(), is that the problem here? Okay, I added ref_ptr's and now indeed the crash doesn't seem to occur anymore. However, the empty line bug remains. The behaviour described isn't some sort of feature is it? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Server migration
Jose Luis Hidalgo wrote: HI All, The migration is beta-completed, we need now to test it and fix the errors that surely will arise. As I've previously told you there is no more OSG user to make changes on the wiki, now everybody should register itself (but please do not use the e-mail feature, currently the server doesn't send messages and your account won't be active). For those who had a subversion account your username/password is the same on Trac, now users from trac and subversion share the same database (that will make easier to grant svn access in the future). beta.openscenegraph.org takes me to http://www.openscenegraph.org/projects/osg, which shows it's running trac 0.9.6 which doesn't sound right as I saw 0.11 previously. So how do I access the new site? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
