[osg-users] osgcluster small fix
Hi Robert, just a note, I have tested the osgcluster example and I found a missing setup, just a line of code. You have to set at ln 530 if (viewerMod != SLAVE) viewer.setCameraManipulator(...) Otherwise it doesn't work Cheers, Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to correctly reference cube map in GLSL with OSG?
Hi Michael, Hi. I haven't found any example of using cubemaps from GLSL in OSG examples and on the web. I only found cubemap usage in osgOcean: http://goo.gl/NwTTs9 It has the following varying in the vertex shader: nCube = gl_Vertex.xyz; And the following usage of it in the fragment one: vec3 p = vec3(nCube.x, nCube.y, -nCube.z); gl_FragColor = textureCube(cubeMap, p.xzy); I used it in my example and the result is the cubemap mapped to boxes without any motion when I turn camera around (the screenshot is attached to the mail). What's the correct way to get moving cube map when I turn camera around? You might try the transformed normal to perform the lookup. e.g. vec3 normal = osg_NormalMatrix * gl_Normal; vec4 color = textureCubeMap(cubeMap, normalize(normal)); If this is not what you are after (e.g. If you are looking for sky-box like reflections), the you need to use the reflection vector which is something like: vec3 normal = osg_NormalMatrix * gl_Normal; vec4 view = osg_ModelViewMatrix * gl_Vertex; vec3 reflect = reflect(normalize(-view.xyz), normal);# Sorry this is out of my head and I didn't test it. But it should give you the idea. Btw. This has nothing to do with OSG. Google for cubemapping glsl. cheers Sebastian Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Memory leak with Openthreads from git under Linux
Hi Roman, The valgrind results say possibly loss, which doesn't necessarily mean that is an actual leak, just that something may be happening that might be leak. I'm not aware of any leaks in OpenThreads's pthread in terms of what it manages itself, if you can spot something from code reivew/testing please pass on the details. If pthreads that it's using is leaking then there might not be anything we can do about it. However, there is perfectly possible for valgrind to simply be generating a false positive. To further look into the issue the best thing to do would be to create a very small example that creates an OpenThreads::Thread object and see if valgrind reports anything for it. Then start the thread then check again. If this does report leaks then review the code that the OpenThreads::Thread to see if you can spot a possible leak. Another refinement would be to create a pthread directly and see if that reports any leaks. Until there is more evidence that there is real leak I'll assume that it's false positive. Robert. On 19 November 2013 07:44, Roman Grigoriev grigor...@gosniias.ru wrote: Hi, I use Openthreads and valgrind give me this errors under Ubuntu 13.10 Code: ==3658== 160 bytes in 1 blocks are possibly lost in loss record 1 of 2 ==3658==at 0x482D4B8: calloc (vg_replace_malloc.c:593) ==3658==by 0x400C99D: allocate_dtv (dl-tls.c:296) ==3658==by 0x400CE4B: _dl_allocate_tls (dl-tls.c:460) ==3658==by 0x48544E9: pthread_create@@GLIBC_2.4 (allocatestack.c:579) ==3658==by 0x48D14FB: OpenThreads::Thread::start() (in /usr/local/lib/libOpenThreads.so.3.3.0) Thank you! Cheers, Roman -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57290#57290 ___ 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] OpenThreads::Mutex doesn't work the same on win32 and linux/pthreads
Hi OSG users especially Windows experts, Please could you have a look at what Mattias is proposing and provide feedback. I don't have Windows machine let alone expertise with Windows threads so can't directly contribute insights to the specifics of the Windows threads implementation so have to defer to the community to provide the expertise. The only thing I'd add in general is that having OpenThreads behave the same across all platforms is desirable so in principle I believe Mattias's suggestion is sound. I'm a litle cautious though as there is chance that Windows only OSG applications might be relying upon the re-entrant nature of the current Mutex under Windows so could find there application hanging with the integration of the change to OpenThreads. Thoughts please ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing memory usage by Texture of size 4096x2048
Hi John, I'll add some general comments as others have already provide quite a few responses. In OpenGL when you create a texture object you first have the memory for the imagery in the applications main memory, when you (via osg::Texture2D) pass that image data to OpenGL fifo, then afterwards the the driver takes the data from the fifo and creates an internal representation of that data that is suitable for passing directly to the graphics hardware. This representation may have different pixel format depending upon the hardware and the texture settings you used, and also may create mipmaps for you. Finally when the actual texture is needed on the GPU it'll be copied to local memory on the graphics card. The result of this pipeline is several copies of your data, it's not a bug, but just the way that OpenGL/hardware manages things. The Texture::setUnRefImageAfterApply(true) usage tells the OSG to unref the image after the data has been passed into the OpenGL fifo, and as long as no other references are kept to the osg::Image this data will be deleted so getting rid of one copy of the data which is why it helps. Another aspect to take into account is that files on disk that are compressed in .jpeg etc. are all much smaller than they are once they are loaded into memory. However, if you use an OpenGL compressed format such as S3TC then it'll be stored in a format that you can pass directly to OpenGL without any unpacking, here the memory usage will be consistent from disk to OSG memory to driver memory and to the GPU memory, with a caveat that if you generate mipmaps at runtime this will increase the footprint by around 40%. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash from loading assets in worker thread
Hi Baker, It really couldn't say whether this might be an new OSG bug or just co-incidence that changing OSG version reveavlled a bug in your code that has be lingering for a while just waiting for the right time to ruin your day - threading bugs have a habit of doing! As I don't know your code there isn't much directly I can do. The only thing I'd suggest that might be an area to look at is to always use ref_ptr in all your code. The read*File() methods doing pass C pointers which does open one to possibility of problems if other codes are retaining a ref_ptr to it but that ref_ptr itself could be deleted by another thread. The solution to this is to use readRef*File() methods that all pass be a ref_ptr, or to do the read call directly from the Registry where you get back a ReadResult that holds a ref_ptr to the object. If you have a look at the OpenSceneGraph/src/osgDB/DatabasePager.cpp usage of read*File() you'll see that it gets the ReadResult. The advantage it has it you can also get more information about failures as well as it being thread safe. Robert. On 19 November 2013 19:46, Bradley Baker Searles bakersear...@gmail.comwrote: Hello, Summary: Since upgrading to OSG 3.2, our application will crash during render while loading a legacy .OSG file on a worker thread. The legacy/deprecated OSG code will load objects that are put into the object cache, but then use takeImage to get a raw pointer to a ref-counted object. If the threads are serviced in a particular order the main thread will do cache cleanup and delete this object that looks like it has no references while the load thread is pre-empted. More Detail: In this use case, the rendered scene graph is empty, and the loaded assets are not introduced into the scene graph until the worker thread returns. Let me map out the basic flow of the error case (not that freezing the worker thread when it has the raw pointer can trigger this crash every time): Code: WORKER THREAD: * Texture2D_readLocalData (src/OsgWrappers/deprecated-dotosg/osg/Texture2D.cpp) calls: * Input::readImage(), which calls * osgDB::readImageFile(), which uses rr.takeImage() to return a raw pointer. * NOTE: the only reference count to the Image at this point is from the cache object. MAIN THREAD: * Registry::updateTimeStampOfObjectsInCacheWithExternalReferences() *** timestamp is not updated because there are no counted external references! * Registry::removeExpiredObjectsInCache() *** this deletes the object because the timestamp was not updated above. WORKER THREAD: * raw Image pointer is added to the texture, but it's not valid at this point. Crash ensues. There are several fixes I can think of offhand, some seem more proper than others. I'm not sure why the raw pointer usage is there, it would seem to violate the principle of the smart pointers. POSSIBLE FIXES: 1. Remove code that sort of uses ref counting, or remove ref-counting along entire speed critical paths. This would seem most correct at a glance. 2. Do not render while loading. We've done this as a temporary fix, but the drawbacks are obvious. Heck, maybe this is not a supported feature and I have just somehow missed this along the way. 3. Introduce an UNDEFINED TIME to initialize cache objects to when they're added (instead of the 0.0 that the parameter currently defaults to). This would allow the problem to be masked to not happen as long as the objects are re-ref-counted within the timeframe alotted to the object cache. I implemented this as well, and it works in our situation, although if I were to freeze the load thread long enough in the right spots I could get it to fail, implying it's not proper in my mind. 4. Don't use old style OSG files. This is not really a good option for us, we've been using OpenSceneGraph for years, and we have a lot of customers with legacy OSG data out there. Our typical use has a mixture of OSG and OBJ files, the OBJ load paths seem to use refcounted pointers throughout. I would have supplied a patch with this post, but not fully understanding the intentions of this code prevents me from creating something that I'm sure is correct. Build/Test Environment: OSG 3.2, using wxWidgets 2.9.5 for windowing Windows 8.1, 64-bit Visual Studio 2010 Input, insight, or better solutions would be greatly appreciated. Thanks Baker [/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57327#57327 ___ 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] PagedLOD and IntersectionVisitor
Hi Oliver,
I have looked at the OSG code and can't see a specific cause, but then I
don't have your code or models so it's all just guessing.
Does LineOfSight work fine for you? If so I'd recommend stepping through
to see what happening and then compare it with your own usage.
Robert.
On 19 November 2013 19:58, Olivier Tournaire olit...@gmail.com wrote:
Hi all,
Sorry for the noise, but, as I did not receive any answer, I am interested
if someone has an idea on the topic.
Regards,
Olivier
2013/11/15 Olivier Tournaire olit...@gmail.com
Hi,
I am currently trying to retrieve some specific triangles in a PagedLOD
model. To do so, I use a PolytopeIntersector with an IntersectionVisitor.
As my model is a PagedLOD, I have set up a reader callback, directly taken
from osgSim::LineOfSight.
The intersector works, but not as expected: it gives me the triangles at
the lowest resolution, whereas I would expect to have them at the finest
LOD. Debugging my program showed me that the void
IntersectionVisitor::apply(osg::PagedLOD plod) method goes where it has to
(i.e., it traverses correctly all childs until the best resolution).
As the IntersectionVisitor sets up by default to use
the USE_HIGHEST_LEVEL_OF_DETAIL flag, I am wondering if I am missing
something and if you could give some pointers on how to achieve triangles
extraction at the finest LOD.
The header root file is:
osg::PagedLOD {
UniqueID 1
Name Tile_+001_+006.osgb
CenterMode USER_DEFINED_CENTER
UserCenter -741.555 904.039 94.1168 213.403
RangeMode PIXEL_SIZE_ON_SCREEN
RangeList 2 {
0 106.702
106.702 1e+030
}
DatabasePath FALSE
RangeDataList 2 {
Tile_+001_+006_L15_0.osgb
}
PriorityList 2 {
0 1
0 1
}
The header of the child file (Tile_+001_+006_L15_0.osgb) is:
osg::PagedLOD {
UniqueID 1
Name Tile_+001_+006_L15_0.osgb
CenterMode USER_DEFINED_CENTER
UserCenter -741.869 906.466 94.7166 206.312
RangeMode PIXEL_SIZE_ON_SCREEN
RangeList 2 {
0 206.312
206.312 1e+030
}
DatabasePath FALSE
RangeDataList 2 {
Tile_+001_+006_L16_00.osgb
}
PriorityList 2 {
0 1
0 1
}
Hope you could help
Regards,
Olivier
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgText] Visual Studio 2013 (VS11) compatibility
HI Judson, Standard library includes do seem to have been tightened up to varying degrees across various degrees across C++11 compiler, previously we got more stuff included incidentally when you included other headers. The solution I opted for for Glyph.cpp was to use osg::maximum rather than std::max, I did this rather than adding the extra includealgorithm as the rest of osgText uses osg::minimum and osg::maximum rather than the std::min and std::max counterparts. This fix is checked into the OSG-3.2 branch and svn/trunk. Robert. On 20 November 2013 00:36, Judson Weissert jud...@mfrac.com wrote: Hello, I was wondering if anyone has compiled OSG on Visual Studio 2013 yet? I am compiling OSG 3.2.1 on Visual Studio 2013, and encountered a build error in src/osgText/Glyph.cpp. It appears that std::min() and std::max() are not defined because the algorithm header was not included. See bullet point: You must use #include algorithm when you call std::min() or std::max(). from http://msdn.microsoft.com/en-us/library/vstudio/bb531344. aspx#sectionToggle2 I imagine this is some sort of C++2011 conformance issue. As far as I can tell, the solution is to simply include algorithm within Glyph.cpp. Granted, I have not figured out where the definitions were coming from previously... Regards, Judson ___ 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] wrong graphics after removing geometry deprecated methods
Hi Gianni, I have just tried your model with osgviewer from svn/trunk and it works fine. Does the problem appear with your own viewer? Does you own viewer setup the Camera's replacing the viewer's master Camera? Does this override neglect to set up any default OpenGL state? I say this as a bug fix in 3.2 revealed a bug in OSG usage that was previously hidden by the bug that was fixed, so fixing the bug makes it look like a new bug has appeared. I have written quite a bit about this issue and how to resolve it prior to the OSG-3.2 release, when it was released and subsequently. From the look of the images you supplied it looks like this may well be a candidate. Robert. On 20 November 2013 15:29, Gianni Ambrosio ga...@vi-grade.com wrote: Hi All, I tried to move to a recent release of OSG but it seems that starting from 3.1.9 (to 3.2.0 included), what has been removed from osg::Geometry has completrly broken the 3d visualization. To reproduce the problem just try to load a5_ivm_crt_v2_RT_whl_front_wheel.ive (attached) with osgDB::readNodeFile(). I tried with osgviewerQt.cpp example. The same example with OSG 3.1.8 reports a bunch of: Geometry::fixDeprecatedData() messages, but indeed it works fine! Does anybody experienced the same bug? Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57334#57334 Attachments: http://forum.openscenegraph.org//files/with319_256.png http://forum.openscenegraph.org//files/with318_104.png http://forum.openscenegraph.org//files/a5_ivm_crt_v2_rt_whl_front_wheel_352.ive ___ 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] osgcluster small fix
Hi Nick, This code hasn't changed and used to work. Could you example Otherwise it doesn't work as I'd like to get to the bottom of when and where it does and doesn't work and why. The slave viewer camera's view matrix is overwritten on each new frame just before renderingTraversals(), this will be any setting from the camera manipulator will be overridden so functionally should be fine. Ideally one wouldn't have any camera manipulators on the slave so you suggested change is good practice, but why it's actually required when you've tested needs to be explained as something else must be going on. Robert. On 21 November 2013 08:28, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Robert, just a note, I have tested the osgcluster example and I found a missing setup, just a line of code. You have to set at ln 530 if (viewerMod != SLAVE) viewer.setCameraManipulator(...) Otherwise it doesn't work Cheers, Nick -- trajce nikolov nick ___ 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] osgcluster small fix
Hi Robert, it makes sense what you just wrote. When I ran the sample, I was able to control the model with the camera manipulator in slave mode, so I just look fast in the sample and come up with this fix. For some reason, the camera view matrix gets valid from the camera manipulator, no idea why. If I find some time today I might investigate this further, but it is welcome if the community test it as well Thanks Nick On Thu, Nov 21, 2013 at 2:15 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Nick, This code hasn't changed and used to work. Could you example Otherwise it doesn't work as I'd like to get to the bottom of when and where it does and doesn't work and why. The slave viewer camera's view matrix is overwritten on each new frame just before renderingTraversals(), this will be any setting from the camera manipulator will be overridden so functionally should be fine. Ideally one wouldn't have any camera manipulators on the slave so you suggested change is good practice, but why it's actually required when you've tested needs to be explained as something else must be going on. Robert. On 21 November 2013 08:28, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Robert, just a note, I have tested the osgcluster example and I found a missing setup, just a line of code. You have to set at ln 530 if (viewerMod != SLAVE) viewer.setCameraManipulator(...) Otherwise it doesn't work Cheers, Nick -- trajce nikolov nick ___ 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgEarth 2.5 released!
Friends, The osgEarth team is proud to announce the release of Version 2.5! osgEarth is a cross-platform Terrain and Mapping SDK built on top of OpenSceneGraph. Visit http://osgearth.org to get started. Head right over to the repo tag and release notes for 2.5 on GitHub: https://github.com/gwaldron/osgearth/releases/tag/osgearth-2.5 Peruse the online documentation: http://docs.osgearth.org/en/latest/ Enjoy!! Glenn Waldron / Pelican Mapping / @glennwaldron ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash from loading assets in worker thread
Hi Robert, The DatabasePager calls using ReadResult all use a ref_ptrosg::Object to store the loaded item, unlike the code in src/osgwrappers/deprecated-dotosg/osg/texture2d.cpp :: Texture2D_readLocalData(Object, Input), which uses Input::ReadImage(filename) to load the image. Input::ReadImage() calls osgDB::readImageFile() which loads the image via the Registry (which keeps a reference), then violates the ref_ptr to return a raw pointer. This code is not thread safe. If a render happens before this raw pointer is safely tucked into a ref_ptr, the asset is deleted as described previously which makes the raw pointer junk. This crash is happening deep within OSG code paths on both threads. Our app isn't affecting anything but the timing here. Is there any reason I should not submit a patch to the OSG that uses thread-safe ref_ptr's for any load path that uses the Registry Object Cache to load assets? Thanks, Baker -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57370#57370 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] C++11 with OSG
Hi, Just wondering how many of you use C++11 with OSG and what you think about it. Thank you! Cheers, deniz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57376#57376 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth 2.5 released!
Awesome work! On Thu, Nov 21, 2013 at 7:49 AM, Tomlinson, Gordon gtomlin...@overwatch.textron.com wrote: Congrats Glenn G. *Gordon Tomlinson - TeamRV* *Sustainment Manager/Chief Engineer**(RemoteView)* *Overwatch* *An Operating Unit of Textron Systems ** [image: rv4-2]* __ *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Glenn Waldron *Sent:* Thursday, November 21, 2013 9:30 AM *To:* OpenSceneGraph Users *Subject:* [osg-users] osgEarth 2.5 released! Friends, The osgEarth team is proud to announce the release of Version 2.5! osgEarth is a cross-platform Terrain and Mapping SDK built on top of OpenSceneGraph. Visit http://osgearth.org to get started. Head right over to the repo tag and release notes for 2.5 on GitHub: https://github.com/gwaldron/osgearth/releases/tag/osgearth-2.5 Peruse the online documentation: http://docs.osgearth.org/en/latest/ Enjoy!! Glenn Waldron / Pelican Mapping / @glennwaldron ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] wrong graphics after removing geometry deprecated methods
robertosfield wrote:
Does the problem appear with your own viewer? Does you own viewer setup the
Camera's replacing the viewer's master Camera? Does this override neglect to
set up any default OpenGL state?
I use the following class:
class ViewerWidget : public osgQt::GLWidget, public osgViewer::CompositeViewer
Here is a code snippet of the constructor:
Code:
ViewerWidget::ViewerWidget(QWidget* iParent, const QGLWidget* iShareWidget,
Qt::WindowFlags iFlags)
: osgQt::GLWidget(iParent, iShareWidget, iFlags)
,timer(0)
{
osgViewer::View* view = new osgViewer::View;
view-setName(Main view);
addView(view);
view-setCamera(createCamera(viframework::viosg::screenWidth(),
viframework::viosg::screenHeight()));
view-setCameraManipulator(new osgGA::TrackballManipulator);
initWindowManager(view);
}
osg::Camera* ViewerWidget::createCamera(int width, int height)
{
osg::ref_ptrosg::Camera camera = new osg::Camera;
camera-setGraphicsContext(new osgQt::GraphicsWindowQt(this));
camera-setClearColor(osg::Vec4(0.2, 0.2, 0.6, 1.0));
camera-setViewport(new osg::Viewport(0, 0, width, height));
double aspect_ratio =
2.0*static_castdouble(width)/static_castdouble(height);
camera-setProjectionMatrixAsPerspective(30.0, aspect_ratio, 1.0, 1.0);
return camera.release();
}
void ViewerWidget::initWindowManager(osgViewer::View* iView)
{
osg::ref_ptrosgWidget::WindowManager wm = new
osgWidget::WindowManager(iView, 1280.0f, 1024.0f, MASK_2D,
osgWidget::WindowManager::WM_USE_RENDERBINS);
osg::Camera* camera = wm-createParentOrthoCamera();
SceneManager manager;
manager.getRoot()-addChild(camera);
manager.setWindowManager(wm);
wm-resizeAllWindows();
iView-addEventHandler(new osgWidget::MouseHandler(wm));
iView-addEventHandler(new osgWidget::ResizeHandler(wm, camera));
}
unsigned int viframework::viosg::screenHeight()
{
osg::GraphicsContext::WindowingSystemInterface* wsi =
osg::GraphicsContext::getWindowingSystemInterface();
osg::GraphicsContext::ScreenSettings settings;
osg::GraphicsContext::Traits traits;
wsi-getScreenSettings(traits, settings);
return static_castunsigned int(settings.height);
}
unsigned int viframework::viosg::screenWidth()
{
osg::GraphicsContext::WindowingSystemInterface* wsi =
osg::GraphicsContext::getWindowingSystemInterface();
osg::GraphicsContext::ScreenSettings settings;
osg::GraphicsContext::Traits traits;
wsi-getScreenSettings(traits, settings);
return static_castunsigned int(settings.width);
}
Cheers,
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57362#57362
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash from loading assets in worker thread
Hi Barker, I've had a quick look at Input.cpp and all the read file calls use C pointers which won't be safe when an application is running multi-threading loads and using the pruning cache at the same time. Temporary workarounds I can see would be either not use object cache when multti-threading load, not use the deprecated .osg format for loading files or to simply run these loads synchronously. The proper fix would be to make sure Input.cpp and the deprecated wrappers all use ref_ptr for the data they use. Unfortunately this will break the ABI of osgDB so would push the fix out beyond OSG-3.2. I'd welcome a submission that addresses this issue with the deprecated loading code. Cheers, Robert. On 21 November 2013 17:07, Bradley Baker Searles bakersear...@gmail.comwrote: Hi Robert, The DatabasePager calls using ReadResult all use a ref_ptrosg::Object to store the loaded item, unlike the code in src/osgwrappers/deprecated-dotosg/osg/texture2d.cpp :: Texture2D_readLocalData(Object, Input), which uses Input::ReadImage(filename) to load the image. Input::ReadImage() calls osgDB::readImageFile() which loads the image via the Registry (which keeps a reference), then violates the ref_ptr to return a raw pointer. This code is not thread safe. If a render happens before this raw pointer is safely tucked into a ref_ptr, the asset is deleted as described previously which makes the raw pointer junk. This crash is happening deep within OSG code paths on both threads. Our app isn't affecting anything but the timing here. Is there any reason I should not submit a patch to the OSG that uses thread-safe ref_ptr's for any load path that uses the Registry Object Cache to load assets? Thanks, Baker -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57370#57370 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgText] Visual Studio 2013 (VS11) compatibility
Thanks Robert! Judson On 11/21/2013 6:02 AM, Robert Osfield wrote: HI Judson, Standard library includes do seem to have been tightened up to varying degrees across various degrees across C++11 compiler, previously we got more stuff included incidentally when you included other headers. The solution I opted for for Glyph.cpp was to use osg::maximum rather than std::max, I did this rather than adding the extra includealgorithm as the rest of osgText uses osg::minimum and osg::maximum rather than the std::min and std::max counterparts. This fix is checked into the OSG-3.2 branch and svn/trunk. Robert. On 20 November 2013 00:36, Judson Weissert jud...@mfrac.com mailto:jud...@mfrac.com wrote: Hello, I was wondering if anyone has compiled OSG on Visual Studio 2013 yet? I am compiling OSG 3.2.1 on Visual Studio 2013, and encountered a build error in src/osgText/Glyph.cpp. It appears that std::min() and std::max() are not defined because the algorithm header was not included. See bullet point: You must use #include algorithm when you call std::min() or std::max(). from http://msdn.microsoft.com/en-us/library/vstudio/bb531344.aspx#sectionToggle2 I imagine this is some sort of C++2011 conformance issue. As far as I can tell, the solution is to simply include algorithm within Glyph.cpp. Granted, I have not figured out where the definitions were coming from previously... Regards, Judson ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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] osgEarth 2.5 released!
yay! the next step for one of my favorite toolkits cheers -- mew On Nov 21, 2013 7:30 AM, Glenn Waldron gwald...@gmail.com wrote: Friends, The osgEarth team is proud to announce the release of Version 2.5! osgEarth is a cross-platform Terrain and Mapping SDK built on top of OpenSceneGraph. Visit http://osgearth.org to get started. Head right over to the repo tag and release notes for 2.5 on GitHub: https://github.com/gwaldron/osgearth/releases/tag/osgearth-2.5 Peruse the online documentation: http://docs.osgearth.org/en/latest/ Enjoy!! Glenn Waldron / Pelican Mapping / @glennwaldron ___ 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] wrong graphics after removing geometry deprecated methods
HI Giana,
As I suspected the bug is introduced by the Qt code example that you've
reused. I had to fix the osgviewerQt example so that it didn't create it's
own local Camera, instead uses the view's master Camera() that the view
initializes in a suitable way to work as a topmost Camera. Have a look at
the code for osgviewerQt in OSG-3.2 or svn/trunk.
The other solution to the bug in the usage approach is to initialize the
StateSet of the Camera so it's suitable for using as the topmost Camera
that defines the state, the line is simply:
camera-getOrCreateStateSet()-setGlobalDefaults();
Why this wasn't required before was the internally SceneView would override
the Camera's StateSet rewriting it's values to use the ones defined by
setGlobalDefaults(), however, this meant the any state that applications
would set on the viewer's Camera would be discarded which is the bug that
needed to be resolved. By default View creates a master Camera and does
the camera-getOrCreateStateSet()-setGlobalDefaults(); for you so that is
no reason for SceneView to override the values.
The problem comes with applications that explicitly assign their own
osg::Camera but never set the state for it so you just end up with OpenGL
defaults, such as having depth test off - which results in the problem you
see. The SceneView hide this so you never got to see the bug in the
original viewer setup code that you had.
Most OSG users aren't affected by this as they don't create their own
osg::Camera and assign it to the View(er). Unfortunately this invalid usage
slipped into OSG examples and was replicated by a few user applications.
The OSG examples are now fixed.
Robert.
On 21 November 2013 15:05, Gianni Ambrosio ga...@vi-grade.com wrote:
robertosfield wrote:
Does the problem appear with your own viewer? Does you own viewer setup
the Camera's replacing the viewer's master Camera? Does this override
neglect to set up any default OpenGL state?
I use the following class:
class ViewerWidget : public osgQt::GLWidget, public
osgViewer::CompositeViewer
Here is a code snippet of the constructor:
Code:
ViewerWidget::ViewerWidget(QWidget* iParent, const QGLWidget*
iShareWidget, Qt::WindowFlags iFlags)
: osgQt::GLWidget(iParent, iShareWidget, iFlags)
,timer(0)
{
osgViewer::View* view = new osgViewer::View;
view-setName(Main view);
addView(view);
view-setCamera(createCamera(viframework::viosg::screenWidth(),
viframework::viosg::screenHeight()));
view-setCameraManipulator(new osgGA::TrackballManipulator);
initWindowManager(view);
}
osg::Camera* ViewerWidget::createCamera(int width, int height)
{
osg::ref_ptrosg::Camera camera = new osg::Camera;
camera-setGraphicsContext(new osgQt::GraphicsWindowQt(this));
camera-setClearColor(osg::Vec4(0.2, 0.2, 0.6, 1.0));
camera-setViewport(new osg::Viewport(0, 0, width, height));
double aspect_ratio =
2.0*static_castdouble(width)/static_castdouble(height);
camera-setProjectionMatrixAsPerspective(30.0, aspect_ratio, 1.0,
1.0);
return camera.release();
}
void ViewerWidget::initWindowManager(osgViewer::View* iView)
{
osg::ref_ptrosgWidget::WindowManager wm = new
osgWidget::WindowManager(iView, 1280.0f, 1024.0f, MASK_2D,
osgWidget::WindowManager::WM_USE_RENDERBINS);
osg::Camera* camera = wm-createParentOrthoCamera();
SceneManager manager;
manager.getRoot()-addChild(camera);
manager.setWindowManager(wm);
wm-resizeAllWindows();
iView-addEventHandler(new osgWidget::MouseHandler(wm));
iView-addEventHandler(new osgWidget::ResizeHandler(wm, camera));
}
unsigned int viframework::viosg::screenHeight()
{
osg::GraphicsContext::WindowingSystemInterface* wsi =
osg::GraphicsContext::getWindowingSystemInterface();
osg::GraphicsContext::ScreenSettings settings;
osg::GraphicsContext::Traits traits;
wsi-getScreenSettings(traits, settings);
return static_castunsigned int(settings.height);
}
unsigned int viframework::viosg::screenWidth()
{
osg::GraphicsContext::WindowingSystemInterface* wsi =
osg::GraphicsContext::getWindowingSystemInterface();
osg::GraphicsContext::ScreenSettings settings;
osg::GraphicsContext::Traits traits;
wsi-getScreenSettings(traits, settings);
return static_castunsigned int(settings.width);
}
Cheers,
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=57362#57362
___
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] v3.0 release of osgWorks and osgBullet
Thanks for the updates Paul, great to see you able to span such a range of OSG versions too ;-) On 18 November 2013 18:07, Paul Martz skewmat...@gmail.com wrote: Hi all -- I've now tagged new v3.0 releases of osgWorks and osgBullet, which are compatible with the current OSG v3.3.0 release, and backwards compatible to OSG v2.8.5. Here are URLs for the project web pages: http://osgworks.googlecode.com http://osgbullet.googlecode.com -- Paul Martz Skew Matrix Software LLC ___ 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] osgEarth 2.5 released!
Congrats Glenn G. Gordon Tomlinson - TeamRV Sustainment Manager/Chief Engineer(RemoteView) Overwatch An Operating Unit of Textron Systems [cid:image005.jpg@01CEE69F.0A10BA20] [rv4-2] __ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Glenn Waldron Sent: Thursday, November 21, 2013 9:30 AM To: OpenSceneGraph Users Subject: [osg-users] osgEarth 2.5 released! Friends, The osgEarth team is proud to announce the release of Version 2.5! osgEarth is a cross-platform Terrain and Mapping SDK built on top of OpenSceneGraph. Visit http://osgearth.orghttp://osgearth.org/ to get started. Head right over to the repo tag and release notes for 2.5 on GitHub: https://github.com/gwaldron/osgearth/releases/tag/osgearth-2.5 Peruse the online documentation: http://docs.osgearth.org/en/latest/ Enjoy!! Glenn Waldron / Pelican Mapping / @glennwaldron inline: image005.jpginline: image006.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] wrong graphics after removing geometry deprecated methods
Thanks Robert for the reply. In fact I verified that osg example osgviewerQt.cpp works fine witn 3.1.8. I mean I downloded osg zip file, run cmake gui, generated a VS 2010 express ed solution and built from there, lobs, ive plug-in and the the example. Modified the example just to load my ive file, just that. Anyway the problem appears with 3.1.9. Then I tried my own application with osg 3.2.0 and it was not working too. The same happens for my application with 3.1.9 and 3.1.10. On the contrary it works fine with 3.1.8. After that I tried building osgviewerQt.cpp example with osg 3.2.0 and in fact it works. Now, I have to understand why my application behaves like the example built against osg 3.1.9 while the osg example works fine. It seems I have to search the forum for an old discussion. There's also another strange behavior I found moving from osg 3.0.1 to a newer release. It is related to osgWidgets. Basically I have a qt application and for sure in osg 3.1.8 osgWidgets are much smaller than their size before I interactively resize the viewer (or the main window that contains the viewer). Is this also a known issue? Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57358#57358 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
