Re: [osg-users] Copying top half of image using osg::copyImage
Hi Robert,
I have indeed gone through the debugger and the values are what I would
expect. I've attached an example so you could see the issue. If I am
interpreting the osg::copyImage parameters correctly, then the if
((src_t+height) (dest_t + destImage-t())) check seems should rather be
if ((src_t+height) (srcImage-t())) if testing if the height parameter
is valid. The attached example fails the if ((src_t+height) (dest_t +
destImage-t())) check. If I remove this check from osg::copyImage, then
the output image is what I would expect.
Thanks,
Donny
On Wed, Apr 22, 2009 at 1:10 PM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Donald,
Have you gone through your code with a debugger at all? Check what
value of nHalfSrcHeight you are getting.
One fix to your code you could do would be to use /2 rather *0.5 as /2
can use integer maths, while *0.5 requires pImageSrc-t() to be
automatically promoted to a float for it work.
Robert.
On Wed, Apr 22, 2009 at 5:57 PM, Donald Cipperly osgc...@gmail.com
wrote:
Hi Robert,
I'm trying to copy the top half of an existing image using
osg::copyImage.
I do this as such:
// Read in source image
osg::ref_ptr osg::Image pImageSrc = osgDB::readImageFile(
test.jpg
);
int nHalfSrcHeight = (int)(pImageSrc-t() * 0.5);
// Allocate destination image
osg::Image *pImageDest = new osg::Image();
pImageDest-allocateImage(pImageSrc-s(), nHalfSrcHeight,
pImageSrc-r(), pImageSrc-getPixelFormat(), pImageSrc-getDataType());
// Copy top half of source image to destination
myCopyImage( pImageSrc.get(), 0, (nHalfSrcHeight-1), 0,
pImageSrc-s(),
nHalfSrcHeight, pImageSrc-r(),
pImageDest, 0, 0, 0, false );
This appears to be the correct way to perform this operation. Is this
correct? If so, then line 210 of osg/ImageUtils.cpp appears to be
incorrect
as it notifies that my input height is too large. And indeed when I
commend
out the block below in ImageUtils.cpp, then it outputs the top half of my
image as I expect.
if ((src_t+height) (dest_t + destImage-t()))
{
osg::notify(osg::NOTICE)copyImage(srcImage, src_s,
src_t, src_r, width, height,
depthstd::endl;
osg::notify(osg::NOTICE) destImage,
dest_s,
dest_t, dest_r, doRescale)std::endl;
osg::notify(osg::NOTICE) input height too
large.std::endl;
return false;
}
Thanks for any help you can provide,
Donny
___
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
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osg/ImageUtils
int main( int, char **)
{
// Read in source image...clockface.JPG from the base
OpenSceneGraph-Data
osg::ref_ptr osg::Image pImageSrc = osgDB::readImageFile(
Images/clockface.JPG );
int nHalfSrcHeight = pImageSrc-t() / 2;
// Allocate destination image
osg::Image *pImageDest = new osg::Image();
pImageDest-allocateImage(pImageSrc-s(), nHalfSrcHeight,
pImageSrc-r(), pImageSrc-getPixelFormat(), pImageSrc-getDataType());
// Copy top half of source image to destination
osg::copyImage( pImageSrc.get(), 0, (nHalfSrcHeight-1), 0,
pImageSrc-s(), nHalfSrcHeight, pImageSrc-r(),
pImageDest, 0, 0, 0, false );
// Write the destination image to file
osgDB::writeImageFile( *pImageDest,
std::string(C:/OpenSceneGraph-Data/Images/clockfaceTop.jpg) );
return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Copying top half of image using osg::copyImage
Hi Robert,
I'm trying to copy the top half of an existing image using osg::copyImage.
I do this as such:
// Read in source image
osg::ref_ptr osg::Image pImageSrc = osgDB::readImageFile( test.jpg
);
int nHalfSrcHeight = (int)(pImageSrc-t() * 0.5);
// Allocate destination image
osg::Image *pImageDest = new osg::Image();
pImageDest-allocateImage(pImageSrc-s(), nHalfSrcHeight,
pImageSrc-r(), pImageSrc-getPixelFormat(), pImageSrc-getDataType());
// Copy top half of source image to destination
myCopyImage( pImageSrc.get(), 0, (nHalfSrcHeight-1), 0, pImageSrc-s(),
nHalfSrcHeight, pImageSrc-r(),
pImageDest, 0, 0, 0, false );
This appears to be the correct way to perform this operation. Is this
correct? If so, then line 210 of osg/ImageUtils.cpp appears to be incorrect
as it notifies that my input height is too large. And indeed when I commend
out the block below in ImageUtils.cpp, then it outputs the top half of my
image as I expect.
if ((src_t+height) (dest_t + destImage-t()))
{
osg::notify(osg::NOTICE)copyImage(srcImage, src_s,
src_t, src_r, width, height, depthstd::endl;
osg::notify(osg::NOTICE) destImage, dest_s,
dest_t, dest_r, doRescale)std::endl;
osg::notify(osg::NOTICE) input height too large.std::endl;
return false;
}
Thanks for any help you can provide,
Donny
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Copying top half of image using osg::copyImage
oops, mis-copied a line from below:
osg::copyImage( pImageSrc.get(), 0, (nHalfSrcHeight-1), 0, pImageSrc-s(),
nHalfSrcHeight, pImageSrc-r(),
pImageDest, 0, 0, 0, false );
- Donny
On Wed, Apr 22, 2009 at 11:57 AM, Donald Cipperly osgc...@gmail.com wrote:
Hi Robert,
I'm trying to copy the top half of an existing image using osg::copyImage.
I do this as such:
// Read in source image
osg::ref_ptr osg::Image pImageSrc = osgDB::readImageFile( test.jpg
);
int nHalfSrcHeight = (int)(pImageSrc-t() * 0.5);
// Allocate destination image
osg::Image *pImageDest = new osg::Image();
pImageDest-allocateImage(pImageSrc-s(), nHalfSrcHeight,
pImageSrc-r(), pImageSrc-getPixelFormat(), pImageSrc-getDataType());
// Copy top half of source image to destination
myCopyImage( pImageSrc.get(), 0, (nHalfSrcHeight-1), 0, pImageSrc-s(),
nHalfSrcHeight, pImageSrc-r(),
pImageDest, 0, 0, 0, false );
This appears to be the correct way to perform this operation. Is this
correct? If so, then line 210 of osg/ImageUtils.cpp appears to be incorrect
as it notifies that my input height is too large. And indeed when I commend
out the block below in ImageUtils.cpp, then it outputs the top half of my
image as I expect.
if ((src_t+height) (dest_t + destImage-t()))
{
osg::notify(osg::NOTICE)copyImage(srcImage, src_s,
src_t, src_r, width, height, depthstd::endl;
osg::notify(osg::NOTICE) destImage, dest_s,
dest_t, dest_r, doRescale)std::endl;
osg::notify(osg::NOTICE) input height too large.std::endl;
return false;
}
Thanks for any help you can provide,
Donny
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows users - VS2008 comments
We upgraded from VS2003 to VS2008 a few months ago and the only issue we ran into was in the conversion of existing projects from VS2003 to VS2008. It seems there are a few issues with optimization settings from converted projects. Some of our projects that were showing as having /O2 optimization, where actually being built with no optimization. We just decided to re-create the projects in VS2008 and have not had any issues since then. - Donny On Sat, Apr 4, 2009 at 11:30 AM, sherman wilcox wilcox.sher...@gmail.comwrote: Slightly off-topic for this mailing list but here goes. For the Windows users out there, those of you that are using or know of developers using VS2008 - any comments? Problems, benefits, pros/cons? My project is using VS2005 and has been for a while now but I'm considering switching to VS2008. In my case there's only one reason - the /MP benefit. /MP enables parallel compilation. For multiprocessor or multicore systems it's a real performance increase. I'm not talking about parallel builds of multiple projects but compiling multiple modules in the same project(s) in parallel. On VS2005 /MP is undocumented but works, mostly. It's a tremendous performance boost. However, I've ran into a PDB corruption issue here as of late. Error C2471. Not sure why it's suddenly happening as I've been using /MP for a long while now. I believe Gordon warned me this could happen and it has. I phoned Microsoft about this and they said that /MP is unsupported on VS2005 and I have no recourse but to either not use that feature (no way - too fast) or upgrade to VS2008. So, I may be upgrading. However, there are numerous developers on my project and I want to have a clear understanding of any potential issues before moving forward. I'll be purchasing a copy to test but I'd like to hear from the list. ___ 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] Object oriented coding
Hi Tomas, This is a software design question, not really an OpenSceneGraph one. I'd recommend reading articles/books on game/object oriented design. The design of your classes will depend on your application requirements, taking into account money/time/etc. constraints. I'd recommend that your design abstract out rendering such that your OSG code is in separate rendering components. We do this in our visualization applications to allow us to switch renderers. We do this using a component based object management design (see http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/) and it has worked out really well. Good luck, - Donny On Wed, Apr 1, 2009 at 5:32 AM, Tomas Lundberg tomas...@gmail.com wrote: Hi, I have done some small test projects for fun in OSG, without really learning it correctly. Now I have a very general question: How do I structure my code to make it more object oriented together with OSG? Let's say I want to visualise an airport with planes coming and leaving. I would like to write this program in an object oriented manner, where the airport has a number of planes, where each plane has a number of parts etc. A plane should of course have properties such speed and engine thrust. Same thing goes for parts of a plane. For instance a wing should have a number that represents the drag, and also a number for its weight. It should also have visual information (shape, position, material etc). How do I combine this visual information with non-visual information in an object oriented manner? I guess visual information should go into the scene graph where as the rest does not. Yet, I want all the information about the wing to go into the same C++ wing object. Is there any good example showing how to manage this? I would love to see simple code examples showing these principles as they are easier to understand. Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9529#9529 ___ 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] Object oriented coding
Tomas, Check out the osgcatch example. It's a simple example with a few classes to encapsulate game objects that may get you going in the right direction. - Donny On Wed, Apr 1, 2009 at 9:51 AM, Tomas Lundberg tomas...@gmail.com wrote: Thanks for the reply. That's an interesting article. It does make sense when thinking about it, although the object oriented stucture is deeply rooted in many programmers' heads (mine included) :) Anyway, I think my question applies to objects and components alike... How does adding data to the scene graph (and drawing it) fit in to objects and components? Staying with object thinking for a while, do people generally create an AddToSceneGraph() member function for sub objects that are to be rendered? With this approach I suppose there is no Draw() member function in sub objects, as this does not go along with drawing the entire scene graph once every frame. Am I right? I know I should probably read some good literature on this, but for now I just want to test the concept and get a not-in-depth general understanding. Is there any small example out there using an object oriented approach together with real OSG code? I know this must sound like a real newbie question, but when it comes to games and scene graphs I'm still a newbie :) By the way, is there a way for me to not publish name and email in this forum? I saw that it is included near the quoted text in the reply. I don't make good friends with spammers :? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9542#9542 ___ 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Building on Windows XP, Visual Studio 2008 sp1. All builds fine, but
getting same warnings as Sukender (haven't tried your latest updates
Robert...about to rebuild with latest revision).
Examples run good except getting crash in osgTexture2D with a map/set
iterator not incrementable error. This error goes away if I add
viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded ); to the
example...maybe thread safety issue with incrementing _currPos??
Stack Trace:
msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x017ab278, const
wchar_t * file=0x0178, unsigned int line=304) Line 24C++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator==(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 304 + 0x17 bytesC++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator!=(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 316 + 0xc bytesC++
osg55-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1746 + 0x33
bytesC++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1368C++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1252C++
osg55-osgd.dll!osg::Drawable::draw(osg::RenderInfo renderInfo={...})
Line 898 + 0x13 bytesC++
osg55-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 60 + 0x19
bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 419 +
0x19 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 469 +
0x35 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line
1253C++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8, bool
doCopyTexture=false) Line 848C++
osg55-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 1108 +
0x1b bytesC++
osg55-osgUtild.dll!osgUtil::SceneView::draw() Line 1540 + 0x37
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::draw() Line 451 + 0xf
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 693 + 0xf bytesC++
osg55-osgd.dll!osg::GraphicsContext::runOperations() Line 688 + 0x33
bytesC++
osg55-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 135C++
osg55-osgd.dll!osg::GraphicsOperation::operator()(osg::Object *
object=0x0277fb30) Line 50 + 0x19 bytesC++
osg55-osgd.dll!osg::OperationThread::run() Line 413 + 0x26 bytes
C++
osg55-osgd.dll!osg::GraphicsThread::run() Line 40C++
ot11-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void *
data=0x026f82ac) Line 116 + 0xf bytesC++
msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytesC
msvcr90d.dll!_threadstartex(void * ptd=0x026f9830) Line 331C
kernel32.dll!7c80b713()
- Donny
On Mon, Feb 2, 2009 at 9:01 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi All,
I've now finished all the merges/bug/features fixes that is required
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Robert,
That did indeed fix the issue.
Thanks,
Donny
On Tue, Feb 3, 2009 at 6:43 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Donald,
This looks to be a threading issue with the text label being updated
while being rendered.
There was no text-setDataVariance(DYNAMIC) so I've added this, and
checked this change into svn/trunk. Could you please test. Modified
osgtexture2D.cpp also attached.
Robert.
On Tue, Feb 3, 2009 at 12:35 PM, Donald Cipperly osgc...@gmail.com
wrote:
Building on Windows XP, Visual Studio 2008 sp1. All builds fine, but
getting same warnings as Sukender (haven't tried your latest updates
Robert...about to rebuild with latest revision).
Examples run good except getting crash in osgTexture2D with a map/set
iterator not incrementable error. This error goes away if I add
viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded ); to the
example...maybe thread safety issue with incrementing _currPos??
Stack Trace:
msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x017ab278,
const
wchar_t * file=0x0178, unsigned int line=304) Line 24C++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator==(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 304 + 0x17 bytesC++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator!=(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 316 + 0xc bytesC++
osg55-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1746 + 0x33
bytesC++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1368C++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1252C++
osg55-osgd.dll!osg::Drawable::draw(osg::RenderInfo
renderInfo={...})
Line 898 + 0x13 bytesC++
osg55-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 60 +
0x19
bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 419
+
0x19 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384
+
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 469
+
0x35 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line
1253C++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384
+
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8, bool
doCopyTexture=false) Line 848C++
osg55-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 1108
+
0x1b bytesC++
osg55-osgUtild.dll!osgUtil::SceneView::draw() Line 1540 + 0x37
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::draw() Line 451 + 0xf
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext
*
context=0x0277fb30) Line 693 + 0xf bytesC++
osg55-osgd.dll!osg::GraphicsContext::runOperations() Line 688 +
0x33
bytesC++
osg55-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 135C++
osg55-osgd.dll!osg::GraphicsOperation::operator
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Robert, Removing the generates another warning: warning C4197: 'volatile const unsigned int' : top-level volatile in cast is ignoredc:\OpenSceneGraphSVN\src\OpenThreads\common\Atomic.cpp133 OpenThreads However, changing line 133 to just return _value; generates no warnings on Visual Studio 2008 sp1. I also see these warnings: warning C4701: potentially uninitialized local variable 'qu' used c:\openscenegraphsvn\src\osg\matrixdecomposition.cpp281osg warning C4512: 'CopyPointsToVertexArrayVisitor' : assignment operator could not be generatedc:\OpenSceneGraphSVN\src\osgUtil\Simplifier.cpp 1654osgUtil - Donny On Tue, Feb 3, 2009 at 10:44 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Guys, Since I've had no feedback on the remaining WIndows warnings I've gone ahead and added pragma's to suppress the following warnings that seemed to be appropriate for supression given that fixes aren't possible/don't look easily resolvable, and the warnings don't point to a real problem in the code either. 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) warning C4702: unreachable code An svn update should fix these warnings. In case of osgIntrospection I've added the warning disable pragma's to the include/osgIntrospection/Export rather each header as doing so ended up many lines of coding for just a single warning disable, not good news when each code change comes with a potential from introducing typo's + associated build/runtime problems. This leaves one warning left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' For this I think the proper solution is to remove the . Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shapefile troubles
The file looked fine for me, but I've written my own Shapefile reader...so it's probably an issue in the shp plugin. Your shapefile has PolyLineZ shapes if that helps in debugging. - Donny On Tue, May 13, 2008 at 3:08 AM, Kimmo Kotajärvi [EMAIL PROTECTED] wrote: (I posted these earlier but it got moderated out… no file attachment this time) Could anybody have a look at these shapefiles? It should be a network of roads but I can't get the shp plugin to read it correctly. http://www.wikiupload.com/download_page.php?id=33045 ~300KB 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] osg 2.4 Wrapper Build Errors in VS 7.1
Visual Studio 7.1 doesn't seem to like osg::ref_ptr variables in the wrapper cpp files: osgViewer\View.cpp(118) : error C2947: expecting '' to terminate template-argument-list, found '' osgText\Text3D.cpp(96) : error C2947: expecting '' to terminate template-argument-list, found '' osgText\Text.cpp(102) : error C2947: expecting '' to terminate template-argument-list, found '' Anyone else seeing this? Thanks, - Donny ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg 2.4 Wrapper Build Errors in VS 7.1
Thanks, adding the space in the macro did indeed fix it. I'll go ahead and submit the fix. - Donny On Mon, Apr 28, 2008 at 3:31 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Donald, osgViewer\View.cpp(118) : error C2947: expecting '' to terminate template-argument-list, found '' osgText\Text3D.cpp(96) : error C2947: expecting '' to terminate template-argument-list, found '' osgText\Text.cpp(102) : error C2947: expecting '' to terminate template-argument-list, found '' Hehe VS 7.1 doesn't like , it thinks it's the operator. Just put a space between the two signs. Robert will probably fix this when he gets back. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.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] mouse location (x,y) in pixel units
How about: float fMouseX = ((ea.getX() + 1.0)*0.5) * (float)ea.getWindowWidth(); float fMouseY = ((ea.getY() + 1.0)*0.5) * (float)ea.getWindowHeight(); - Donny On Thu, Apr 24, 2008 at 8:56 AM, Andrew Lett [EMAIL PROTECTED] wrote: In OSG2.2 I'd like to find the 'real' x,y location of the mouse cursor. If my window is 640x480, then the value for x should be between 0 and 639, while y should be from 0 to 479. I need the x,y values in this form so that it can be injected into CEGUI correctly. The GUIEventAdapter has protected members _mx and _my, along with the access methods getX() and getY(). However, these methods both yield values between -1 and 1. While stepping through the code, the _mx and _my actually correctly hold the pixel based values I need until encountering the following section in Viewer.cpp: osg::Vec3d new_coord = osg::Vec3d(x,y,0.0) * matrix; x = new_coord.x(); y = new_coord.y(); ... event-setX(x); event-setY(y); Aside from making private changes on GUIEventAdapter, is there any other way to read the mouse x,y location in the format I need? All suggestions are very much appreciated. Sincerely, - Andrew ___ 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] Problems with osgText
Sounds like you forgot to link with osgText.lib - D On Jan 15, 2008 6:09 AM, Pedro José Muñoz Martínez [EMAIL PROTECTED] wrote: Hello all, I have a problem with adding text. Just instantiating : osgText::Text* texto = new osgText::Text(); I found linking errors such as: 1Curso1.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: __thiscall osgText::Text::Text(void) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function _main 1Curso1.obj : error LNK2001: unresolved external symbol public: virtual void __thiscall osgText::Text::setThreadSafeRefUnref(bool) ([EMAIL PROTECTED]@osgText@@[EMAIL PROTECTED]) And I don´t know what can it be because I include it #include osgText/Text and the error still continuous. Any idea? Thanks in advance. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Richard, I've seen this type of thing before in my scenes with cracks in the terrain. Adjusting of lines 242-243 in DepthPartitionNode.cpp seemed to fix this for me: znear *= 0.99; zfar *= 1.01; - D. On Dec 17, 2007 5:30 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Donald, Thanks... that's a pretty easy looking solution. However, I seem to be doing something unorthodox somewhere that is preventing this node from working as intended. I get a moving gap cut through the world that is more or less parallel to the camera plane, and that moves around as the camera moves (I am moving my camera manually). Have you seen this effect before (see below)? Richard On Dec 17, 2007, at 9:03 AM, Donald Cipperly wrote: Have a look at the osgdepthpartition example. I use depth partitioning to solve z-fighting issues in really large scenes. - D. On Dec 17, 2007 7:17 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode (osgUtil::CullVisitor:: DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Have a look at the osgdepthpartition example. I use depth partitioning to solve z-fighting issues in really large scenes. - D. On Dec 17, 2007 7:17 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode (osgUtil::CullVisitor:: DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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] Hiding the Mouse Pointer
From osgcatch, osgphotoalbum, and osgstereoimage examples:
// switch off the cursor
osgViewer::Viewer::Windows windows;
viewer.getWindows(windows);
for(osgViewer::Viewer::Windows::iterator itr = windows.begin();
itr != windows.end();
++itr)
{
(*itr)-useCursor(false);
}
On Nov 21, 2007 6:42 AM, Kim C Bale [EMAIL PROTECTED] wrote:
How do you hide the mouse cursor in the viewer window?
Cheers,
Kim.
*
To view the terms under which this email is distributed, please go to
http://www.hull.ac.uk/legal/email_disclaimer.html
*
___
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] ESRIShape error
I can load the file just fine using my Shapefile plugin btw. The points are in a local coordinate system. See attached pic. On Oct 30, 2007 1:05 PM, Karl Beal [EMAIL PROTECTED] wrote: I've attached the shapefile in question. I'm running on OpenSceneGraph-2.2.0 on Windows. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are NOT the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying this e-mail is strictly prohibited. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org attachment: shp1.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewerMFC Resize Issue
I found a small error in calculating the x mouse location after resizing the render window in the osgViewerMFC example. I've traced this back in the debugger to osgViewer::Viewer::eventTraversal(). Line 550 in this file has the correct value: float x = event-getX(); However, the calculations in lines 599-607 produce an incorrect value for x: osg::Viewport* viewport = getCameraWithFocus()-getViewport(); osg::Matrix localCameraVPW = getCameraWithFocus()-getViewMatrix() * getCameraWithFocus()-getProjectionMatrix(); if (viewport) localCameraVPW *= viewport-computeWindowMatrix(); osg::Matrix matrix( osg::Matrix::inverse(localCameraVPW) * masterCameraVPW ); osg::Vec3d new_coord = osg::Vec3d(x,y,0.0) * matrix; x = new_coord.x(); The viewport is correct, so it looks like the view matrix or projection matrix aren't being refreshed properly after a resize. The y value is always correct :/ Not sure where to look from here...any ideas? Thx ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
