Re: [osg-users] osgdem produces strips
Hi Robert; I read all your advice which you wrote before! But always the result is only strips! At the and I give up but your last message take me a last hope to do this database :) As you say, I downloaded the VPB with svn before! And I download again,now it is working:) If anyone see my previous results like only strips! You only download the png texture and its elevation mode from http://www.cc.gatech.edu/projects/large_models/ps.html . Then use this sample commands; gdal_translate ps_height_??k.png ps_height_??k.tif gdaladdo -r average ps_height_??k.tif 2 4 8 16 32 gdal_translate ps_texture_??k.png ps_texture_??k.tif gdaladdo -r average ps_texture_??k.tif 2 4 8 16 32 osgdem --xx 10 --yy 10 -t ps_texture_??k.tif --xx 10 --yy 10 -d ps_height_??k.tif -l 4 -v 0.1 -o puget.ive -a pegout.osga and then you run osgviewer pegout.osga, you should see good vertices on the images :D Thank you very much Robert! We are waiting of 2.4 Version impatiently! Ümit UZUN Date: Thu, 13 Dec 2007 18:34:09 + From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgdem produces strips Hi ümit, On Nov 19, 2007 11:48 AM, ümit uzun wrote: Hi Robert; I used ; osgdem --xx 10 --yy 10 -t ps_texture_1k.tif \ --xx 10 --yy 10 -d ps_height_1k.tif \ -l 8 -v 0.1 -o puget.ive -a pegout.osga options like in introductions. Is there any simple example about vpb? I aim to make flight simulation, I have plane model and I only want to environment database with osga! I have just tracked down a bug in the SVN version of VPB that was causing problems in handling the --xx etc definition of coordinate systems in osgdem. An svn update update of OpenSceneGraph and VirtualPlanetBuilder will fix this bug, so the above settings should work once more. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Windows Live Messenger'ın için Ücretsiz 30 İfadeyi yükle http://get.live.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgIntrospection: areArgumentsCompatible() issue
Hi Manu,
You right :-).
I think in the introspection concept implemented by Marco Jez, If you use a
getCompatibleConstructor(...) or other low-level method in osgIntrospection,
you have to know the API as same as you write your code without
introspection.
David
2007/12/13, Emmanuel Roche [EMAIL PROTECTED]:
Hi there !
in the osgIntropsection framework, we use getCompatibleConstructor(...) or
getCompatibleMethod(...), etc... to get a function considering the
parameters offered. But it this process do the framework take into account
the possible implicit parameter constructions ?
I tried to check the sources, and as far as I understand, everything would
happen in the function if it was the case (for example for the implicit
convertion of a const char* object to std::string):
bool Reflection::accum_conv_path(const Type source, const Type dest,
ConverterList conv, std::vectorconst Type* chain, CastType castType)
{
// break unwanted loops
if (std::find( chain.begin(), chain.end(), source) != chain.end())
return false;
// store the type being processed to avoid loops
chain.push_back(source);
// search a converter from source
StaticData::ConverterMapMap::const_iterator i =
getOrCreateStaticData().convmap.find(source);
if (i == getOrCreateStaticData().convmap.end())
return false;
// search a converter to dest
const StaticData::ConverterMap cmap = i-second;
StaticData::ConverterMap::const_iterator j = cmap.find(dest);
if (j != cmap.end() (j-second-getCastType() == castType))
{
conv.push_back(j-second);
return true;
}
// search a undirect converter from source to ... to dest
for (j=cmap.begin(); j!=cmap.end(); ++j)
{
if ((j-second-getCastType() == castType)
accum_conv_path(*j-first, dest, conv, chain, castType))
{
conv.push_front(j-second);
return true;
}
}
return false;
}
... but I can't see anything concerning the type constructors here, so I
guess that to call a function you need to pass the exact type of parameter
needed (with an exception for the derived classes, and inheritance system),
for example:
with the function void myfunc(std::string arg1, osg::Node* obj)
the reflection framework would find a compatible method with the arguments
: { std::string(test) , and osg::Group* myGroup } but it won't find
anything with the pair { test, osg::Node* myNode }... Am I wrong ??
regards,
Manu.
___
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] help
Hi all: I have been using OSG for couples of days. But recently, I am confused by the management of Environment Variables. Here, I found this class seemed very useful: class OSG_EXPORT ApplicationUsage : public osg::Referenced Well, it seemed arranging all the variables clearly. But I also found the following using way here and there: getenv(OSG_COMPUTE_NEAR_FAR_MODE)) getenv( OSG_LIBRARY_PATH) getenv( OSG_LD_LIBRARY_PATH) All these variables are not exist in my System Environment Variable. So I suppose it should be the following one: osg::ApplicationUsage::instance()-getEnvironmentalVariables[ByName]( const std::string str ) But this function getEnvironmentalVariables[ByName] is not exist. So I wonder why. Maybe ApplicationUsage is being in the process of dealing? Anyone can help me? Thanks very much. Yours sincerely, Leven [EMAIL PROTECTED] 07-12-24 - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
HI Paul, I have just run osgviewer on my Linux box and the fonts are the original size. I wonder if this is a new cross platform issue introduced by David's work on Text3D, or something associated with use of the newer freetype library, or perhaps the fonts at your end have somehow changed. Is anyone else seeing this issue with the SVN version of the OSG? Robert. On Dec 13, 2007 8:11 PM, Paul Martz [EMAIL PROTECTED] wrote: Current SVN head seems to have extra-large screen oriented fonts. See the attached screen shots. This is on Windows VS8; don't know about other platforms? I get the same for screen oriented fonts in the osgtext example. While my failing eyesight certainly appreciates the increased font size, I can't help but think this is a bug. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ 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] help
Hi Leven, The OSG's use of environmental variables is purely an optional way of setting default values that various classes wish to expose to outside control. The ApplicationUsage::instance() is just a class used the collect the details on the env variables that the OSG can use, is just a fulfills a documentation role, it's not active at all in terms of checking env vars - this instead is the role of the individual classes. The easiest way to use the list of supported env vars is to do: osgviewer --help-env Which lists the env vars supported. On the command line you can use this like: export OSG_STEREO=ON osgviewer cow.osg Use set instead of export under Windows. Robert. On Dec 14, 2007 9:33 AM, leven [EMAIL PROTECTED] wrote: Hi all: I have been using OSG for couples of days. But recently, I am confused by the management of Environment Variables. Here, I found this class seemed very useful: class OSG_EXPORT ApplicationUsage : public osg::Referenced Well, it seemed arranging all the variables clearly. But I also found the following using way here and there: getenv(OSG_COMPUTE_NEAR_FAR_MODE)) getenv( OSG_LIBRARY_PATH) getenv( OSG_LD_LIBRARY_PATH) All these variables are not exist in my System Environment Variable. So I suppose it should be the following one: osg::ApplicationUsage::instance()-getEnvironmentalVariables[ByName]( const std::string str ) But this function getEnvironmentalVariables[ByName] is not exist. So I wonder why. Maybe ApplicationUsage is being in the process of dealing? Anyone can help me? Thanks very much. Yours sincerely, Leven [EMAIL PROTECTED] 07-12-24 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ___ 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] osgHUD 0.1.1 ALPHA
Jeremy, I am very keen on experimenting with your HUD. However, as a Windows/VisC++ 7.1 user, I have a lot of difficulty with the code. I'm not a cross-platform expert, so I have difficulty in knowing how to simultaneously specify a windows and linux acceptable build. I can submit my stuff to you, but don't know how useful it will be. I did the following: Minor points: 1) Constructions like not and and or aren't recognised by MS .NET 7.1out of the box; I had to replace them all with !, etc. 2) uint isn't recognised either; I replaced it with unsigned int 3) std::sort wants #include algorithm 4) I need to link to osgText, osgDB and osgGA to build; these aren't in any of the project files 5) osgHUD::UIObjectParentosgHUD::Widget::getByName is reported as being recursive, similar with osgHUD::Widget::getWindowManager Major points: I added the usual windows exports header file, something like this: #ifndef WIN32_LEAN_AND_MEAN #define WIN32_LEAN_AND_MEAN #endif #include windows.h #ifdef osgHUD_EXPORTS #define HUD_API __declspec(dllexport) #else #define HUD_API __declspec(dllimport) #endif and then declare every DLL exported class, and things like createOrthoCamera(), with HUD_API. This all then works OK, and all the exes run just fine. I haven't managed to review the code yet. We have an in-house HUD system which I would like to lever on to yours for future use; this may throw up some design issues when I do it (although it won't be for a while)... Hope that helps, David On 13/12/2007, Jeremy Moles [EMAIL PROTECTED] wrote: By the way: this also includes comments like, OMG THIS SUCKS LOL, if you're that kind of person... :) Not just positive feedback, so to speak. On Thu, 2007-12-13 at 12:19 -0500, Jeremy Moles wrote: Just wanted to give another heads up on the state of development and perhaps solicit some more feedback (which has been very small so far, seeing as there isn't much code yet--only about 2100 lines). There is an SVN tag of 0.1.1, and a new tarball in the downloads section. http://code.google.com/p/osghud/downloads/list All the normal stuff applies (seriously alpha, blah, blah), but I'm interested in getting opinions and perhaps having people catch any bad design decisions I'm making before it's too late. The biggest differences in this from the version from last week is a great deal of code simplification and the addition of a small skeleton for a table-like layout (osgHUD::Table). In the next 0.1.2 testing release I'm aiming to add support for basic texturing. However, it's an issue I need to approach carefully, because it can really start to go wrong here. :) Remember to set OSG_WINDOW before running the examples. # OSG_WINDOW=0 0 1280 1024 osghudtable ...or else you'll need to modify the examples to use your fullscreen resolution in the 2D ortho camera for picking, moving, etc. to work as you might expect. Don't let the simple examples fool you! :) They (ideally) demonstrate the important stuff, even if they're horribly ugly at the moment. ___ 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] What was reasoning behind OSG Z up axis
On Dec 13, 2007 9:03 PM, etrek [EMAIL PROTECTED] wrote: In OpenGL Y axis is up ( world and view ). In DirectXY axis is up ( world and view ). They define Y up in *eye* coordinates. The modelview matrices put you into eye coordinates, of which must be standardised. They don't actually say anything about the coordinates of the world, this is what the inverse of the view transform defines. The two most popular graphics API's consider Y axis as up. So do most Graphics texts like Foley et al. OSG uses OpenGL as its graphics API, so why not use the same coord system? Just curious as to the reasoning behind this design decision. The OSG is built around the concept of worlds coordinates rather than eye coordinates - its about creating virtual worlds, which in turn have a counter part in the real world and in the real-world (disciplines beyond computer graphics) one generally to X going east, Y going north, Z going up. Z is most commonly up and refers to height. Not surprisingly the vis-sim market grew up around this too rather than getting fixated on eye coordinates being akin world coordinates... For me one of the key things in grasping real-time computer graphics is to get a handle on the ideal of different coordinate frames - world coordinate and eye coordinates being two different coordinate frames used for two different things. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] retrieving SceneView and contextID()
HI Michale, The ContextID is associated with GraphicsContext's, and its the Viewer's Camera's that hold the GraphicsContext (normally a GraphicsWindowsX11/Win32/Carbon subclass), and each GraphicsContext has the State object, each of which has the ContextID so on can do: viewer.getCamera()-getGraphicsContext()-getState()-getContextID(); Or if the viewer's master Camera doesn't have a GraphicsContext, instead it delegates the rendering to its slaves then you'll need to iterator through the slave Camera's to get the ContextID. There is a viewer.getContexts(osgViewer::ViewerBase::Contexts) convinience method to help you get the lists of all the active graphics contexts, so you could easily use this instead of iterating through. And... not once did you need to grapple with the internal implementation of SceneView that is used the hood. But if you really really must grapple then the Camera::getRenderer() will give you the Renderer that is used to do the rendering - and its this osgViewer::Renderer that has the SceneView that does all the internal work. Robert. On Dec 13, 2007 9:52 PM, Michele Bosi [EMAIL PROTECTED] wrote: Hello, I need to retrieve the current contextID or the contextID that a Viewer is working on, how do I do it? I saw in the documentation that one should retrieve the SceneView but it doesn't say how / from where, and I couldn't figure it out, as far a I could see osg::View and its subclasses doesn't have such a getSceneView() method or similar. I saw that there were some posts about how to retrieve the context from a camera but that seemed to be more of an hack than the actual standard way so if possible I would like to avoid that solution. So, what is the clean and mean way of retrieving the SceneView given an osgViewer::Viewer? Regards, Michele ___ 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] What was reasoning behind OSG Z up axis
[Controversial mode on] I think a better question to ask would be. How consistent are all osg's plugins at enforcing osg's stated z up world convention? I would expect all the plugins that knew the default orientation of an external model either by convention or by data, to ensure that models where rotated to z_up on input and from z_up on output. I am just wondering ;-) Just to start the ball rolling Plugin Enforces == Osg yes Ive yes Dae no Ac no Roger -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 14 December 2007 10:04 To: OpenSceneGraph Users Subject: Re: [osg-users] What was reasoning behind OSG Z up axis ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What was reasoning behind OSG Z up axis
Hi Roger, Which way is up for the plugins can be plugin specific, but it can also be down to individual modeller and the convention they use. For instance terrapage and OpenFlight you can pretty well guarantee that they'll come in Z up as that the convention used in the modelling programs and the industry they are tied to. With other modelling packages the convention is often far less regulated. My guess systems that deal with whole worlds rather than individual artifacts will be more regulated in orientation. Robert. On Dec 14, 2007 11:00 AM, Roger James [EMAIL PROTECTED] wrote: [Controversial mode on] I think a better question to ask would be. How consistent are all osg's plugins at enforcing osg's stated z up world convention? I would expect all the plugins that knew the default orientation of an external model either by convention or by data, to ensure that models where rotated to z_up on input and from z_up on output. I am just wondering ;-) Just to start the ball rolling Plugin Enforces == Osg yes Ive yes Dae no Ac no Roger -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 14 December 2007 10:04 To: OpenSceneGraph Users Subject: Re: [osg-users] What was reasoning behind OSG Z up axis ___ 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] readFontFile possible bug
Hi Sherman, I have tried out your modified osgtext example with the --mt 5 etc option along with a 8GB whole earth database and find the frame rate stalling, especially when zooming in to new high res regions. Running with on screen stats on suggests that its the GPU that is stalling things, with a single frame taking a very long time, then once its freed up the app runs freely once more with millisceond GPU times. I've put timing code into the UpdateTextOperation and neither the load nor update methods take very long most of the time, and there isn't a big hit here when the stall happen so it doesn't seem to be directly associated with the extra threads running. I haven't been able to establish the exact cause of stalls, but it looks to be an issue with the newly introduced subgraphs forcing compile of texture objects/display lists in such a way that the OpenGL driver/GPU is stalling. The texture sizes associated with osgText shouldn't be very large so the bandwidth and memory footprint shouldn't be a bottleneck, clearly something is happening down in the OpenGL fifo/GPU that is causing major problems and stalling things. One thing it doesn't look like is a threading issue, my guess running the UpdateTextOperation synchronously i.e. from the main loop would probably see the same big hits on the GPU, although perhaps doing it synchronously would regulate the amount of new data added in a subgraph per frame. Getting to the bottom of this issue will take digging down into draw dispatch, and probably adding things like GPU stats collection to the osgText::Text/Font rendering methods as well as osg::Texture texture subloading. I would suggest opening a different thread into investigations of these GPU stall issues, as it would seem so far the multi-threaded font crashes/bugs look resolved and this thread can be closed. Robert, On Dec 14, 2007 12:58 AM, sherman wilcox [EMAIL PROTECTED] wrote: OK, grabbed the latest copy of OSG out of SVN (latest as of about 2PM today) and ran my test app again. With the latest OSG the app doesn't crash, but there are still major issues. So, the multi-threading issue is still there. The database pager simply stops working, I get all manner of errors in the console window, etc. I've attached the test app. Should compile in linux, windows, etc. If you run this app, you will need a paged database to really stress things. I have one (about 148MB compressed) that I can provide if anyone is interested. Just email me and I'll provide a link to download. Oh, and be sure to pass the app an argument of --mt 5, where 5 is the number of test threads to launch, can be any reasonable number. On Dec 12, 2007 10:21 PM, sherman wilcox [EMAIL PROTECTED] wrote: I spent a bit of time this evening digging up the the code that reproduces the crash. I'll update to the SVN snapshot of OSG and give it a try. I was able to reproduce the crash on 2.2.0. On Dec 12, 2007 4:22 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, On Dec 11, 2007 11:31 PM, sherman wilcox [EMAIL PROTECTED] wrote: I can still reliably reproduce the multithreaded osgText / databasepager crash issue :) Could you explain how your recreate the crash, and the circumstances of the crash. It may be exactly the same problem as Serge has, but also just as easily could be another weakness that needs solving. Aaa you gotta love debugging multi-threaded apps remotely :-) 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] Big fonts in current SVN
Hello All: I feel like I have seen this befor on a windows build I did several months ago. I think I was using a system installed font on windows and not the font that comes in the OSG data path. When I used the OSG data path font everything is OK. Sorry if this doesn't help much. Take care Garrett On Dec 14, 2007, at 5:24 AM, Robert Osfield wrote: HI Paul, I have just run osgviewer on my Linux box and the fonts are the original size. I wonder if this is a new cross platform issue introduced by David's work on Text3D, or something associated with use of the newer freetype library, or perhaps the fonts at your end have somehow changed. Is anyone else seeing this issue with the SVN version of the OSG? Robert. On Dec 13, 2007 8:11 PM, Paul Martz [EMAIL PROTECTED] wrote: Current SVN head seems to have extra-large screen oriented fonts. See the attached screen shots. This is on Windows VS8; don't know about other platforms? I get the same for screen oriented fonts in the osgtext example. While my failing eyesight certainly appreciates the increased font size, I can't help but think this is a bug. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ 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] retrieving SceneView and contextID()
Thank you very much to everyone for the replies, now the situation is much clearer and I think I can solve my problem which by the way is (should be) very easy, that is I need the context id simply to pass it to some function that check the support for extensions like point sprite. I am going to have multiple opengl windows but on simple systems, with one card, one monitor, so checking for the supported extensions in one context should be valid for all the others. Thank you again, Michele On Dec 14, 2007 11:14 AM, Robert Osfield [EMAIL PROTECTED] wrote: HI Michale, The ContextID is associated with GraphicsContext's, and its the Viewer's Camera's that hold the GraphicsContext (normally a GraphicsWindowsX11/Win32/Carbon subclass), and each GraphicsContext has the State object, each of which has the ContextID so on can do: viewer.getCamera()-getGraphicsContext()-getState()-getContextID(); Or if the viewer's master Camera doesn't have a GraphicsContext, instead it delegates the rendering to its slaves then you'll need to iterator through the slave Camera's to get the ContextID. There is a viewer.getContexts(osgViewer::ViewerBase::Contexts) convinience method to help you get the lists of all the active graphics contexts, so you could easily use this instead of iterating through. And... not once did you need to grapple with the internal implementation of SceneView that is used the hood. But if you really really must grapple then the Camera::getRenderer() will give you the Renderer that is used to do the rendering - and its this osgViewer::Renderer that has the SceneView that does all the internal work. Robert. On Dec 13, 2007 9:52 PM, Michele Bosi [EMAIL PROTECTED] wrote: Hello, I need to retrieve the current contextID or the contextID that a Viewer is working on, how do I do it? I saw in the documentation that one should retrieve the SceneView but it doesn't say how / from where, and I couldn't figure it out, as far a I could see osg::View and its subclasses doesn't have such a getSceneView() method or similar. I saw that there were some posts about how to retrieve the context from a camera but that seemed to be more of an hack than the actual standard way so if possible I would like to avoid that solution. So, what is the clean and mean way of retrieving the SceneView given an osgViewer::Viewer? Regards, Michele ___ 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] Development-system for Mac-OS
Ugh, that's one of the nasty Leopard bugs documented on the Wiki. We managed to sidestep this in the Xcode project by removing extra/unnecessary link dependencies and by properly adhering to SDK rules. CMake's SDK support is still a bit shaky (something we're trying to work on). But if you're lucky, you might still be able to sidestep it in CMake too by removing any extra/unnecessary link dependencies in building the freetype plugin. Or, you can follow the Wiki solution and add the required link line to the build. -Eric On 12/13/07, Gerrick Bivins [EMAIL PROTECTED] wrote: What is the the suggested method to fix the build(ie avoid linking errors) on OSX 10.5 with CMake?Our app doesn't use frameworks etc so I run into the freetype linking error during compile. I'm not all that familiar with CMake so other than setting the couple of freetype path variables in the ccmake gui, I don't know where to tweek the build so that it picks up the correct libs. As a side note, I upgrade from Tiger to Leopard rather than a new install. I'm running on a fairly new mbp (received in oct). Here is the exact error: [ 86%] Built target osgdb_qt Linking CXX shared module ../../../lib/osgPlugins-2.2.0/osgdb_freetype.so ld: cycle in dylib re-exports with /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/libGL.dylib for architecture i386 collect2: ld returned 1 exit status ld: cycle in dylib re-exports with /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/libGL.dylib for architecture ppc collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/m2/m2u1oBxxGAqUxi2h7sbDKTI/-Tmp-//ccWn7pVI.out (No such file or directory) make[2]: *** [lib/osgPlugins-2.2.0/osgdb_freetype.so] Error 1 make[1]: *** [src/osgPlugins/freetype/CMakeFiles/osgdb_freetype.dir/all] Error 2 make: *** [all] Error 2 [EMAIL PROTECTED]/devEnv/research/APIs/OpenSceneGraph_svn$ biv On Dec 13, 2007 1:01 AM, Andreas Goebel [EMAIL PROTECTED] wrote: E. Wing schrieb: In my opinion, you are best off getting Leopard. Apple will not be updating OpenGL drivers for Tiger from this point on. Working OpenGL drivers is by far the most important aspect in my opinion. Thank you all, I summarize: I´d (probably) be best of with: - Mac OS 10.5 - but use 10.4 sdk to target both 10.4 and 10.5 right? I know that the slogan is think different, so that´s what I´ll have to do ... Regards, Andreas ___ 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] What was reasoning behind OSG Z up axis
You are spot on there Robert. Most of the plugins result in a Z up model on input because they pass the vertex data through unchanged from their native Z up environment. The only one I know from memory that does a flip is the obj loader although that can be suppressed by a noRotation option. Does anyone know of any others? Would it be a good idea if I put static transforms in the ac and dae plugins which are by default Y up and had this behaviour controlled by a noRotation parameter? This could be made standard across other plugins that know when their data is not Z up. Users (like me) who have viewing environments that are Y up by default could then have the option to specify that parameter and avoid having to put in an extra transform to flip the models back to their original orientation. Ah well maybe next year! Roger -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 14 December 2007 11:30 To: OpenSceneGraph Users Subject: Re: [osg-users] What was reasoning behind OSG Z up axis Hi Roger, Which way is up for the plugins can be plugin specific, but it can also be down to individual modeller and the convention they use. For instance terrapage and OpenFlight you can pretty well guarantee that they'll come in Z up as that the convention used in the modelling programs and the industry they are tied to. With other modelling packages the convention is often far less regulated. My guess systems that deal with whole worlds rather than individual artifacts will be more regulated in orientation. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDB\readerwriter header typo
In the osgDB\readerwriter header there's a copypaste error. The comment for the CACHE_ARCHIVES option is the same as for CACHE_HEIGHTFIELDS. I'm not sure what archives are so I've not made a change. Joseph Steel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
On Dec 14, 2007 2:05 PM, Paul Martz [EMAIL PROTECTED] wrote: Thanks all. I don't think it's an issue with fonts on my system because the 2.2 and SVN screenshots were both captured on the same system. Double check this assertion, use OSG_NOTIFY_LEVEL set to DEBUG to find out which fonts have been loaded in each case. Do they use the same version of freetype? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
Hello Robert, Is anyone else seeing this issue with the SVN version of the OSG? My last update was yesterday, and I don't see anything wrong with the font size... I'll try to update now and see. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgHUD 0.1.1 ALPHA
First of all, thanks a ton for the feedback! :) Keep reading below... On Fri, 2007-12-14 at 10:32 +, David Spilling wrote: Jeremy, I am very keen on experimenting with your HUD. However, as a Windows/VisC++ 7.1 user, I have a lot of difficulty with the code. I'm not a cross-platform expert, so I have difficulty in knowing how to simultaneously specify a windows and linux acceptable build. I can submit my stuff to you, but don't know how useful it will be. I did the following: Minor points: 1) Constructions like not and and or aren't recognised by MS .NET 7.1 out of the box; I had to replace them all with !, etc This is pretty frustrating, because I'm about 99% sure these are acceptable C++ keywords. They look about a thousand times better in the code, but if Windows won't support them I'll drop their usage. I build with both GCC and ICC (Intel's compiler), all warnings turned on, and neither of them have ever complained about this... 2) uint isn't recognised either; I replaced it with unsigned int Whoops, I knew this but it looks like I left out 2 instances. :( 3) std::sort wants #include algorithm Fixed. 4) I need to link to osgText, osgDB and osgGA to build; these aren't in any of the project files Fixed. 5) osgHUD::UIObjectParentosgHUD::Widget::getByName is reported as being recursive, similar with osgHUD::Widget::getWindowManager Hmm, weird. I've introduced an alternative implementation. It's necessary to have const and non const version of these functions though, and I really don't want to have the exact same code copy/pasted. Major points: I added the usual windows exports header file, something like this: #ifndef WIN32_LEAN_AND_MEAN #define WIN32_LEAN_AND_MEAN #endif #include windows.h #ifdef osgHUD_EXPORTS #define HUD_API __declspec(dllexport) #else #define HUD_API __declspec(dllimport) #endif and then declare every DLL exported class, and things like createOrthoCamera(), with HUD_API. This all then works OK, and all the exes run just fine. Fixed (but using OSG_EXPORT instead). The WIN32_LEAN_AND_MEAN thing may appear somewhere else in OSG, I'm not sure... I haven't managed to review the code yet. We have an in-house HUD system which I would like to lever on to yours for future use; this may throw up some design issues when I do it (although it won't be for a while)... Hope that helps, Yes, very much. :) Can you try the new version I've put up with your changes (0.1.2) and let me know if it compiles on Windows okay without you having to modify too much? If I missed anything, let me know... David On 13/12/2007, Jeremy Moles [EMAIL PROTECTED] wrote: By the way: this also includes comments like, OMG THIS SUCKS LOL, if you're that kind of person... :) Not just positive feedback, so to speak. On Thu, 2007-12-13 at 12:19 -0500, Jeremy Moles wrote: Just wanted to give another heads up on the state of development and perhaps solicit some more feedback (which has been very small so far, seeing as there isn't much code yet--only about 2100 lines). There is an SVN tag of 0.1.1, and a new tarball in the downloads section. http://code.google.com/p/osghud/downloads/list All the normal stuff applies (seriously alpha, blah, blah), but I'm interested in getting opinions and perhaps having people catch any bad design decisions I'm making before it's too late. The biggest differences in this from the version from last week is a great deal of code simplification and the addition of a small skeleton for a table-like layout (osgHUD::Table). In the next 0.1.2 testing release I'm aiming to add support for basic texturing. However, it's an issue I need to approach carefully, because it can really start to go wrong here. :) Remember to set OSG_WINDOW before running the examples. # OSG_WINDOW=0 0 1280 1024 osghudtable ...or else you'll need to modify the examples to use your fullscreen resolution in the 2D ortho camera for picking, moving, etc. to work as you might expect. Don't let the simple examples fool you! :) They (ideally) demonstrate the important stuff, even if they're horribly ugly at the moment. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users
Re: [osg-users] Big fonts in current SVN
Double check this assertion, use OSG_NOTIFY_LEVEL set to DEBUG to find out which fonts have been loaded in each case. Good idea. This shows that 2.2 (correct size) and SVN head (large size) are both loading the same font file: OpenSceneGraph-Data\fonts\arial.ttf. Do they use the same version of freetype? They are different versions. Current SVN head's FreeType plugin won't link against the older version of freetype I had been using previously. Here are the versions I'm using: My SVN head binaries use FreeType 2.3.5 My 2.2 binaries use FreeType 2.1.9 J-S -- Understand you don't see the same issue. What version of FreeType are you using? (And please confirm you're on Windows VS8.) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
Hello, Is anyone else seeing this issue with the SVN version of the OSG? My last update was yesterday, and I don't see anything wrong with the font size... I'll try to update now and see. Nope, still no problem... Sorry to not be of any help, Paul. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Showing aircraft model with terrain!
Hi All; First of all I want to make a very simple flight simulator; I have Portland terrain which I download from http://www.openeaagles.com/visualdb.html; sites. It produced by terrapage. When I try to open it instead of JoeDirt.flt in NPS tutorial with tank, it is open but after a second the tank get invisible! Why ? Second question; I have a aircraft model and I can rotate around of it. My tree like this; mRoot mLightGroup mLightSource mLight mModelGroup mTransform (osg::MatrixTransform) mModel (aircraft model .osg) As you see, my aircraft could rotated with osg::MatrixTransform functions by user. I couldn't find out where should I XXX.addchild(mTerrainNode) my terrain! I try a lot of combination but anytime the terrain didn't appear on the screen with aircraft! What is wrong? I am using mTerrainNode = osgDB::readNodeFile( mTerrainPathName ); function to read. Should I use different class or namespace to read or manipulate? Please help me! Thank a lot! _ Windows Live Messenger'ın için ücretsiz güncelleştirme! http://get.live.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
Hello Paul, J-S -- Understand you don't see the same issue. What version of FreeType are you using? (And please confirm you're on Windows VS8.) My environment seems to be very similar to yours: - Freetype 2.3.5 (from Mike's 3rdParty SVN) - Windows Vista Ultimate 32bit (possibly one difference, but shouldn't be significant here) - Visual Studio 8. At home, I'm using the same freetype, Windows XP SP2 and Visual C++ Express 2005, and it seems normal as well. Though I haven't really checked the size in pixels, but the glyphs don't overlap the stats display as they did in your screenshot. Sorry... J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] readFontFile possible bug
Robert, I'm not so sure the multi-threading issue is resolved. I wasn't getting simple GPU stalls. The database pager would stop working after several of these stalls. By stop working I don't mean interruptions with resumption. That database pager would not come back at all. Also, the log messages to screen was strange. Some were garbled messages and mentioned that it could no longer find plugins, etc. The inability to find plugins could explain the database pager, but the question then becomes why does running background threads dump plugins and trash log output? On Dec 14, 2007 5:25 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, I have tried out your modified osgtext example with the --mt 5 etc option along with a 8GB whole earth database and find the frame rate stalling, especially when zooming in to new high res regions. Running with on screen stats on suggests that its the GPU that is stalling things, with a single frame taking a very long time, then once its freed up the app runs freely once more with millisceond GPU times. I've put timing code into the UpdateTextOperation and neither the load nor update methods take very long most of the time, and there isn't a big hit here when the stall happen so it doesn't seem to be directly associated with the extra threads running. I haven't been able to establish the exact cause of stalls, but it looks to be an issue with the newly introduced subgraphs forcing compile of texture objects/display lists in such a way that the OpenGL driver/GPU is stalling. The texture sizes associated with osgText shouldn't be very large so the bandwidth and memory footprint shouldn't be a bottleneck, clearly something is happening down in the OpenGL fifo/GPU that is causing major problems and stalling things. One thing it doesn't look like is a threading issue, my guess running the UpdateTextOperation synchronously i.e. from the main loop would probably see the same big hits on the GPU, although perhaps doing it synchronously would regulate the amount of new data added in a subgraph per frame. Getting to the bottom of this issue will take digging down into draw dispatch, and probably adding things like GPU stats collection to the osgText::Text/Font rendering methods as well as osg::Texture texture subloading. I would suggest opening a different thread into investigations of these GPU stall issues, as it would seem so far the multi-threaded font crashes/bugs look resolved and this thread can be closed. Robert, On Dec 14, 2007 12:58 AM, sherman wilcox [EMAIL PROTECTED] wrote: OK, grabbed the latest copy of OSG out of SVN (latest as of about 2PM today) and ran my test app again. With the latest OSG the app doesn't crash, but there are still major issues. So, the multi-threading issue is still there. The database pager simply stops working, I get all manner of errors in the console window, etc. I've attached the test app. Should compile in linux, windows, etc. If you run this app, you will need a paged database to really stress things. I have one (about 148MB compressed) that I can provide if anyone is interested. Just email me and I'll provide a link to download. Oh, and be sure to pass the app an argument of --mt 5, where 5 is the number of test threads to launch, can be any reasonable number. On Dec 12, 2007 10:21 PM, sherman wilcox [EMAIL PROTECTED] wrote: I spent a bit of time this evening digging up the the code that reproduces the crash. I'll update to the SVN snapshot of OSG and give it a try. I was able to reproduce the crash on 2.2.0. On Dec 12, 2007 4:22 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, On Dec 11, 2007 11:31 PM, sherman wilcox [EMAIL PROTECTED] wrote: I can still reliably reproduce the multithreaded osgText / databasepager crash issue :) Could you explain how your recreate the crash, and the circumstances of the crash. It may be exactly the same problem as Serge has, but also just as easily could be another weakness that needs solving. Aaa you gotta love debugging multi-threaded apps remotely :-) 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INHERIT_RENDERBIN_DETAILS
Hi John -- Can you post an .osg file that demonstrates the problem in osgviewer? -Paul Robert, We are using getOrCreateStateSet()-setRenderBinDetails. What we have is this: osg::group1-osg::group2-osg::group3-osg::geode-osg::geomet ry, where group3 contains multiple geode-geometry children. group3 has setRenderBinDetails called without specifying INHERIT_RENDERBIN_DETAILS, Which means it is setting to USE_RENDERBIN_DETAILS by default, correct? geode has setRenderBinDetails called, specifying INHERIT_RENDERBIN_DETAILS. None of the other stuff has renderbin details set in the statesets, HOWEVER, there may be other statesets in the chain that do exist (I call getOrCreate). Maybe they all exist regardless of whether I call getOrCreate, but I am not sure of this. The geode/geometry subtrees also have a texture associated with them. They also have GL_DEPTH_TEST disabled, so that we should see the most recently drawn (highest renderbin #) when two geometries overlap or would normally conceal one another. This is not what's happenning however. Any ideas why this might be the case? I have been over the code and I'm quite sure that I've described the situation more accurately. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INHERIT_RENDERBIN_DETAILS
Robert, We are using getOrCreateStateSet()-setRenderBinDetails. What we have is this: osg::group1-osg::group2-osg::group3-osg::geode-osg::geometry, where group3 contains multiple geode-geometry children. group3 has setRenderBinDetails called without specifying INHERIT_RENDERBIN_DETAILS, Which means it is setting to USE_RENDERBIN_DETAILS by default, correct? geode has setRenderBinDetails called, specifying INHERIT_RENDERBIN_DETAILS. None of the other stuff has renderbin details set in the statesets, HOWEVER, there may be other statesets in the chain that do exist (I call getOrCreate). Maybe they all exist regardless of whether I call getOrCreate, but I am not sure of this. The geode/geometry subtrees also have a texture associated with them. They also have GL_DEPTH_TEST disabled, so that we should see the most recently drawn (highest renderbin #) when two geometries overlap or would normally conceal one another. This is not what's happenning however. Any ideas why this might be the case? I have been over the code and I'm quite sure that I've described the situation more accurately. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 12, 2007 2:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] INHERIT_RENDERBIN_DETAILS Hi John I'm afraid there is too little info provided to know what might be up and how to fix it. StateSet::RenderBinDetails is what should be used to control overall draw order, but you make not mention of this. Robert. On Dec 12, 2007 7:08 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Hello all. We are using inherit renderbin details to assign a nested set of priorities. We have a group node with a top-level priority which contains several geodes with priorities using the inherit flag. Each of the geodes has a textured polygon geometry. We want to have the polygons depth test disabled and drawn in a certain order so that they will show the last drawn on top. OSG is not drawing these in order as it should. Any ideas what the problem might be? We haven't used the override renderbin details flag anywhere, so it is bizarre that things are happening this way. We can turn on blending and lower the alphas and see that both our polygons are there. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INHERIT_RENDERBIN_DETAILS
Paul, That's not so easy to do, but I will try to create an osgViewer app that hard-codes a scenegraph that duplicates the behaviors we're seeing over the weekend so I can provide the osg file. Right now we are using osgUtil::SceneViews, and not osgViewer. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, December 14, 2007 11:20 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] INHERIT_RENDERBIN_DETAILS Hi John -- Can you post an .osg file that demonstrates the problem in osgviewer? -Paul Robert, We are using getOrCreateStateSet()-setRenderBinDetails. What we have is this: osg::group1-osg::group2-osg::group3-osg::geode-osg::geomet ry, where group3 contains multiple geode-geometry children. group3 has setRenderBinDetails called without specifying INHERIT_RENDERBIN_DETAILS, Which means it is setting to USE_RENDERBIN_DETAILS by default, correct? geode has setRenderBinDetails called, specifying INHERIT_RENDERBIN_DETAILS. None of the other stuff has renderbin details set in the statesets, HOWEVER, there may be other statesets in the chain that do exist (I call getOrCreate). Maybe they all exist regardless of whether I call getOrCreate, but I am not sure of this. The geode/geometry subtrees also have a texture associated with them. They also have GL_DEPTH_TEST disabled, so that we should see the most recently drawn (highest renderbin #) when two geometries overlap or would normally conceal one another. This is not what's happenning however. Any ideas why this might be the case? I have been over the code and I'm quite sure that I've described the situation more accurately. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] ___ 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
Re: [osg-users] INHERIT_RENDERBIN_DETAILS
Paul, That's not so easy to do, but I will try to create an osgViewer app that hard-codes a scenegraph that duplicates the behaviors we're seeing over the weekend so I can provide the osg file. Right now we are using osgUtil::SceneViews, and not osgViewer. Hm. You should be able to just add a call to osgDB::writeNodeFile( foo.osg ) to your existing application and post the output here. You don't need to use osgViewer to do this. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What was reasoning behind OSG Z up axis
Random thoughts: COLLADA, in an attempt to address this common issue, does provide a flag to specify which axis to call up. For applying a static rotation, that was exactly the motivation for the .rot and .trans pseudoloaders: to adjust coordinate systems via data filenames rather than code or special flags in every plugin. Eg: osgviewer mydata.anyformat.0,0,-90.rot Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Roger James Sent: Friday, December 14, 2007 7:51 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] What was reasoning behind OSG Z up axis You are spot on there Robert. Most of the plugins result in a Z up model on input because they pass the vertex data through unchanged from their native Z up environment. The only one I know from memory that does a flip is the obj loader although that can be suppressed by a noRotation option. Does anyone know of any others? Would it be a good idea if I put static transforms in the ac and dae plugins which are by default Y up and had this behaviour controlled by a noRotation parameter? This could be made standard across other plugins that know when their data is not Z up. Users (like me) who have viewing environments that are Y up by default could then have the option to specify that parameter and avoid having to put in an extra transform to flip the models back to their original orientation. Ah well maybe next year! Roger -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 14 December 2007 11:30 To: OpenSceneGraph Users Subject: Re: [osg-users] What was reasoning behind OSG Z up axis Hi Roger, Which way is up for the plugins can be plugin specific, but it can also be down to individual modeller and the convention they use. For instance terrapage and OpenFlight you can pretty well guarantee that they'll come in Z up as that the convention used in the modelling programs and the industry they are tied to. With other modelling packages the convention is often far less regulated. My guess systems that deal with whole worlds rather than individual artifacts will be more regulated in orientation. 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] INHERIT_RENDERBIN_DETAILS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Moore wrote: Argentieri, John-P63223 wrote: osg::group1-osg::group2-osg::group3-osg::geode-osg::geometry, where group3 contains multiple geode-geometry children. ... If you want the geodes to be drawn in a relative order, you have to setRenderBinDetails on them too, with the appropriate number in the order. It doesn't sound like you're doing that. That wasn't very clear. I meant setRenderBinDetails on their StateSets. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHYrNyeDhWHdXrDRURAslbAKCLVDVxeZDhCaO+KVswRx2z9IrcagCgx9D7 LyYTkLKsUjonoAXMRWLKbfs= =KJUw -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Asynchronous file loading via DatabasePager questions
Hi all,
What I'm trying to do:
Asynchronous model loading using OSG 2.2
How I'm currently doing it:
I'm trying to use the Database Pager's requestNodeFile.
I created a new node class that I can add (as well as place temporary
objects) that I can add and will stay in the scene.
class DtDelayedModelNode : public osg::Group
{
...
DtDelayedModelNode(const std::string filename, osgDB::DatabasePager*
pager) : osg::Group()
{
osg::FrameStamp fs;
fs.setFrameNumber(INT_MAX);
pager-requestNodeFile(filename,this,1.0,fs);
}
...
};
Problems:
#1 Very limited documentation of the Pager class and no example on how
to use it. I've searched the osgusers archive but haven't found
anything too helpful, the 1.x examples don't seem relevant anymore.
#2 Occasional texture corruption. This is difficult to reproduce
however it appears that sometimes the width of the texture is 1px
creating a streaking effect.
#3 Certain actions cause the main app to lock, for example bringing up
the Stats HUD.
Questions:
Is the Database Pager the proper way to be doing this?
Are their any good examples using the Database Pager using OSG 2.x?
What if any calls should I make to the pager around frame() (ie it
doesn't appear that startFrame endFrame are needed, any other calls)?
The value of the frame stamp appears to control deletion of requests. Ie
if I pass in the current frame stamp, the model is actually deleted in
compileGLObjects. Unless I set it to some value in the future (currently
using INT_MAX) I can't guarantee it will load. Could someone explain the
purpose of the framestamp and the proper usage?
Is there anyway to get status feedback while a file loads?
Thanks,
Colin
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INHERIT_RENDERBIN_DETAILS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Argentieri, John-P63223 wrote: Robert, We are using getOrCreateStateSet()-setRenderBinDetails. What we have is this: osg::group1-osg::group2-osg::group3-osg::geode-osg::geometry, where group3 contains multiple geode-geometry children. group3 has setRenderBinDetails called without specifying INHERIT_RENDERBIN_DETAILS, Which means it is setting to USE_RENDERBIN_DETAILS by default, correct? geode has setRenderBinDetails called, specifying INHERIT_RENDERBIN_DETAILS. None of the other stuff has renderbin details set in the statesets, HOWEVER, there may be other statesets in the chain that do exist (I call getOrCreate). Maybe they all exist regardless of whether I call getOrCreate, but I am not sure of this. The geode/geometry subtrees also have a texture associated with them. They also have GL_DEPTH_TEST disabled, so that we should see the most recently drawn (highest renderbin #) when two geometries overlap or would normally conceal one another. This is not what's happenning however. Any ideas why this might be the case? I have been over the code and I'm quite sure that I've described the situation more accurately. If you want the geodes to be drawn in a relative order, you have to setRenderBinDetails on them too, with the appropriate number in the order. It doesn't sound like you're doing that. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHYrHBeDhWHdXrDRURAq0qAKDEB9PWXr85UIIdR6own7bIQTfA+QCg3ovt XfwXEcua0KfRfP4X/M5paIc= =vFy+ -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
Let me throw out some ideas, which Bob and I have discussed in the past and also mentioned here on osg-users... * The reference manual, as it stands today, contains some nice supplementary material, but in essence it's Doxygen output from the source code. We could beef up the source code comments for classes and functions, and contribute this back to osg-submissions. This would improve future versions of the ref man. This is a big job and seems worthwhile only if we focus our efforts on stable functionality. * The existing ref man documents osg, osgDB, and osgUtil. We could expand this series to include similar reference material for things like the NodeKits (osgText, osgSim, osgParticle), using OSG in windowing systems (osgViewer, osgManipulator, osgGA), etc. * We could embark on the much-promised and long-awaited Programming Guide. Again, this is a big job and only seems worthwhile if we focus our efforts on stable features. * We could spend time writing short whitepapers on various OSG topics, similar to Don's useful document on reference-counted memory. We could sell these as PDFs for a couple dollars a pop or something, depending on scope. Possible topics would include rendering order with RenderBins, deriving your own Nodes, Drawables, or StateAttributes, platform-specific topics, resolving build and installation issues, using the Geometry class, performance issues, etc etc, the list is essentially endless. * Any other suggestions for documentation? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 let me pile on and say i'm thrilled we're done with this too. :) i'd also ask of all those users out there who are interested in better documentation to send us an email: [EMAIL PROTECTED] - tell us what would is most important to you in our next book. what you'd like to see, what you think needs more elaboration, etc. we're very interested in ensuring that these books are relevant, focused, and good, and that we increase overall goodness of the documentation and tools available to osg users. thanks! bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What was reasoning behind OSG Z up axis
Mike, For information, my latest collada plugin submission makes the axis orientation, units and scaling information available to callers via parameters passed back by the reader. Roger -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Mike Weiblen Sent: 14 December 2007 16:35 To: OpenSceneGraph Users Subject: Re: [osg-users] What was reasoning behind OSG Z up axis Random thoughts: COLLADA, in an attempt to address this common issue, does provide a flag to specify which axis to call up. For applying a static rotation, that was exactly the motivation for the .rot and .trans pseudoloaders: to adjust coordinate systems via data filenames rather than code or special flags in every plugin. Eg: osgviewer mydata.anyformat.0,0,-90.rot Cheers -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
Paul Martz wrote: * We could spend time writing short whitepapers on various OSG topics, I'd be very much in favour of this form of documentation. It allows users to pick and choose which papers to read, without having to buy lots of doxygen output or stuff they already know. Domain experts could write a paper, with maybe a editor-in-chief to ensure consistency. Admittedly I can see most of this work just coming down to two or three people, but the potential is there. Or maybe the domain expert could just write some notes and someone could be employed as a ghost-writer; this might be attractive to foreign users. Once enough have been written, they could be compiled into a paper book as a sort of OSG Gems. This is something of a Utopian vision I admit, my experience tells me it wouldn't work out like this; but it'd be a reasonable idea to aim for. Incidentally, my offer to proof-read still stands. -JD __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Asynchronous file loading via DatabasePager questions
Colin Branch wrote on Friday, December 14, 2007 10:30 AM:
Hi all,
What I'm trying to do:
Asynchronous model loading using OSG 2.2
How I'm currently doing it:
I'm trying to use the Database Pager's requestNodeFile.
I created a new node class that I can add (as well as place temporary
objects) that I can add and will stay in the scene.
class DtDelayedModelNode : public osg::Group
{
...
DtDelayedModelNode(const std::string filename, osgDB::DatabasePager*
pager) : osg::Group()
{
osg::FrameStamp fs;
fs.setFrameNumber(INT_MAX);
pager-requestNodeFile(filename,this,1.0,fs);
}
...
};
I'm not sure what you're trying to do. It looks like you just want to be
able to load a file when needed rather than right away. Couldn't you
just use osg::ProxyNode or osg::PagedLOD?
What if any calls should I make to the pager around frame() (ie it
doesn't appear that startFrame endFrame are needed, any other calls)?
If you are using osgViewer or osgProducer, then everything should happen
automatically; they do all the necessary DatabasePager handling for you.
The value of the frame stamp appears to control deletion of requests.
Ie if I pass in the current frame stamp, the model is actually
deleted in compileGLObjects. Unless I set it to some value in the
future (currently using INT_MAX) I can't guarantee it will load.
Could someone explain the purpose of the framestamp and the proper
usage?
You don't actually need to pass in a FrameStamp, but if you do, then the
DatabasePager uses it to see how long it's been since the last time a
particular file was requested. If it's been too many frames since the
file request, then the DatabasePager assumes the request is out of date
and discards it. Note also that this behavior is dependent on startFrame
and endFrame.
Is there anyway to get status feedback while a file loads?
Not at present.
--
Bryan Thrall
FlightSafety International
[EMAIL PROTECTED]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
I would just like to jump in here and say I'm also having font problems w/ SVN as of either yesterday or the day before. My problems aren't like the ones Paul is seeing, but they're definitely new differences that weren't there Tuesday... Attached is a picture of the osghudlabel example from osgHUD. In the past, the text rendered has been nice and reasonably compact, but now there is almost an entire row of blank space between real row of text. This is the case for both my own fonts and the Times font provided w/ OSG. HOWEVER, this could just be my imagination, but was the font clarity improved with the recent changes to osgText? Even the spacing is wonky, I can swear they actually look a little crisper... not subpixel-aligned (as that would take a minimum of 3 passes so I hear), but still good. :) On Thu, 2007-12-13 at 13:11 -0700, Paul Martz wrote: Current SVN head seems to have extra-large screen oriented fonts. See the attached screen shots. This is on Windows VS8; don't know about other platforms? I get the same for screen oriented fonts in the osgtext example. While my failing eyesight certainly appreciates the increased font size, I can't help but think this is a bug. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ 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] Big fonts in current SVN
Image attached. On Fri, 2007-12-14 at 12:53 -0500, Jeremy Moles wrote: I would just like to jump in here and say I'm also having font problems w/ SVN as of either yesterday or the day before. My problems aren't like the ones Paul is seeing, but they're definitely new differences that weren't there Tuesday... Attached is a picture of the osghudlabel example from osgHUD. In the past, the text rendered has been nice and reasonably compact, but now there is almost an entire row of blank space between real row of text. This is the case for both my own fonts and the Times font provided w/ OSG. HOWEVER, this could just be my imagination, but was the font clarity improved with the recent changes to osgText? Even the spacing is wonky, I can swear they actually look a little crisper... not subpixel-aligned (as that would take a minimum of 3 passes so I hear), but still good. :) On Thu, 2007-12-13 at 13:11 -0700, Paul Martz wrote: Current SVN head seems to have extra-large screen oriented fonts. See the attached screen shots. This is on Windows VS8; don't know about other platforms? I get the same for screen oriented fonts in the osgtext example. While my failing eyesight certainly appreciates the increased font size, I can't help but think this is a bug. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ 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 attachment: osghudlabel.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
Hello Bob and Paul, * The reference manual, as it stands today, contains some nice supplementary material, but in essence it's Doxygen output from the source code. We could beef up the source code comments for classes and functions, and contribute this back to osg-submissions. This would improve future versions of the ref man. This is a big job and seems worthwhile only if we focus our efforts on stable functionality. I'm always in favor of improving the existing online documentation, so this is a good idea. Some classes are particularly stark, and sometimes it's not clear whether there are preconditions or particular formats for variables. You have to kind of try it, and hopefully your intuition will be right... Even for some straight OpenGL things (I was looking at osg::PolygonOffset lately, so that one jumps to mind), the arguments and units could be documented and typical usage could be discussed... Some things are obscure even in OpenGL's documentation. * The existing ref man documents osg, osgDB, and osgUtil. We could expand this series to include similar reference material for things like the NodeKits (osgText, osgSim, osgParticle), using OSG in windowing systems (osgViewer, osgManipulator, osgGA), etc. The latter would be great. I haven't used the former 3 nodekits much (yet - apart from the occasional text) so I couldn't say personally if I'd find them useful or not. * We could spend time writing short whitepapers on various OSG topics, similar to Don's useful document on reference-counted memory. We could sell these as PDFs for a couple dollars a pop or something, depending on scope. Possible topics would include rendering order with RenderBins, deriving your own Nodes, Drawables, or StateAttributes, platform-specific topics, resolving build and installation issues, using the Geometry class, performance issues, etc etc, the list is essentially endless. As JD mentioned, I think that's a good idea as well. The time required for each document would be relatively small, but the focused approach means that new users will probably be more inclined to read the ones that interest them rather than pour over a huge programming guide. I'll see if I can think of other things, but this should keep you occupied for the better part of the next century don't you think? :-) Good work, keep it up. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
On Dec 14, 2007 3:18 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello, Is anyone else seeing this issue with the SVN version of the OSG? My last update was yesterday, and I don't see anything wrong with the font size... I'll try to update now and see. Nope, still no problem... Sorry to not be of any help, Paul. Perhaps we have an uninitialized variable lurking in our midst? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
Hi Jeremy, The alignment problem is a known problem that David (the author of the recent changes to osgText) knows about and will be looking into. The texture based fonts themselves haven't actually changed apart from the internals being reworked in terms of the new TexBase class, the actual rendering process should be the same. Robert. On Dec 14, 2007 5:53 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I would just like to jump in here and say I'm also having font problems w/ SVN as of either yesterday or the day before. My problems aren't like the ones Paul is seeing, but they're definitely new differences that weren't there Tuesday... Attached is a picture of the osghudlabel example from osgHUD. In the past, the text rendered has been nice and reasonably compact, but now there is almost an entire row of blank space between real row of text. This is the case for both my own fonts and the Times font provided w/ OSG. HOWEVER, this could just be my imagination, but was the font clarity improved with the recent changes to osgText? Even the spacing is wonky, I can swear they actually look a little crisper... not subpixel-aligned (as that would take a minimum of 3 passes so I hear), but still good. :) On Thu, 2007-12-13 at 13:11 -0700, Paul Martz wrote: Current SVN head seems to have extra-large screen oriented fonts. See the attached screen shots. This is on Windows VS8; don't know about other platforms? I get the same for screen oriented fonts in the osgtext example. While my failing eyesight certainly appreciates the increased font size, I can't help but think this is a bug. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ 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] Big fonts in current SVN
On Fri, 2007-12-14 at 20:23 +, Robert Osfield wrote: Hi Jeremy, The alignment problem is a known problem that David (the author of the recent changes to osgText) knows about and will be looking into. The texture based fonts themselves haven't actually changed apart from the internals being reworked in terms of the new TexBase class, the actual rendering process should be the same. Alas, my once-believedly infallible eyes fail me. :) Maybe they were confused by the extra space... Robert. On Dec 14, 2007 5:53 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I would just like to jump in here and say I'm also having font problems w/ SVN as of either yesterday or the day before. My problems aren't like the ones Paul is seeing, but they're definitely new differences that weren't there Tuesday... Attached is a picture of the osghudlabel example from osgHUD. In the past, the text rendered has been nice and reasonably compact, but now there is almost an entire row of blank space between real row of text. This is the case for both my own fonts and the Times font provided w/ OSG. HOWEVER, this could just be my imagination, but was the font clarity improved with the recent changes to osgText? Even the spacing is wonky, I can swear they actually look a little crisper... not subpixel-aligned (as that would take a minimum of 3 passes so I hear), but still good. :) On Thu, 2007-12-13 at 13:11 -0700, Paul Martz wrote: Current SVN head seems to have extra-large screen oriented fonts. See the attached screen shots. This is on Windows VS8; don't know about other platforms? I get the same for screen oriented fonts in the osgtext example. While my failing eyesight certainly appreciates the increased font size, I can't help but think this is a bug. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ 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] osgHUD 0.1.1 ALPHA
I started checking this library out but haven't responded yet as OSG has been running slow for me (seemed to conflict with compiz and set resolution doesn't seem to work on linux). But I was actually just getting ready to start a GUI library for OSG, but looks like you've beat me to it, haha. :) 1) Constructions like not and and or aren't recognised by MS .NET 7.1 out of the box; I had to replace them all with !, etc This is pretty frustrating, because I'm about 99% sure these are acceptable C++ keywords. They look about a thousand times better in the code, but if Windows won't support them I'll drop their usage. Not sure, but I think those are reserved keywords. There may be a way to enable them in VS. Currently I'm finishing up a game for a company so I haven't had much time lately, but I'll try to look at the design so maybe we can get some discussion about this library going (I have lots of interest in GUI's). Also if I get some time I'll try to build it on my Mac. Thanks for contributing, Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
On Dec 14, 2007 7:59 PM, Zachary Hilbun [EMAIL PROTECTED] wrote: To me an API is only as good as it's documentation. I'd suggest that the OSG is proof that point of view is a perhaps just a little flawed. Good documentation but a poor API and implementation don't make for successful end user applications. However, with a good API and implementation you do have a least have chance of making something useful. I'm not suggesting not having good documentation is not a great thing to have, obviously great documentation and great API and implementation is all what a perfect project would be composed of. From my experience with the OSG project, its the software that solves the problems at the end of the day, and the majority of contributors to the OSG and clients who pay for parts of the OSG to be developed have a problem to solve so they write the code or fund the work to do it. One can say write the documentation first then the software, it might work for you, but so far for the hundreds of contributors to the OSG this hasn't been the case, the gifts that are given tend to be source code. Thankfully there has been exceptions, the QSG was a funded documentation effort, and there have been efforts like the ref manual by Paul Martz and Bob Kuehne, but alas the revenue from books does match the level of effort put in so it is a case of labour of love. Work on the tutorials, wiki and examples are also gifts to the community. However, this work is still in minority - few people have time to spend on activities that don't directly result in getting their project deadlines met, and alas few companies have tens of thousands of dollars to put towards serious documentation efforts. I do like the idea of small white papers on different topics, small chunks of documentation are much easier to squeeze in a free day here or there, than spending many months on a major book. Coherency with such works is more difficult though, but still wouldn't detract from their usefulness. Personally I'd love to see enough funding to employ a fulltime technical writer, failing this perhaps part time. Would companies be prepared to help fund documentation effort? Such as by sponsoring or just straight donation? The amounts we'd need to find would be ten of thousands of dollars to be able to do do any significant chunks of work. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Would it be possible to implement setScreenResolution for X11? Was it left out because it requires an X11 extension? I have some linux machines that have older video cards that run the desktop ok at higher resolutions, but run 3D much faster if the resolution is scaled down. Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and DIS
Try looking at Delta 3D. I think their latest version has DIS support. They also support HLA too. Judd Robert Hansford wrote: Hi all, Does anyone have any experience working with the DIS protocol (http://en.wikipedia.org/wiki/Distributed_Interactive_Simulation) or something similar? I have to rewrite our OSG application to render a scene described/updated via DIS and I'm unsure of the best way to go about it (from a design point of view). DIS provides the state information for the various objects in the scene (eg their position, attitude and any degree-of-freedom or other attributes), so I will have to query that information before each frame is rendered. Presumably the best way to do that is to use the update callbacks for each object, but what resolution should I do it at? Should I have a single callback for each entity that updates all of it's data, or should each node in the graph callback to the appropriate datum? Either way, should I create classes that extend the existing OSG classes (eg a DIS-compatible PAT node, a DIS-compatible DoF node, a DIS-compatible LoD node etc) and then find some way to replace the appropriate instances of those nodes within the models? Or is there some other way to do it? I've never really looked at this side of OSG before. If anyone has done anything similar and wouldn't mind giving some advice, it would be greatly appreciated. Thanks in advance Rob. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Judd Tracy Institute for Simulation and Training University of Central Florida 407-882-1405 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
Next, I'll try taking the 2.2 osgText src and include directories, drop them into my SVN tree, and rebuild. So I'll have the old osgText with the new OSG and 3rd party dependencies. If I can get it to build, that should be a good test. I put the 2.2 osgText include and src dirs in my svn tree. The results: A few things didn't compile, as expected: the osgText plugin and the osgtext3D example both failed to build because of the missing Text3D header. However, those executables were irrelevant to my testing. The font size was back to normal in this configuration. So, although this might be a platform- or even user-specific issue, one contributing factor is isolated to post-2.2 changed code somewhere in osgText. Maybe someone involved in the osgText code changes should take a look? I'm available to answer questions or try out fixes, but I really do need to get back to a couple projects that I've ignored while investigating this issue. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgIntrospection uninitialization
Hi everyone,
just a simple request stil on the introspection framework:
I have noticed that the Types and Converters are stored in a static
structure in the Reflection class... and this structure is totally
unaccessible. (Well we could still use Reflection::getTypes() to get the
type map and delete every type one by one after a const cast, but for the
converters map that's not possible.
The problem with this kind of static structure, is that they are destroyed
only at the very end of your process, and when it comes to profiling
questions this gives a big mess (at least on Windows...) : My profiler
(AQTime 5) is simply considering all the reflection allocations as memory
leaks !...
I guess it would not be a bad idea to add a simple clear static function
to the reflection class to simply delete the static_data member and set it
to NULL. This could even prove useful in [I admit very specific and very
strange] cases where people would want to stop reflecting every types and
restart with new types...
Could some one remind me how to process to submit a code change ? (except if
someone else can add this clear or whatever function directly... it should
only be two lines of code anyway:
void clear() {
if(_static_data)
delete _static_data;
_static_data = 0;
}
regards,
Manu.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to change my osg-users mailing list subscription options?
How to change my osg-users mailing list subscription options? I want to get MIME digests. The URL: http://openscenegraph.net/mailman/options/osg-users/ncutjwz%40sina.com Can Not be Found. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 25, 2007 10:12 PM Subject: Welcome to the osg-users mailing list (Digest mode) Welcome to the [EMAIL PROTECTED] mailing list! To post to this list, send your email to: [EMAIL PROTECTED] General information about the mailing list is at: http://openscenegraph.net/mailman/listinfo/osg-users If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://openscenegraph.net/mailman/options/osg-users/ncutjwz%40sina.com You can also make such adjustments via email by sending a message to: [EMAIL PROTECTED] with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: 467407 Normally, Mailman will remind you of your openscenegraph.net mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to change my osg-users mailing list subscription options?
Hello Jin, How to change my osg-users mailing list subscription options? I want to get MIME digests. [...] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org See the link there? It's at the bottom of every post! :-) The mail you quoted was the old one, with the old server address... You probably got a new one when the server was switched over. Also, going to www.openscenegraph.org and clicking on Mailing Lists in the menu on the right would have gotten you to the right place. But try the address above, it should work for you. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] unresolved externals
I downloaded and compiled FreeType library but it did not solve my problem, it still gives this error both in Release and Debug compile Error2error LNK2019: unresolved external symbol _FT_Outline_Get_BBox referenced in function protected: void __thiscall FreeTypeFont3D::init(void) ([EMAIL PROTECTED]@@IAEXXZ) FreeTypeFont3D.obj Error3fatal error LNK1120: 1 unresolved externals E:\OpenSceneGraph Source\OpenSceneGraph\built\lib\Release\..\..\bin\osgPlugins- 2.2.0\osgdb_freetype.dll Does anyone know how to solve this problem? Thanks in advance, /emre ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] readFontFile possible bug
I performed my tests using the SVN trunk of OSG (as about 2 hours ago) Here are some of the log messages: Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X1_Y0_subtile.ive. Error r e.a.d.i.n ga nfoitlhee:r DeartraoIrn pcuotdSet rmeanesa mt:h:arte atdhUeI nfto(n)t: fiFlaei lceodu ltdo nroet add unsign ed in t. .v..a lbuee . opened, read or simply that it is broken..d Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X0_Y1_subtile.ive. WarnEinrgr:o rC oruelda dniontg ffiinlde :p lDuagtianI ntpou trSetarde aomb:j:ercetasd UfIrnotm( )f:i lFea ilCe:d\ tWo irnedaodw su\Fonnstisg\nteidme s.itnttf v.alue . Warning: Could not find plugin to read objects from file c:/system/earth/earth_L3_X2_Y2_subtile.ive. Error reading file: D.a.t.a.I napnuottShterre aemr:r:orre acdoUdIen tm(e)a:n sF atihlaetd tthoe rfeoandt ufnislieg n ceodu lidn tn ovtadlue. be opened, read or simply that it is broken..d Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X0_Y1_subtile.ive. WarniEnrgr:o rC orueladd innogt ffiilned: pDlautgaiInnp uttoS trreeaadm :o:brjeeacdtUsI nftr(o)m: fFialiel edC :t\oW rienaddo wusn\sFiognntesd\ tiinmte sv.atltufe.. Warning: Could not find plugin to read objects from file c:/system/earth/earth_L3_X2_Y2_subtile.ive. E.r.r..o ra nroetahdeirn ge rfriolre :co dDea tmaeIannpsu ttShtarte atmh:e: rfeoandtU Ifnitl(e) : cFoauillde dn ottod r ead unsigned i n.t. .v.a lbuee .o pened, read or simply that it is broken..d Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X1_Y0_subtile.ive. WarniEnrgr:o rC oreualddi nngo tf iflien:d DpaltuagIinn ptutoS rteraeda mo:b:jreecatdsU Ifnrto(m) :f iFlaei leCd: \tWo i nrdeowasd\ Fuonnstisg\nteidm eisn.tt tvfal.ue. Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X0_Y1_subtile.ive. Error readin g. .f.i.l ea:n oDtahtearI neprurtoSrt rceoadme: :meraenasd UtIhnatt( )t:h eF afiolnetd ftiol er ecaodu lud n sniotgdn ed int v a.l.u.e. be o.pen ed, read or simply that it is broken..d Warning: Could not find plugin to read objects from file c:/system/earth/earth_L3_X2_Y2_subtile.ive. WarnEirnrg:o rC orueladd innogt ffiilned: p lDuagtianI ntpou trSead torbejaemc:t:sr efarodmU Ifnitl(e) : FCa:i\lWeidn dtowos \rFeoadn tusn\stiigmneesd. titnft .va lue. On Dec 14, 2007 2:13 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, On Dec 14, 2007 3:15 PM, sherman wilcox [EMAIL PROTECTED] wrote: Robert, I'm not so sure the multi-threading issue is resolved. I wasn't getting simple GPU stalls. The database pager would stop working after several of these stalls. By stop working I don't mean interruptions with resumption. That database pager would not come back at all. Also, the log messages to screen was strange. Some were garbled messages and mentioned that it could no longer find plugins, etc. The inability to find plugins could explain the database pager, but the question then becomes why does running background threads dump plugins and trash log output? OK. This does sounds like more than just a plain stall, all I was able to do was recreate the stall. Could you capture the error messages and post them? As for a thread dumping plugins etc. This suggest to be that the Registry is getting corrupted for some reason, but who knows, this is all pretty new in style of problem than we've seen before. 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] unresolved externals
Hello Emre, I downloaded and compiled FreeType library but it did not solve my problem, it still gives this error both in Release and Debug compile You did not need to download and compile it, just download the new 3rd party bundle from Mike Weiblen's SVN: https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1/ or https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs71/ Then, and this is important, you need to re-do the CMake config. Either A) Delete your CMakeCache.txt file and then re-run CMakeSetup so it will detect the correct library names. Or B) Start CMakeSetup, enable Show Advanced Values, and change them manually. From memory, the ones that need changing are: PNG_LIBRARY= libpng.lib -- libpng13.lib PNG_LIBRARY_DEBUG = libpngd.lib -- libpng13d.lib FREETYPE_LIBRARY = libfreetype219.lib -- libfreetype235.lib FREETYPE_LIBRARY_DEBUG = libfreetype219_D.lib -- libfreetype235_D.lib ZLIB_LIBRARY = zlib.lib -- zlib1.lib ZLIB_LIBRARY_DEBUG = zlibd.lib-- zlib1d.lib (but double-check with the contents of 3rdParty/lib to be sure that all your libraries have the right names) Hope this helps, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
