[osg-users] non-solid texture color and osg::Image.setImage
I generate a texture as follows:
osg::Texture2D * map ()
{
int width = 38, height = 40;
osg::Texture2D * map = new osg::Texture2D;
map - setTextureSize (width, height);
map - setFilter (osg::Texture2D::MIN_FILTER,
osg::Texture2D::LINEAR);
map - setFilter (osg::Texture2D::MAG_FILTER,
osg::Texture2D::LINEAR);
osg::Image * image = new osg::Image;
unsigned char * data = new unsigned char [width * height];
for ( unsigned y = 0; y height ; y ++ )
for( unsigned x = 0; x width; x ++ ) {
int random = rand () % 5000;
data [y * width + x] = (unsigned char) x * y;
}
image - setImage (width, height,
1,
4,
GL_RGBA,
GL_UNSIGNED_BYTE,
data,
osg::Image::NO_DELETE
);
map - setImage (image);
return map;
}
However, despite different values the data placed in the osg::Image buffer data
a texture always it is displayed by solid color.
Color changes depending on value of parameters: width, height, 1, 4, GL_RGBA,
GL_UNSIGNED_BYTE,but always stays as solid.
How i can make that each point of a texture was displayed by the color set in
the buffer data?
Where I can read more detailed documentation on osg:: Image.setImage?
thanks,
sergey
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40728#40728
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] non-solid texture color and osg::Image.setImage
Hi,
for an RGBA texture you would need data to be of size width*height*4.
Also, not sure what your magic 4 is in image - setImage. Put GL_RGBA
instead of 4.
Try:
image - setImage (width, height, 1,
GL_RGBA,
GL_RGBA,
GL_UNSIGNED_BYTE,
data,
osg::Image::NO_DELETE
);
jp
On 22/06/11 08:17, Sergey Alekseev wrote:
I generate a texture as follows:
osg::Texture2D * map ()
{
int width = 38, height = 40;
osg::Texture2D * map = new osg::Texture2D;
map - setTextureSize (width, height);
map - setFilter (osg::Texture2D::MIN_FILTER,
osg::Texture2D::LINEAR);
map - setFilter (osg::Texture2D::MAG_FILTER,
osg::Texture2D::LINEAR);
osg::Image * image = new osg::Image;
unsigned char * data = new unsigned char [width * height];
for ( unsigned y = 0; y height ; y ++ )
for( unsigned x = 0; x width; x ++ ) {
int random = rand () % 5000;
data [y * width + x] = (unsigned char) x * y;
}
image - setImage (width, height,
1,
4,
GL_RGBA,
GL_UNSIGNED_BYTE,
data,
osg::Image::NO_DELETE
);
map - setImage (image);
return map;
}
However, despite different values the data placed in the osg::Image buffer data
a texture always it is displayed by solid color.
Color changes depending on value of parameters: width, height, 1, 4, GL_RGBA,
GL_UNSIGNED_BYTE,but always stays as solid.
How i can make that each point of a texture was displayed by the color set in
the buffer data?
Where I can read more detailed documentation on osg:: Image.setImage?
thanks,
sergey
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40728#40728
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac OS X windowing system related issue (maybe)
Thank you Stephan, I've tried by executing getWindowingSystemInterface() before opening the settings window but unfortunately it didn't help. On the other hand, I tried to call the viewer's realize() method BEFORE opening the settings window and now it has focus, can be moved and it works as expected...BUT, when the settings window is shown, I also see the viewer's window (fullscreen and filled with white color) just behind the settings window...when I close the latter, the viewer shows my scene normally. This is close to the expected behavior except for the viewer's window 'already' showing behind the settings window (it should be shown only after the user closes the settings windows). I guess that the camera settings window is created as a child of the OSG application window, so it behaves normally only when the application window's creation has completed...don't know. Maybe I should perform only a part of what happens in the realize() method? Regards. Alessandro On Tue, Jun 21, 2011 at 11:40 PM, Stephan Huber ratzf...@digitalmind.de wrote: Hi Alessandro, Am 21.06.11 22:35, schrieb Alessandro Terenzi: If this can help, when I built OSG I chose 'Carbon' as windowing system, I built OSG as frameworks and I'm building my OSG application as a console application. If I build my application as an app bundle (instead of a try creating the WindowSystemInterface via osg::GraphicsContext::getWindowingSystemInterface() before opening the settings-dialog. the WindowingSystemInterface does some fancy things, so that windows opened by a console-app work correctly. Perhaps that helps. cheers, Stephan ___ 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] Mac OS X windowing system related issue (maybe)
Thank you Stephan, I've tried by executing getWindowingSystemInterface() before opening the settings window but unfortunately it didn't help. On the other hand, I tried to call the viewer's realize() method BEFORE opening the settings window and now it has focus, can be moved and it works as expected...BUT, when the settings window is shown, I also see the viewer's window (fullscreen and filled with white color) just behind the settings window...when I close the latter, the viewer shows my scene normally. This is close to the expected behavior except for the viewer's window 'already' showing behind the settings window (it should be shown only after the user closes the settings windows). I guess that the camera settings window is created as a child of the OSG application window, so it behaves normally only when the application window's creation has completed...don't know. Maybe I should perform only a part of what happens in the realize() method? Regards. Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40730#40730 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
Hi Robert and OSG community, my first post here :) OSG 3.0 RC2 in Release mode was built fine here on Debian Testing x86_64, using g++ 4.6. I just got lots of warnings like warning: variable ‘xyz’ set but not used [-Wunused-but-set-variable]. (This type of warning is new in gcc 4.6) I ran alot of the examples, which worked ok as far as I can tell, except for: 1) osgmotionblur, which shows the model but logs this output to the console: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) 2) osgtexture2D, which, after some time of running ok, either aborts with terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc or with a segfault. GPU is an ATI HD4870 using the fglrx 11.4-2 driver. Compiling the RC2 against GL3 worked flawlessly as well. Greetings Stephan On 21.06.2011 12:58, Robert Osfield wrote: Hi All, I have just tagged the second 3.0.0 release candidate, you can get the source from: source package : OpenSceneGraph-3.0.0-rc2.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-3.0.0-rc2 OpenSceneGraph Feedback from the community on the state of the 3.0 branch and rc1 has been pretty positive so it does look like we are in a pretty good state for the final 3.0.0 stable release. While feedback has been positive it does concern me is that volume of feedback from the community is still rather low, suggesting that the release candidate 1 and the OSG-3.0 branch haven't recieved a lot of widespread testing yet, so perhaps we might be lulling ourselves into a false sense of security. What we really need now is more widespread testing so we can catch any problems that might be present on more niche usage cases or the less comonly used build platforms.Almost always right away a stable release we get feedback from the community that there is a build issue or a feature regression that could have easily been resolved prior to the release, but the problems slipped through because those users who come across the issues didn't actually test the software prior to release. I would encourage everyone in the community not to assume just because others are doing testing and providing positive feedback that things will also work fine for you, assume that there will be problems and to make sure that problems these problems get resolved come come forward and test the software and tells us about the problems. Right now is great opportunity to get those bugs resolved, I and others are primed to investigate and resolved them. After the stable release you'll have missed the boat - we'll be on holiday or focussing on other work. So please test, it's your own as much as everyone elses good. Thanks in advance, Robert. -- Changes checked in since 3.0.0-rc1 are: 2011-06-21 10:07 robert * src/osg/glu/libtess/tess.h: Merged changeset 12581 from svn/trunk to address VisualStudio warning 2011-06-21 09:58 robert * src/osgPlugins/fbx/WriterCompareTriangle.cpp, src/osgPlugins/fbx/WriterCompareTriangle.h, src/osgPlugins/fbx/fbxMaterialToOsgStateSet.cpp, src/osgPlugins/fbx/fbxMaterialToOsgStateSet.h, src/osgPlugins/fbx/fbxRLight.cpp, src/osgPlugins/fbx/fbxRMesh.cpp, src/osgPlugins/fbx/fbxRNode.cpp: Merged from svn/trunk warnings fixes provided by Changeset 12582 from Michael Platings, along with addition of returns at ends of files and changes to tabs to four spaces. 2011-06-20 19:41 robert * CMakeLists.txt: Updated release candidate number 2011-06-20 19:37 robert * src/osgPlugins/bmp/ReaderWriterBMP.cpp, src/osgPlugins/png/ReaderWriterPNG.cpp, src/osgPlugins/tga/ReaderWriterTGA.cpp: Merged from svn/trunk, r12574. From Farshid Lashkari, BGR write support for BMP, PNG and TGA 2011-06-20 19:33 robert * examples/osgphotoalbum/PhotoArchive.cpp, src/osg/ImageUtils.cpp, src/osg/OcclusionQueryNode.cpp, src/osgDB/ExternalFileWriter.cpp, src/osgDB/InputStream.cpp, src/osgDB/OutputStream.cpp, src/osgPlugins/Inventor/ConvertToInventor.cpp, src/osgPlugins/Inventor/ReaderWriterIV.cpp, src/osgPlugins/OpenFlight/expGeometryRecords.cpp, src/osgPlugins/cfg/CameraConfig.cpp, src/osgPlugins/freetype/FreeTypeLibrary.cpp, src/osgPlugins/geo/ReaderWriterGEO.cpp, src/osgPlugins/geo/osgGeoNodes.h, src/osgPlugins/md2/ReaderWriterMD2.cpp, src/osgPlugins/pic/ReaderWriterPIC.cpp, src/osgPlugins/ply/plyfile.cpp, src/osgPlugins/pvr/ReaderWriterPVR.cpp, src/osgPlugins/shp/ESRIShapeParser.cpp, src/osgPlugins/shp/XBaseParser.cpp, src/osgPlugins/zip/unzip.cpp, src/osgShadow/MinimalCullBoundsShadowMap.cpp, src/osgViewer/ScreenCaptureHandler.cpp,
Re: [osg-users] Bottleneck in osgText::Text
Hi John,
There is rather too little detail about the performance you are
seeing, how many text items you have, how many you are change per
frame, whether you've compiled with debug and are profiling this, what
platform you are working with, what you hardware is, what happens to
your update, cull and draw times
Given these unknowns we can't really give a guess as what might be and
what you might be able to do about it.
Robert.
On Wed, Jun 22, 2011 at 1:22 AM, phishja...@yahoo.com
phishja...@yahoo.com wrote:
I was profiling my application today and found that the overall performance
bottleneck was in osgText::Text.
I built up a multi-line std::string on every frame with some changing data in
it. I then called setText on my osg::ref_ptrosgText::Text member variable
and passed in the std::string. The profiler identified the setText line as
the bottleneck for the entire (large) application, cutting my frame rate in
more
than half. Any idea why this might be a bottleneck or how I might speed
things
up? It seems like a pretty basic action after a cursory look at the OSG
source
code behind it.
std::string outputText;
for(size_t i = 0; i about7; i++)
{outputText += getData(i) + \n;}
this-_text-setText(outputText);
Thanks.
- John Farrier
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
Hi Stephan, On Wed, Jun 22, 2011 at 8:57 AM, Stephan Wenglorz stephan.maku...@gmx.net wrote: my first post here :) Welcome and thanks for pitching in with testing the release ;-) OSG 3.0 RC2 in Release mode was built fine here on Debian Testing x86_64, using g++ 4.6. I just got lots of warnings like warning: variable ‘xyz’ set but not used [-Wunused-but-set-variable]. I have g++ 4.5.2 and it doesn't support -Wunused-but-set-variable so can't review these warnings. They'll likely be all benign warnings so not critical to fix for 3.0.0. Could you post the full warnigns as text file so I can quickly look through them to see if there are any possible bugs that they might be highlighting? (This type of warning is new in gcc 4.6) I ran alot of the examples, which worked ok as far as I can tell, except for: 1) osgmotionblur, which shows the model but logs this output to the console: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) This is because the ATI driver not yet support the accumulation buffer that the osgmotionblurr example uses. We can implement motion blurr using render to texture but the point of this example is to demonstate use of the accumulation buffer as much as motion blurr. A fix would probably be to see if we can automatically detect support for the accumulation buffer and then not run the viewer if it's not available. 2) osgtexture2D, which, after some time of running ok, either aborts with terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc or with a segfault. This is will be a driver bug. It is frustruting that such a simple test app with simply GL usuage might fail though as it suggests that more problems would ensure in more complex GL usage. GPU is an ATI HD4870 using the fglrx 11.4-2 driver. Compiling the RC2 against GL3 worked flawlessly as well. Thanks for the testing. The AMD/ATI driver/functionality issues are something that AMD really need to look at. The warnings we can either ignore, fix or just suppress for the release. Fixing warnings might be preferrable if fixing them is a low risk to code portability and robustness - we do have to be careful about widespread warning fixes as it's easy to make mistakes and unintentially break code, one only needs to make 1 mistake in 100 warnings fixes for there to be a serious regression. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac OS X windowing system related issue (maybe)
I finally managed to solve the issue: I called setUpViewAcrossAllScreens() before opening the settings window. What does setUpViewAcrossAllScreens do? Cheers. Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40735#40735 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Potential OSG 3.0 --run-on-demand regression
Hi Tamer, Thanks for spotting this regression. The bug came about due to me tightening up the event traversal so that it only handles events uptill the viewer.advance(), which prevents events having negative times w.r.t the frame event. Unfortunately this fix meant that no events were being processed when using --run-on-demand as this support doesn't event advance the frame till an event comes in. I have changed the cutoff time for events for the case of --run-on-demand so it behaves the way it used to. Robert. On Tue, Jun 21, 2011 at 4:44 PM, Tamer Fahmy tamer.fa...@gmail.com wrote: Hi all, tested OpenSceneGraph 3.0-rc2 on Ubuntu 10.10 with NVidia 270.41.19, which builds and runs just fine. However, I noticed that (at least on my system) trying to run e.g. 'osgviewer --run-on-demand cessna.osg' renders the first frame just fine, but then apparently frame updates aren't triggered by any further input events. Reverting the changes of src/osgViewer/Viewer.cpp and src/osgViewer/CompositeViewer.cpp from r12523 to the previous r12294 makes it work again. Anyone else able to reproduce that behavior, too? Thanks for all the great work on OpenSceneGraph and good luck with the upcoming release, tamer. ___ 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] Potential OSG 3.0 --run-on-demand regression
Hi Tamer et. al, On Wed, Jun 22, 2011 at 10:10 AM, Robert Osfield robert.osfi...@gmail.com wrote: I have changed the cutoff time for events for the case of --run-on-demand so it behaves the way it used to. Forgot to mention that this fix is now checked into svn/trunk and the OSG-3.0 branch. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] non-solid texture color and osg::Image.setImage
Hi, JP, thanks you for your answer. I have made as you wrote and have received - the same solid texture color. Only has changed color of a texture: from dark lila to dark grey. thank you, sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40738#40738 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for OSG-3.0 branch tomorrow!
Hi Ryan, I've used the latest rev of cppcheck in their git repository but don't get a fraction of the warnigns that you do. I've addressed the ones that I can fix and these were checked in for the rc2, two of the warnings can't be fixed as the leak warnings it suggested are associated with an interpretation of putenv behaviour that is only valid for some implementations. What command line options did you use when running cppcheck? I'm using the cppcheck . 2 trunk.txt Suggested in the cppcheck -h. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
Hello Robert, On 22.06.2011 10:28, Robert Osfield wrote: Hi Stephan, On Wed, Jun 22, 2011 at 8:57 AM, Stephan Wenglorz stephan.maku...@gmx.net wrote: my first post here :) Welcome and thanks for pitching in with testing the release ;-) Thank you! OSG 3.0 RC2 in Release mode was built fine here on Debian Testing x86_64, using g++ 4.6. I just got lots of warnings like warning: variable ‘xyz’ set but not used [-Wunused-but-set-variable]. I have g++ 4.5.2 and it doesn't support -Wunused-but-set-variable so can't review these warnings. They'll likely be all benign warnings so not critical to fix for 3.0.0. Could you post the full warnigns as text file so I can quickly look through them to see if there are any possible bugs that they might be highlighting? File is attached. (This type of warning is new in gcc 4.6) I ran alot of the examples, which worked ok as far as I can tell, except for: 1) osgmotionblur, which shows the model but logs this output to the console: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) This is because the ATI driver not yet support the accumulation buffer that the osgmotionblurr example uses. We can implement motion blurr using render to texture but the point of this example is to demonstate use of the accumulation buffer as much as motion blurr. A fix would probably be to see if we can automatically detect support for the accumulation buffer and then not run the viewer if it's not available. Ok, and I see this has already been known for some time, sorry, I should have searched this list first. 2) osgtexture2D, which, after some time of running ok, either aborts with terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc or with a segfault. This is will be a driver bug. It is frustruting that such a simple test app with simply GL usuage might fail though as it suggests that more problems would ensure in more complex GL usage. Thanks for the clarification. Would it help to file a bug report at ATI in such cases? GPU is an ATI HD4870 using the fglrx 11.4-2 driver. Compiling the RC2 against GL3 worked flawlessly as well. Thanks for the testing. The AMD/ATI driver/functionality issues are something that AMD really need to look at. The warnings we can either ignore, fix or just suppress for the release. Fixing warnings might be preferrable if fixing them is a low risk to code portability and robustness - we do have to be careful about widespread warning fixes as it's easy to make mistakes and unintentially break code, one only needs to make 1 mistake in 100 warnings fixes for there to be a serious regression. Robert. I agree, as you said these warnings seem to be no problem, just some superfluous variables, so I would ignore them for now rather than risk to break something so close to the release. Greetings Stephan /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osg/ShapeDrawable.cpp: In member function âvoid PrimitiveShapeVisitor::createHalfSphere(unsigned int, unsigned int, float, int, float, const Matrix)â: /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osg/ShapeDrawable.cpp:1409:11: warning: variable ânzBaseâ set but not used [-Wunused-but-set-variable] /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osg/ShapeDrawable.cpp:1410:11: warning: variable ânRatioBaseâ set but not used [-Wunused-but-set-variable] /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgUtil/DelaunayTriangulator.cpp: In function âosgUtil::Triangle_list osgUtil::fillHole(osg::Vec3Array*, std::vectorunsigned int, std::allocatorunsigned int )â: /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgUtil/DelaunayTriangulator.cpp:569:27: warning: variable âptestâ set but not used [-Wunused-but-set-variable] /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgUtil/DelaunayTriangulator.cpp: In member function âbool osgUtil::DelaunayTriangulator::triangulate()â: /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgUtil/DelaunayTriangulator.cpp:979:45: warning: variable âcurpâ set but not used [-Wunused-but-set-variable] /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgUtil/RenderStage.cpp: In member function âvoid osgUtil::RenderStage::runCameraSetUp(osg::RenderInfo)â: /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgUtil/RenderStage.cpp:631:18: warning: variable âstencilAttachedâ set but not used [-Wunused-but-set-variable] /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgText/FadeText.cpp: In member function âvoid FadeTextPolytopeData::buildPolytope()â: /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgText/FadeText.cpp:74:20: warning: variable âedge23â set but not used [-Wunused-but-set-variable] /home/stephan/Dev/LibSources/OpenSceneGraph-3.0.0-rc2/src/osgText/FadeText.cpp:75:20: warning: variable âedge30â set but not used
Re: [osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
Hi Stephan, On Wed, Jun 22, 2011 at 11:00 AM, Stephan Wenglorz stephan.maku...@gmx.net wrote: I agree, as you said these warnings seem to be no problem, just some superfluous variables, so I would ignore them for now rather than risk to break something so close to the release. I've done a reivew of all the warnings and most are indeed benign cases of variables being set and then never used. In a couple of cases it suggest that return codes were being ignored when warnings should have been emitted to I've added these. Most cases were just places where a variable and it's setting could be safely removed so I've done this and removing code that isn't used should be very low risk. Since the changes looked low risk I've checked them into both svn/trunk and OSG-3.0 branch so fingers crossed the next release candidate with be close to warning free under g++ 4.6. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] non-solid texture color and osg::Image.setImage
Hi, On 22/06/11 11:29, Sergey Alekseev wrote: Hi, JP, thanks you for your answer. I have made as you wrote and have received - the same solid texture color. Only has changed color of a texture: from dark lila to dark grey. how are you applying the texture to geometry? Are your texture coordinates OK? jp thank you, sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40738#40738 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing a workaround for fullscreen toggling issues under modern X11 window managers
Hi Robert, Ok, I have yesterday tested fvwm with the viewer changes. This works so far. On Tuesday 21 June 2011, Robert Osfield wrote: When users attempt to do things is awkward ways, especially when grampling with lower level facilities, it's a warning sign to me that the OSG is make the problem more difficult and probably needs refactoring. Sometimes it's just the users overcomplicating things for little reason, but often there will be an underlying design issue that they are trying to workaround. It's doesn't always mean I can see a straight forward solution... but occassionally a small tweak to the OSG can make a big diffrence. Yes. The problem is with the cull callback in a Geode during the cull stage. The cull callback in a geode cannot do much. It just calls an empty traverse method in a geode. Then past that all drawables are *unconditionally* - from the point of the geodes cull visitor - put into the render graph. This lies with Geode's having Drawable children that aren't Nodes so the usual traversal rules don't apply. One modification to the OSG that I have considered for a while is to make a Drawable a Node. This has a number of knock on effects though so something I'll need to consider rather carefully. Hmm, That would reduce the Geode to just being a Group. At first it would probably help when the NodeVisitor is able to visit Drawables using the usual accept mehtods or something like that. Then we could probably just use the Geodes traverse method to walk the drawables. One dfficulty in this approach is the Bilboard implementation that does little more then just a traversal of all Drawables. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing a workaround for fullscreen toggling issues under modern X11 window managers
Hi Mathias, 2011/6/22 Mathias Fröhlich m.froehl...@science-computing.de: Ok, I have yesterday tested fvwm with the viewer changes. This works so far. Thanks for the testing. Looks like the viewer changes for fullscreen toggling are good to go. One modification to the OSG that I have considered for a while is to make a Drawable a Node. This has a number of knock on effects though so something I'll need to consider rather carefully. Hmm, That would reduce the Geode to just being a Group. Probably/possibly. One of the challenge with making a Drawable a Node is that retraining backwards compatibility so to achieve this we'd still have to carry around classes that aren't that neccessary anyone. I'm not sure how far we'd be able to retain compatibility or how much this compatibility might compromise the cleanness of the design. It's one of those tasks that one really has to roll ones sleves up and do the changes and see what happens. At first it would probably help when the NodeVisitor is able to visit Drawables using the usual accept mehtods or something like that. Then we could probably just use the Geodes traverse method to walk the drawables. One dfficulty in this approach is the Bilboard implementation that does little more then just a traversal of all Drawables. I don't see any problems with handling subclasses from Geode, it'd be bit like how LOD subclasses from Group - it add a per child property that the the traverse method handles in a special way. A NodeCallback that overrides the traverse then would have to handle the special functionality of a Billboard. In the case of a Billboard we'd probably want to have a special handling of cases when chidlren are Drawable rather than Node's, as Drawables you can just manage the modelview matrix directly and don't need to worry about the view frustum transformation, while normal Nodes you have to push/pop the view frustum as we do right now for the normal Transform nodes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
Sorry abou this unsavoury spam getting through - it looks to be a case of a guinuine osg-user that has their mail account compromised by the spammers. I've unsubscribed the problem account and notified the account holder. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] picking vertices
Hi,
I want to let my user pick individual vertices on a model. I used the osgPick
example code to get the picking of an object working great, but when I tried to
use the code to pick the vertex it is not really working correctly, and I am
not sure what I am doing wrong. Here is the code I am using:
Code:
//Get the selected vertex.
const osgUtil::LineSegmentIntersector::Intersection::IndexList vil =
hitr-indexList;
osg::Geometry *osgGeom = dynamic_castosg::Geometry *(hitr-drawable.get());
if(vil.size() 0 osgGeom)
{
osg::ref_ptrosg::Vec3Array aryVert =
dynamic_castosg::Vec3Array*(osgGeom-getVertexArray());
int iSelVert = vil[0];
m_vSelectedVertex = (*aryVert)[iSelVert];
}
else
m_vSelectedVertex.set(0, 0, 0);
I assumed that the index list that is returned back would be of the index of
vertices sorted by the closest vertex. When I tested this though it sometimes
gave me the same number even when I clicked different vertices. It was always
three numbers in the index list as well. Not sure why. Is there anyone out
there who can clear up exactly what the index list is returning to me, and how
I can use that to get the vertex that was clicked on?
Thank you!
Cheers,
David[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40752#40752
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Potential issues in NodeVisitor subclasses
Hi Ryan, NodeVisitor's subclasses are meant to only override the methods they need to. It's what makes the convinient and powerful. The documented problems which the warning issue relate to aren't relevent to NodeVisitor usage. This compiler warning issue is in practice just a distraction that will lead to more code bloat and potential problems. FYI, different compilers have complained about this issue on and off for the last decade but not once in the history of the OSG has there been a bug due to this issue. Adding a using osg::NodeVisitor::apply to all subclasses just to quieten down a silly warning is what I would call a good coding practice. Robert. On Wed, Jun 22, 2011 at 5:17 PM, Ryan Pavlik rpav...@iastate.edu wrote: All, I've been working to get all the code I use to compile cleanly using Clang, which is a faster, stricter, yet more helpful compiler than gcc. I actually would like to get things to build cleanly with -Wall -Wextra in Clang since those are often potential errors. I'll submit a full warnings log in a later email along with the build patches, but I wanted to mention one issue separately. Apparently resolution of overloaded functions takes place on the name only, rather than the full signature, which interacts with virtual functions. In NodeVisitor, a number of virtual functions are declared with the same name, apply, as required for the visitor pattern. It seems that according to the standard, unexpected things may happen if not all overloads are implemented in a subclass. The best discussions of this issue that I've found so far are here: http://www.codeguru.com/forum/showthread.php?t=459396 https://groups.google.com/forum/#!topic/mozilla.dev.builds/60CACLzH_YM http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423 https://www.securecoding.cert.org/confluence/display/cplusplus/OOP03-CPP.+Prefer+not+to+overload+virtual+functions - note that the ideal solution is only mentioned in the comments The apparent best solution is for all NodeVisitor subclasses to include a line equivalent to: using osg::NodeVisitor::apply; (replacing osg::NodeVisitor with a more specialized base class where not inheriting directly from NodeVisitor) That said, I haven't worked on this too long or done extensive testing, but it is an issue I wanted to bring up. Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com ___ 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] picking vertices
HI David,
When the ray intersects a triangle it provides the three vertex
indices and the associated ratios are the baricentric coordinates
that you can use to compute the interoplate vertex, colour, tex coord
etc. There isn't an sorting of the indices to report the nearest.
Robert.
On Wed, Jun 22, 2011 at 5:19 PM, David Cofer dco...@mindcreators.com wrote:
Hi,
I want to let my user pick individual vertices on a model. I used the osgPick
example code to get the picking of an object working great, but when I tried
to use the code to pick the vertex it is not really working correctly, and I
am not sure what I am doing wrong. Here is the code I am using:
Code:
//Get the selected vertex.
const osgUtil::LineSegmentIntersector::Intersection::IndexList vil =
hitr-indexList;
osg::Geometry *osgGeom = dynamic_castosg::Geometry *(hitr-drawable.get());
if(vil.size() 0 osgGeom)
{
osg::ref_ptrosg::Vec3Array aryVert =
dynamic_castosg::Vec3Array*(osgGeom-getVertexArray());
int iSelVert = vil[0];
m_vSelectedVertex = (*aryVert)[iSelVert];
}
else
m_vSelectedVertex.set(0, 0, 0);
I assumed that the index list that is returned back would be of the index of
vertices sorted by the closest vertex. When I tested this though it sometimes
gave me the same number even when I clicked different vertices. It was always
three numbers in the index list as well. Not sure why. Is there anyone out
there who can clear up exactly what the index list is returning to me, and
how I can use that to get the vertex that was clicked on?
Thank you!
Cheers,
David[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40752#40752
___
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] OpenSceneGraph-3.0.0-rc3 tagged, and plan to final 3.0.0 release
Hi All, I have just tagged 3.0.0 release candidate 3, you can grab the source from: source package : http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.0.0-rc3.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-3.0.0-rc3 OpenSceneGraph Since rc2 I have fixed a few warnings, a regression in the run on demand, and merged a tweak to the FindCOLLADA.cmake to handle a recent update to the COLLADA-DOM install path. A full ChangeLog is added below. So far the feedback on the OSG-3.0 branch and the release candidates has continued to be pretty positive, the few problems that have coming up have been resolved easily and with changes that are low risk so I'm pretty happy that we are in good place to start thinking about tagging the final 3.0.0 release, which I will do tomorrow or Friday depending on how testing of rc3 goes. I don't have an outstanding issues to chase up now so my focus is now turning to admin side of the release - updating the NEWS.txt and the wiki page, my first crack at this was to simply edit the previous NEWS item for 2.8 just so we had some to work from, I'll need to do a lot more editing to this, suggestions welcome. http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG3.0 I have also generated the authors list using the osgversion -r ChangeLog AUTHORS.txt utility that automatically generates the authors file from the svn generated ChangeLog, with osgversion fixes any typo's of names. If you are a contributor could you please read through the authors list and if there is a mistake - such as a mispelling or your name appearing twice due to a slight variation in the name entered, then please just point me at the mistake and I'll update the code that catches and corrects this mistakes. The full list can be found at: http://www.openscenegraph.org/projects/osg/wiki/Support/Contributors/ThreePointZero Once I've tagged the final release we'll need to get binaries generated for the main dev platforms and upload to the server, and also look to getting the various software repositories like Debian to update to 3.0.0 as well. If you can help with this please come forward now so we can coordinate things. As a trial run for the binaries I would be useful to build binaries for rc3 and get these tested as well prior to the final 3.0.0 release. I'll also be updating the OpenSceneGraph-Data for the release. I've already checked all the changes into OpenSceneGraph-Data/trunk required for 3.0.0 - such as converting most of the .osg's to .osgt's and retaining the .osg' that the 3.0 book talks about. I'll create the package data package tomorrow. Finally once we've for the 3.0.0 release done, binaries uploaded, website update we'll need to pass on the news of the release out to the development community. With previous releases we've used the following SpreadTheNews wiki page to coordinate the contacting of various news sites so we don't waste time contacting the same news portal twice. http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/SpreadingTheNews Have I forgotton anything on the admin side? If so let me know. And finally... another please for more testing, just two more days left to iron out all those last minute bugs ;-) Thanks in advance for you help, Robert. -- ChangeLog since 3.0.0-rc2 2011-06-22 16:18 robert * CMakeModules/FindCOLLADA.cmake: From Magnus Kessler, I have recently installed the latest version of collada-dom on Linux, and found that the include path has changed. By default, collada-dom now installs its header files under /usr/local/include/collada-dom or/usr/include/collada- dom. The attached FindCollada.cmake has been updated to look for these locations in addition to the previous candidate locations. 2011-06-22 15:41 robert * AUTHORS.txt, ChangeLog: Updated ChangeLog and AUTHORS file for release 2011-06-22 12:45 robert * CMakeLists.txt: Updated RC number for the 3.0.0-rc3 2011-06-22 12:38 robert * applications/present3D/present3D.cpp, examples/osgdistortion/osgdistortion.cpp, examples/osgposter/osgposter.cpp, examples/osgtext3D/TextNode.cpp, examples/osgthreadedterrain/osgthreadedterrain.cpp, examples/osgvolume/osgvolume.cpp, examples/osgwidgetcanvas/osgwidgetcanvas.cpp, src/osg/ShapeDrawable.cpp, src/osgGA/NodeTrackerManipulator.cpp, src/osgGA/TerrainManipulator.cpp, src/osgParticle/FluidProgram.cpp, src/osgPlugins/Inventor/ConvertToInventor.cpp, src/osgPlugins/OpenFlight/GeometryRecords.cpp, src/osgPlugins/OpenFlight/ReaderWriterFLT.cpp, src/osgPlugins/ac/Geode.cpp, src/osgPlugins/cfg/ConfigParser.cpp, src/osgPlugins/dds/ReaderWriterDDS.cpp,
[osg-users] [osgPlugins] FBX plugin: crash if using AVI texture
Hi, I'm trying to see a simple quad with a video (AVI) texture applied. The video is played correctly by osgmovie but if I use osgviewer to open the FBX model (that uses the AVI) when execution is over osgviewer crashes. I'm using OSG 3.0.0 rc1 and the FBX was created from 3dsMax using the FBX SDK 2012. I'm attaching the FBX and OSG (if you want to try them you have to just replace the paths for the video file). I also tried with a .osg and it doens't crashes. Cheers, Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40757#40757 Attachments: http://forum.openscenegraph.org//files/video_texture_139.zip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Potential issues in NodeVisitor subclasses
On Wed, Jun 22, 2011 at 11:29 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Ryan, NodeVisitor's subclasses are meant to only override the methods they need to. It's what makes the convinient and powerful. Yes, of course - for some time I was confused on how a visitor could be implemented _without_ triggering this warning. The documented problems which the warning issue relate to aren't relevent to NodeVisitor usage. This compiler warning issue is in practice just a distraction that will lead to more code bloat and potential problems. FYI, different compilers have complained about this issue on and off for the last decade but not once in the history of the OSG has there been a bug due to this issue. Adding a using osg::NodeVisitor::apply to all subclasses just to quieten down a silly warning is what I would call a good coding practice. Yes, when thinking through it, I couldn't think of an instance in which it would affect use, since Visitors are generally only handled by a base class reference, but the warning was the most frequent. I'm unsure I understand your thoughts on a resolution - are you saying we should add using osg::NodeVisitor::apply; or that we should ignore the warning? Thanks! Ryan Robert. On Wed, Jun 22, 2011 at 5:17 PM, Ryan Pavlik rpav...@iastate.edu wrote: All, I've been working to get all the code I use to compile cleanly using Clang, which is a faster, stricter, yet more helpful compiler than gcc. I actually would like to get things to build cleanly with -Wall -Wextra in Clang since those are often potential errors. I'll submit a full warnings log in a later email along with the build patches, but I wanted to mention one issue separately. Apparently resolution of overloaded functions takes place on the name only, rather than the full signature, which interacts with virtual functions. In NodeVisitor, a number of virtual functions are declared with the same name, apply, as required for the visitor pattern. It seems that according to the standard, unexpected things may happen if not all overloads are implemented in a subclass. The best discussions of this issue that I've found so far are here: http://www.codeguru.com/forum/showthread.php?t=459396 https://groups.google.com/forum/#!topic/mozilla.dev.builds/60CACLzH_YM http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423 https://www.securecoding.cert.org/confluence/display/cplusplus/OOP03-CPP.+Prefer+not+to+overload+virtual+functions - note that the ideal solution is only mentioned in the comments The apparent best solution is for all NodeVisitor subclasses to include a line equivalent to: using osg::NodeVisitor::apply; (replacing osg::NodeVisitor with a more specialized base class where not inheriting directly from NodeVisitor) That said, I haven't worked on this too long or done extensive testing, but it is an issue I wanted to bring up. Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com ___ 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 -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Good new for IOS developers
Thanks Alessandro It's called Alien Attack, it's actually been made for a client AppToyz to go with there AppBlaster gun attachment for iphones. It should actually be released in the next week or so. I'll give you a shout when it is. Tom PS It's also free! On 21 June 2011 21:19, Alessandro Terenzi a.tere...@gmail.com wrote: Congratulation Thomas! what's your app's name? I look forward to trying it... Alessandro PS: hope it's free ;) On Tue, Jun 21, 2011 at 1:41 PM, Thomas Hogarth thomas.hoga...@gmail.comwrote: Hi All, This might have been discussed in the past but it's the first confirmation I have personally had. My first IOS app using OpenSceneGraph was approved for the app store today. I was using 2.9.15, so a pretty recent version (not recent enough to be a test of the 3.0 rc1). OpenSceneGraph was also built statically and was using the depreciated osg and imageio plugins. Thought other would be interested. Tom PS If other have submitted apps, please let me know your experience ___ 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] Potential issues in NodeVisitor subclasses
Hi Ryan, On Wed, Jun 22, 2011 at 6:35 PM, Ryan Pavlik rpav...@iastate.edu wrote: Yes, of course - for some time I was confused on how a visitor could be implemented _without_ triggering this warning. You can''t implement a vistor pattern without triggering the warning. Since the vistor pattern is such a powerful and widely used design pattern is pretty poor that the warning flags it as problem. Yes, when thinking through it, I couldn't think of an instance in which it would affect use, since Visitors are generally only handled by a base class reference, but the warning was the most frequent. I'm unsure I understand your thoughts on a resolution - are you saying we should add using osg::NodeVisitor::apply; or that we should ignore the warning? In the context of visitor this warning is false positive, so doing anything to the code just to quieten this false positive is a false positive. How much effort should one spend quietening false positives? What risks are their in doing this? Personally I'd just disable the warning. Ideally you'd be able to do this right in the base class so that you don't have to disable it for other places where the warning might be approrpiate. Failing the ability disable the warning just for a single class and it's subclasses one would have to disable the warning at the compile level. For 3.0.0 I'm not going to start chasing stuff like how to quieten down false positives, unless it's as single as CMake option or a #pragma added to an OSG header. It's both an issue of where do I spend me time now to maximize the final software quality and what risks we take with the code so close to a risk. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] FBX plugin: crash if using AVI texture
HI Alessandro, Could run a debug build and get a stack trace from the crash and then post this stack trace, it should give us a bit more of ideal of what might be at fault. Also what movie plugin are you attempting to use to play the movie? Robert. On Wed, Jun 22, 2011 at 6:32 PM, Alessandro Terenzi a.tere...@gmail.com wrote: Hi, I'm trying to see a simple quad with a video (AVI) texture applied. The video is played correctly by osgmovie but if I use osgviewer to open the FBX model (that uses the AVI) when execution is over osgviewer crashes. I'm using OSG 3.0.0 rc1 and the FBX was created from 3dsMax using the FBX SDK 2012. I'm attaching the FBX and OSG (if you want to try them you have to just replace the paths for the video file). I also tried with a .osg and it doens't crashes. Cheers, Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40757#40757 Attachments: http://forum.openscenegraph.org//files/video_texture_139.zip ___ 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] [osgPlugins] FBX plugin: crash if using AVI texture
Hi Robert, unfortunately I will not be able to try it before friday, anyway the video plugin that I use is QuickTime (the OS is Windows 7 x64, OSG is built for 32 bit and we tried with a couple of different AVIs on two PCs). Hope this helps a little. Alessandro On Wednesday, June 22, 2011, Robert Osfield robert.osfi...@gmail.com wrote: HI Alessandro, Could run a debug build and get a stack trace from the crash and then post this stack trace, it should give us a bit more of ideal of what might be at fault. Also what movie plugin are you attempting to use to play the movie? Robert. On Wed, Jun 22, 2011 at 6:32 PM, Alessandro Terenzi a.tere...@gmail.com wrote: Hi, I'm trying to see a simple quad with a video (AVI) texture applied. The video is played correctly by osgmovie but if I use osgviewer to open the FBX model (that uses the AVI) when execution is over osgviewer crashes. I'm using OSG 3.0.0 rc1 and the FBX was created from 3dsMax using the FBX SDK 2012. I'm attaching the FBX and OSG (if you want to try them you have to just replace the paths for the video file). I also tried with a .osg and it doens't crashes. Cheers, Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40757#40757 Attachments: http://forum.openscenegraph.org//files/video_texture_139.zip ___ 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] [osgPlugins] FBX plugin: crash if using AVI texture
Hi Allessandro, I've copied a .avi file I have to the name video1.avi so that the .osg and .FBX files both load the file, and by using -e ffmpeg on the command line I'm able to osgviewer to load the avi file just fine. I don't get any crashes, but I also don't get any played movie as to play them you'll need an explicit imagestream-play() call. To get around the need to explictly call play() I put together a very simple Present3D xml file to read the movie as an image, as the .osg and the .FBX. The attached test.p3d does this. To test it I also need to load the ffmpeg to handle playing the video, the command line to use is: present3D test.p3d -e ffmpeg Present3D is built as part of the OSG alongside osgviewer so you should have it built already. Press Page Down/Up or Left/Right Arraow keys to change slides and the type of rendering. With Present3D all the different options for me, all play correctly and all don't crash. Robert. test.p3d Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0-rc3 tagged, and plan to final 3.0.0 release
Hi Robert, http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG3.0 On this page, in the new features list, you mentioned user data... I think you meant the new generalized metadata system, so I changed that bullet point to better show this. After all, OSG has had user data for a long time now. Other than that, looks good. http://www.openscenegraph.org/projects/osg/wiki/Support/Contributors/ThreePointZero For the contributors list, seems you have a unicode / character encoding mismatch, because for example the ö in Mathias Fröhlich (and others) became ÷, and the é in Romano José Magacho da Silva (and others) became Ú. Other than that, looks good. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] FBX plugin: crash if using AVI texture
HI Alessandro, On Wed, Jun 22, 2011 at 8:00 PM, Alessandro Terenzi a.tere...@gmail.com wrote: unfortunately I will not be able to try it before friday, anyway the video plugin that I use is QuickTime (the OS is Windows 7 x64, OSG is built for 32 bit and we tried with a couple of different AVIs on two PCs). Friday will be too later for 3.0.0. Where the problem might lie I can't say, but it all works at least with the ffmpeg plugin under Linux, so one might consider the Quicktime plugin as being a potential cause of problems, but it just as easily code be a problem elsewhere. Quicktime used to be the only video solution under Windows but now we have the ffmpeg and the directshow plugins so if it does turn out to be the problem then you can always look into trying out these other plugins. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] FBX plugin: crash if using AVI texture
Thank you Robert for your answers, I'll try the ffmpeg plugins as soon as I'll be back to work, only one note: I've already tried the directshow plugin but, as you can see from a couple of mails of mine, without success...so far I could not find a solution for using that plugin and this is the reason I'm stll using QuickTime even on Windows. Cheers. Alessandro On Wednesday, June 22, 2011, Robert Osfield robert.osfi...@gmail.com wrote: HI Alessandro, On Wed, Jun 22, 2011 at 8:00 PM, Alessandro Terenzi a.tere...@gmail.com wrote: unfortunately I will not be able to try it before friday, anyway the video plugin that I use is QuickTime (the OS is Windows 7 x64, OSG is built for 32 bit and we tried with a couple of different AVIs on two PCs). Friday will be too later for 3.0.0. Where the problem might lie I can't say, but it all works at least with the ffmpeg plugin under Linux, so one might consider the Quicktime plugin as being a potential cause of problems, but it just as easily code be a problem elsewhere. Quicktime used to be the only video solution under Windows but now we have the ffmpeg and the directshow plugins so if it does turn out to be the problem then you can always look into trying out these other plugins. 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] improperly culled osgText
Hi,
I found another problem with invisible text today. In TextBase.cpp
there is this chunk of code at line 290:
// provide a fallback in cases where no bounding box has
been been setup so far
if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
{
// default to a zero size.
bbox.set(_position, _position);
}
else
{
osg::Matrix matrix;
matrix.makeTranslate(_position);
matrix.preMultRotate(_rotation);
bbox.expandBy(osg::Vec3(_textBB.xMin(),_textBB.yMin(),_textBB.zMin())*matrix);
bbox.expandBy(osg::Vec3(_textBB.xMax(),_textBB.yMax(),_textBB.zMax())*matrix);
}
I'm probably missing something but I don't see the logic behind the
first conditional. Does it really have a purpose or is it legacy
code? If I change the whole chunk to this then my text is displayed
properly:
osg::Matrix matrix;
matrix.makeTranslate(_position);
matrix.preMultRotate(_rotation);
bbox.expandBy(osg::Vec3(_textBB.xMin(),_textBB.yMin(),_textBB.zMin())*matrix);
bbox.expandBy(osg::Vec3(_textBB.xMax(),_textBB.yMax(),_textBB.zMax())*matrix);
--
Terry Welsh
mogumbo 'at' gmail.com
www.reallyslick.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0-rc3 tagged, and plan to final 3.0.0 release
Hi all, I gave 3.0.0-rc3 a check out here and found a few problems. These are quite possibly due to the atypical setup here, particularly the farily old version of Qt installed and possibly other factors. system:x86_64 SuSE 11.01 graphics: NVIDIA Quadro FX 1800 270.41.19 gcc: 4.3.1 Qt: 3.3.3 The example osgviewerQt comes up with solid blue background in all viewports and not other graphics. I'm unable to run the other Qt examples since we don't compile for QT_QTWEBKIT_LIBRARY. We've got Qt-4.4.3 so this could be a version mismatch. A number of other examples failed due a missing jpeg plugin. I don't know why this is a problem and haven't invesitgated it yet. Otherwise, the build seemed to go without a hickup and other then the problems mentioned the examples were working. On a very positive note 3.0.0-rc3 did quite well in the 20 year old legacy application we've recently ported to osg. -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issues centering cursor for mouselook with first-person manipulator.
No ideas floating around out there?? :( -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40772#40772 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VirtialPlanetBuilder-0.9.12 dev release tagged, and plans for VPB-1.0
Hi Robert, VPB doesn't compile with MinGW because of some errors in the FileUtils headers and source. I'd like to send my changes to osg-submissions soon. Wang Rui 2011/6/21 Robert Osfield robert.osfi...@gmail.com: Hi All, OpenSceneGraph-3.0.0 release seems to be going smoothly so it looks like I might have a little time this week to squeeze in getting VirtualPlanetBuilder to 1.0 as well. This morning I merged a couple of changes to VPB from the community and made a a little cleanup myself so it reminded me that VPB-1.0 is as long overdue as OSG-3.0 so why not go with the flow and get VPB-1.0 out the door. It's basically feature complete for it's 1.0 and has been so for quite so time now - it's just I've been so busy with the OSG and client work that it's sat a little neglected in the corner. The first step was to tag a dev release which you can now grab from: svn co http://www.openscenegraph.org/svn/VirtualPlanetBuilder/tags/VirtualPlanetBuilder-0.9.12 VirtualPlanetBuilder Could members of the community update to svn/trunk of VPB or the 0.9.12 dev release above and let me know how well things are building working on your system. If things look solid I'll just go right ahead and make the 1.0 later this week. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
