[osg-users] 回复： Re: 回复： Re: blink q uestion!
Thanks a lot ,I already do these in a update callback. But blink continue
exist.
This is my code:
ResultCode ExpCntl::startPaint(HINSTANCE hinstance)
{
ResultCode rslt = SUCCESS;
DWORD paintThreadID;
HANDLE paintThreadHandle;
paintThreadHandle = CreateThread(NULL, 0, PaintThread, hinstance, NULL,
paintThreadID);
CloseHandle(paintThreadHandle);
//rslt = PaintThread(hinstance);
SleepEx(100, false);
return rslt;
}
DWORD WINAPI PaintThread(LPVOID lpData)
{
g_var.threadcount ++;
HINSTANCE hInstPaint = *static_castHINSTANCE*(lpData);
WNDCLASS wndClassPaint;
// register back ground window class
wndClassPaint.style = 0;
wndClassPaint.lpfnWndProc= PaintWinProc;
wndClassPaint.cbClsExtra = 0;
wndClassPaint.cbWndExtra = 0;
wndClassPaint.hInstance = hInstPaint;
wndClassPaint.hIcon = NULL; // no icon
wndClassPaint.hCursor= NULL; // no cursor
wndClassPaint.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH); // black
background
wndClassPaint.lpszMenuName = NULL;
wndClassPaint.lpszClassName = Ldpesbackground;
//
// CoInitialize(NULL);
// IMyButtonPtr temp;
// CoCreateInstance(__uuidof(MyButton), NULL, CLSCTX_ALL, __uuidof(IMyButton),
// (void**)temp);
// CoCreateInstance(__uuidof(ControlManager), NULL, CLSCTX_ALL,
// __uuidof(IControlManager), (void**)pControlManager);
if (!RegisterClass(wndClassPaint))
{ // fail to register the window class
//goto over;
g_var.threadcount --;
//GdiplusShutdown(gdiplusToken);
//CoUninitialize();
return 0;
}
// create back ground window
HWND hWndPaint;
hWndPaint = CreateWindow(
Ldpesbackground, // window class name
L,// window caption
0, // window style
0, // initial x position
0, // initial y position
CW_USEDEFAULT, // initial x size
CW_USEDEFAULT, // initial y size
NULL,// parent window handle
NULL,// window menu handle
hInstPaint, // program instance handle
NULL);// creation parameters
if (!hWndPaint)
{ // fail to create window
//goto over;
g_var.threadcount --;
//GdiplusShutdown(gdiplusToken);
CoUninitialize();
return 0;
}
// hide the caption of back ground window
DWORD dwStyle = GetWindowLong(hWndPaint, GWL_STYLE);
dwStyle = ~(WS_CAPTION);
SetWindowLong(hWndPaint, GWL_STYLE, dwStyle);
// show the back ground window
ShowWindow(hWndPaint, SW_MAXIMIZE);
UpdateWindow(hWndPaint);
//ShowCursor(false);
这段是加载hook动态库并安装钩子
typedef BOOL (*InstallHook)();
typedef BOOL (*UnHook)();
InstallHook ProcInstallHook = NULL;
UnHook ProcUnHook = NULL;
HINSTANCE hInstLib = NULL;
hInstLib = LoadLibraryA(hook.dll);
if (hInstLib == NULL)
{
MessageBoxA(NULL, 没有打开hook.dll, 提醒, MB_OK);
return 0;
}
ProcInstallHook = (InstallHook) GetProcAddress(hInstLib,InstallHook);
if (ProcInstallHook != NULL)
{
ProcInstallHook();
}
加载hook结束
/*GdiplusStartupInput gdiplusStartupInput;
ULONG_PTR gdiplusToken;
GdiplusStartup(gdiplusToken, gdiplusStartupInput, NULL);*/
osgViewer::Viewer viewer; //场景
// Local Variable to hold window size data
RECT rect;
// Get the current window size
::GetWindowRect(hWndPaint, rect);
//全局变量来保存viewer窗口的大小属性
{
_osgviewer_rect().bottom = rect.bottom ;
_osgviewer_rect().left = rect.left;
_osgviewer_rect().right = rect.right;
_osgviewer_rect().top= rect.top;
_osgviewer_rect().viewer_background_color = osg::Vec4(0,0,0,1);
_osgviewer_rect().clicked_editbox = NULL;
}
// Init the GraphicsContext Traits
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
// Init the Windata Variable that holds the handle for the Window to
display OSG in.
osg::ref_ptrosg::Referenced windata = new
osgViewer::GraphicsWindowWin32::WindowData(hWndPaint);
// Setup the traits parameters
traits-x = 0;
traits-y = 0;
traits-width = rect.right - rect.left;
traits-height = rect.bottom - rect.top;
traits-windowDecoration = false;
traits-doubleBuffer = true;
traits-sharedContext = 0;
traits-setInheritedWindowPixelFormat = true;
traits-inheritedWindowData = windata;
// Create the Graphics Context
osg::GraphicsContext* gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
// Assign Graphics Context to the Camera
viewer.getCamera()-setGraphicsContext(gc);
// Set the viewport for the Camera
viewer.getCamera()-setClearColor(_osgviewer_rect().viewer_background_color);
viewer.getCamera()-setViewport(new osg::Viewport(traits-x, traits-y,
traits-width, traits-height));
//osg::ref_ptrosg::Group root = new osg::Group;
osg::ref_ptrosg::Switch root = new osg::Switch;
//root-addChild(new osg::Node());
viewer.setSceneData(root.get());//设置场景根节点
关闭自动计算远近裁减面
Re: [osg-users] VPB bug or faulty data?
Hi Alejandro Im not 100% here, but I think you still need to specify some sort of projection basis, even plain lat lon uses some defenition of the geoid like WGS84 og similar. Natrally it could be a problem with you GTiff file. What version of VPB OSG are you using? Brgs. Ralf 2008/10/27 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hi, Actually the data has no projections, it is in plain longitude/latitude coordinates. Which is the recomended projection for data about 1 or two degrees long so I can have it in kilometers? Regards, -- A. On Sun, Oct 26, 2008 at 2:04 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro It seams you are missing projection information in the createt geotiff file. VPB needs some sort of projection system information in the input or you should specify the projection in the commandline for VPB It will be faster if you project your source data using ie gdalwarp, adal translate can also encode the projection data if its missing and you know what it should be. Brgs. Ralf Stokholm 2008/10/26 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hello: I got DEM data from INEGI (Mexican Geographic Institute) and convert it to Geo Tiff. gdal_translate -of GTiff -co TILED=YES MDE-n20s19e097o099.bil volcanes.tif gdaladdo -r average volcanes.tif 2 4 8 16 32 gdalinfo volcanes.tif Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength Driver: GTiff/GeoTIFF Files: volcanes.tif Size is 7200, 3600 Coordinate System is `' Origin = (-99.000,20.000) Pixel Size = (0.0002778,-0.0002778) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -99.000, 20.000) Lower Left ( -99.000, 19.000) Upper Right ( -97.000, 20.000) Lower Right ( -97.000, 19.000) Center ( -98.000, 19.500) Band 1 Block=256x256 Type=UInt16, ColorInterp=Gray NoData Value=0 Overviews: 3600x1800, 1800x900, 900x450, 450x225, 225x113 Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength If I try to create the terrain database this way I get only a line osgdem -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive so I have to give approximate pixel size with xx and yy and it apparently works. osgdem --xx 33 --yy 33 -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive Is there not enough information in the geotiff file? or this is a bug? Regards, -- A. ___ 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] VPB bug or faulty data?
Hi Alejandro, VPB is only understand well referenced WGS84 formatted data. So I advice you to use referenced images to create your terrain, if you are not familiar with reference data manipulation on images you should download prepared referenced data from http://seamless.usgs.gov/index.php or http://geoengine.nga.mil/geospatial/SW_TOOLS/NIMAMUSE/webinter/rast_roam.htmlYou can find lots of web site to download these kind of data. Best Regards. Umit Uzun 2008/10/27 Ralf Stokholm [EMAIL PROTECTED] Hi Alejandro Im not 100% here, but I think you still need to specify some sort of projection basis, even plain lat lon uses some defenition of the geoid like WGS84 og similar. Natrally it could be a problem with you GTiff file. What version of VPB OSG are you using? Brgs. Ralf 2008/10/27 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hi, Actually the data has no projections, it is in plain longitude/latitude coordinates. Which is the recomended projection for data about 1 or two degrees long so I can have it in kilometers? Regards, -- A. On Sun, Oct 26, 2008 at 2:04 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro It seams you are missing projection information in the createt geotiff file. VPB needs some sort of projection system information in the input or you should specify the projection in the commandline for VPB It will be faster if you project your source data using ie gdalwarp, adal translate can also encode the projection data if its missing and you know what it should be. Brgs. Ralf Stokholm 2008/10/26 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hello: I got DEM data from INEGI (Mexican Geographic Institute) and convert it to Geo Tiff. gdal_translate -of GTiff -co TILED=YES MDE-n20s19e097o099.bil volcanes.tif gdaladdo -r average volcanes.tif 2 4 8 16 32 gdalinfo volcanes.tif Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength Driver: GTiff/GeoTIFF Files: volcanes.tif Size is 7200, 3600 Coordinate System is `' Origin = (-99.000,20.000) Pixel Size = (0.0002778,-0.0002778) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -99.000, 20.000) Lower Left ( -99.000, 19.000) Upper Right ( -97.000, 20.000) Lower Right ( -97.000, 19.000) Center ( -98.000, 19.500) Band 1 Block=256x256 Type=UInt16, ColorInterp=Gray NoData Value=0 Overviews: 3600x1800, 1800x900, 900x450, 450x225, 225x113 Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength If I try to create the terrain database this way I get only a line osgdem -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive so I have to give approximate pixel size with xx and yy and it apparently works. osgdem --xx 33 --yy 33 -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive Is there not enough information in the geotiff file? or this is a bug? Regards, -- A. ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 回复： Re: 回复： Re: blink qu estion!
Hi, YangXiao What have you done to your widget handle (hWndPaint) in rootCallback? Please do not update the handle by yourself. Also plz don't send such long code here. It brings trouble to others ... Wang Rui 2008/10/27 YangXiao [EMAIL PROTECTED] Thanks a lot ,I already do these in a update callback. But blink continue exist. This is my code: ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB bug or faulty data?
Hi Umit, On Mon, Oct 27, 2008 at 7:36 AM, Ümit Uzun [EMAIL PROTECTED] wrote: VPB is only understand well referenced WGS84 formatted data. This is not correct, VPB can handle a wide range of projections, including no projections if your manually provide the projections. However, I would very strongly recommend that you provide data with proper projections for them, it makes the whole build process far far easier and reliable. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB bug or faulty data?
Hi Robert, Thanks for clarification. But I remember that, VPB can manipulate only WGS84 referenced data. But it may be valid for only BlueMarble viewer. Sorry for wrong comment :) Best Regards. Umit Uzun 2008/10/27 Robert Osfield [EMAIL PROTECTED] Hi Umit, On Mon, Oct 27, 2008 at 7:36 AM, Ümit Uzun [EMAIL PROTECTED] wrote: VPB is only understand well referenced WGS84 formatted data. This is not correct, VPB can handle a wide range of projections, including no projections if your manually provide the projections. However, I would very strongly recommend that you provide data with proper projections for them, it makes the whole build process far far easier and reliable. 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] VPB bug or faulty data?
Hi Umit, On Mon, Oct 27, 2008 at 9:25 AM, Ümit Uzun [EMAIL PROTECTED] wrote: Thanks for clarification. But I remember that, VPB can manipulate only WGS84 referenced data. But it may be valid for only BlueMarble viewer. Sorry for wrong comment :) When building geocentric databases VPB reprojects the data into WGS84 and then builds the data, if you are using vpbmaster then you'll need to do this reprojection as a prior step to calling vpbmaster. The vpbcache utility can do this reprojection for you. If you are just using osgdem standalone then it can do the reprojection for you. The key is that your source data should have at least a projection that GDAL recognizes otherwise you end up having to build your own projection. GDAL has tools to allow you to do this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
Hi Cedric, I'm excited about the prospect of an LGPL'd osgAnimation. I tried checking out the animtk repository with mercurial, but no luck: % hg clone http://hg.plopbyte.net/animtk requesting all changes adding changesets abort: could not import module directory! transaction abort! rollback completed Exit 255 Is this a client- server-, or permissions problem? Best regards, John Cedric Pinson wrote: Hi Robert, Ok i changed the code to fit the osg coding style. if you want to look at it http://hg.plopbyte.net/animtk/file/0acae4280750 or get the repo: hg clone http://hg.plopbyte.net/animtk Cheers, Cedric -- 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
[osg-users] I need to write an ive plugin.
Hi, I have written a new class which inherit from osg::Group. I have written a plugin for the .osg file format, that works fine. I need to write a plugin for the .ive file format. My initial thought was to copy-paste the ive::LOD code and replace the actual read/write parts according to my needs. I am compiling this code inside one of my own projects. I added includes to the ive/ReadWrite.h and ive/Group.h. The code compiles. Linking results in errors on unresolved externals. I could not find a library to link with, and I see that the header-files inside ive does not have export statements. So I think I have gone ahead doing this in a very wrong way. Does anybody have an example or directions for me on how to do this? I also wonder how the code written as an ive plugin gets called when reading/writing ive files. Do I need to register my class somewhere? Regards, Viggo _ Hold kontakten med Windows Live Messenger. http://clk.atdmt.com/GBL/go/msnnkdre001003gbl/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I need to write an ive plugin.
Hi Viggo, I'm afraid the .ive format is not extensible, the only way to add to it is to directly modify the sourceof the ive plugin. Long term I want to introduce a binary .osg format that is extensible, but I don't have the time available right now to tackle this. Robert. On Mon, Oct 27, 2008 at 10:17 AM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi, I have written a new class which inherit from osg::Group. I have written a plugin for the .osg file format, that works fine. I need to write a plugin for the .ive file format. My initial thought was to copy-paste the ive::LOD code and replace the actual read/write parts according to my needs. I am compiling this code inside one of my own projects. I added includes to the ive/ReadWrite.h and ive/Group.h. The code compiles. Linking results in errors on unresolved externals. I could not find a library to link with, and I see that the header-files inside ive does not have export statements. So I think I have gone ahead doing this in a very wrong way. Does anybody have an example or directions for me on how to do this? I also wonder how the code written as an ive plugin gets called when reading/writing ive files. Do I need to register my class somewhere? Regards, Viggo Se bildegalleri på MSN Style. Kate Moss eller Sienna Miller: Hvilken kjendis-stil passer deg? ___ 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] animtk release 0.0.9
Hi John, I guess it comes from the version of mercurial you are using. I tried because of your post, and it works. hg clone http://hg.plopbyte.net/animtk destination directory: animtk requesting all changes adding changesets adding manifests adding file changes added 323 changesets with 1620 changes to 465 files updating working directory 163 files updated, 0 files merged, 0 files removed, 0 files unresolved hg --version Mercurial Distributed SCM (version 1.0.2) Copyright (C) 2005-2008 Matt Mackall [EMAIL PROTECTED] and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Maye you are using an old mercurial version, check your version Cheers, Cedric John Vidar Larring wrote: Hi Cedric, I'm excited about the prospect of an LGPL'd osgAnimation. I tried checking out the animtk repository with mercurial, but no luck: % hg clone http://hg.plopbyte.net/animtk requesting all changes adding changesets abort: could not import module directory! transaction abort! rollback completed Exit 255 Is this a client- server-, or permissions problem? Best regards, John Cedric Pinson wrote: Hi Robert, Ok i changed the code to fit the osg coding style. if you want to look at it http://hg.plopbyte.net/animtk/file/0acae4280750 or get the repo: hg clone http://hg.plopbyte.net/animtk Cheers, Cedric -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
Hi Robert, I guess i can use the same branch of Jeremy to start the integration. Most of the time I interact with Jeremy so using the same branche is good for me. I will follow your suggestion for integration. Cheers, Cedric Robert Osfield wrote: Hi Cedric, On Fri, Oct 24, 2008 at 6:52 PM, Cedric Pinson [EMAIL PROTECTED] wrote: Ok i changed the code to fit the osg coding style. if you want to look at it http://hg.plopbyte.net/animtk/file/0acae4280750 This looks far closer to the usual OSG style, so thanks for making the change, it certainly makes things smoother to integrate. On the trail integration front I was think that perhaps you could maintain your own branch of the OSG this preps the code ready for a straight merge. Or slightly lighter weight solution would be to just reuse Jeremy Moles's osgWidget branch for you both to prep stuff prior to merge with svn/trunk. If you are up for this then we could get Jose to add your as a writer to the braches section of OSG wiki. In this merge I'd suggest renaming osgATK to osgAnimation. The OSGANIMATION_EXPORT symbol will also be need for all your classes that have implementations in the .cpp's, as per the rest of the OSG libs. The license will also need to be changed, otherwise I won't be able to merge it with svn/trunk as the osgAnimation library, and I'll just have to wait for another such library with a compatible license to developed. Prior to any merge what we need is the community to start pitching in, testing across platforms. What would be great if people could port apps based on osgCal to osgATK/osgAnimation to see how well the new libs hold up feature and implementation wise. This extra exposure might put more work your way initially but it will mean that it shapes up quicker and solves some of the real animation needs that existing users already have. Many thanks you for efforts, Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load animated model?
This problem was solved in the past. http://groups.google.com/group/osg-users/browse_thread/thread/b9725f6566bd92f3/700f0659ed89598e?lnk=gstq=animate+model#700f0659ed89598e Please search the group before posting. Hĩ ;) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping
Hi Melchior, On Fri, Oct 24, 2008 at 8:36 PM, Melchior FRANZ [EMAIL PROTECTED] wrote: * Robert Osfield -- Friday 24 October 2008: But it doesn't really say anything about the how the texture wrap modes map to this, if at all. I can't say that either, but the current situation is bad. Because 'texrep 1 1' is default anyway (according to spec and reference implementation) AC3D itself doesn't even write it to its files! AC3D users who want the default do now have to manually(!) insert oodles of 'texrep 1 1' with an editor, only because OSG does no longer respect the documented default. I have just checked in a change from Mathias Froehlich in that reverts the ac3d plugin back to honouring the default texture repeat. I have also asked John Cummings who instigated the texture clamping changes to engage on this thread, hopefully he'll be able to explain the source of his problem files and provide some examples so that others can see if there is a possible solution for detecting when texture clamping might be appropriate and detectable in reliable way. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
Thanks Cedric, Instead of using the pre-built binary (version 0.9.4), I downloaded and compiled mercurial from source (version 1.0.2), and clone (a.k.a. checkout) worked like a charm. Hope this is helpful for other first-time mercurial / animtk users;) Best regards, John Cedric Pinson wrote: Hi John, I guess it comes from the version of mercurial you are using. I tried because of your post, and it works. hg clone http://hg.plopbyte.net/animtk destination directory: animtk requesting all changes adding changesets adding manifests adding file changes added 323 changesets with 1620 changes to 465 files updating working directory 163 files updated, 0 files merged, 0 files removed, 0 files unresolved hg --version Mercurial Distributed SCM (version 1.0.2) Copyright (C) 2005-2008 Matt Mackall [EMAIL PROTECTED] and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Maye you are using an old mercurial version, check your version Cheers, Cedric John Vidar Larring wrote: Hi Cedric, I'm excited about the prospect of an LGPL'd osgAnimation. I tried checking out the animtk repository with mercurial, but no luck: % hg clone http://hg.plopbyte.net/animtk requesting all changes adding changesets abort: could not import module directory! transaction abort! rollback completed Exit 255 Is this a client- server-, or permissions problem? Best regards, John Cedric Pinson wrote: Hi Robert, Ok i changed the code to fit the osg coding style. if you want to look at it http://hg.plopbyte.net/animtk/file/0acae4280750 or get the repo: hg clone http://hg.plopbyte.net/animtk Cheers, Cedric -- Best regards, John WeatherOne -- 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
[osg-users] strange behavior on stereo rendering
Hello, I'm trying to get working stereo for a three sided CAVE. I use a stereo matrices callback which overrides the stereo matrix calculations in the osgUtil::SceneView class. But i only can see the output for the right buffer, the left buffer will never used. I printed out with glGetIntegrv(GL_DRAW_BUFFER, buffer) the current buffer value and i still get the GL_BACK_RIGHT, never GL_BACK_LEFT. The same behavior i get with osgViewer, without my Callback. I use the NVIDIA QuatroFX 4500. Do i set or use a wrong state value or will my state value overriden by OSG inside? With best regards Johann. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] gluScaleImage() returns out of memory
Hi, I'm receiving an out of memory error while trying to scale an image. File : Image.cpp Line : 839 (2.6.1) In Image::scaleImage(), gluScaleImage() returns 1285 : out of memory. Any ideas? Can ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] gluScaleImage() returns out of memory
Usually this means you don't have an active GL graphics context, which unfortunately gluScaleImage requires. -gw Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Mon, Oct 27, 2008 at 8:44 AM, Can T. Oguz [EMAIL PROTECTED] wrote: Hi, I'm receiving an out of memory error while trying to scale an image. File : Image.cpp Line : 839 (2.6.1) In Image::scaleImage(), gluScaleImage() returns 1285 : out of memory. Any ideas? Can ___ 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] gluScaleImage() returns out of memory
First guess 'Are you doing this in process with a valid graphics context' Might help if you provided some basic info such as How are you scaling the image (code) What version of osg What OS how big is the image What type of image is it Graphics card etc. have you tried debug the issue? , stepped into the code etc to see what might be amiss Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Can T. Oguz Sent: Monday, October 27, 2008 8:45 AM To: OpenSceneGraph Users Subject: [osg-users] gluScaleImage() returns out of memory Hi, I'm receiving an out of memory error while trying to scale an image. File : Image.cpp Line : 839 (2.6.1) In Image::scaleImage(), gluScaleImage() returns 1285 : out of memory. Any ideas? Can ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] gluScaleImage() returns out of memory
Hi,
Yes, I've read the previous posts and I have a valid context. I have even
made the calls after the first frame() is executed (to ensure the context)
Source image is 512x217
Dest image is 50x20
OS : Win XP
Image iss JPG, GL_RGB
Card : NVidia 8800 GT
OSG : 2.6.1
and the code is :
for (UINT i = 0; i 3; i++)
{
Image* image = readImageFile(string(path) + textureFiles[i] + .jpg);
m_textures[i] = new Texture2D(image);
m_thumbnails[i] = new Image(*image, CopyOp::DEEP_COPY_IMAGES);
m_thumbnails[i]-scaleImage(50, 20, 1);
}
I've also tried a non-copied fresh image and I've got the same error.
Thanks for reading,
Can
2008/10/27 Tomlinson, Gordon [EMAIL PROTECTED]
First guess 'Are you doing this in process with a valid graphics context'
Might help if you provided some basic info such as
How are you scaling the image (code)
What version of osg
What OS
how big is the image
What type of image is it
Graphics card
etc.
have you tried debug the issue? , stepped into the code etc to see what
might be amiss
*Gordon*
__
*Gordon Tomlinson*
*Product Manager 3D
**Email * : gtomlinson @ overwatch.textron.com
__
*(C): (+1) 571-265-2612
(W)**: (+1) 703-437-7651*
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
- *Master Tambo Tetsura*
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Can T. Oguz
*Sent:* Monday, October 27, 2008 8:45 AM
*To:* OpenSceneGraph Users
*Subject:* [osg-users] gluScaleImage() returns out of memory
Hi,
I'm receiving an out of memory error while trying to scale an image.
File : Image.cpp
Line : 839 (2.6.1)
In Image::scaleImage(), gluScaleImage() returns 1285 : out of memory.
Any ideas?
Can
___
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] gluScaleImage() returns out of memory
Hi Can,
You make no mention where about your call the scaleImage from, there
is chance that you think you are calling it from a thread with the
graphics context but don't. Without more info about your usage there
isn't anyone else can say. Please remember the OSG is multi-threaded,
and by default with put the graphics in its own thread per context so
then main thread won't have the context current.
Robert.
On Mon, Oct 27, 2008 at 1:06 PM, Can T. Oguz [EMAIL PROTECTED] wrote:
Hi,
Yes, I've read the previous posts and I have a valid context. I have even
made the calls after the first frame() is executed (to ensure the context)
Source image is 512x217
Dest image is 50x20
OS : Win XP
Image iss JPG, GL_RGB
Card : NVidia 8800 GT
OSG : 2.6.1
and the code is :
for (UINT i = 0; i 3; i++)
{
Image
* image = readImageFile(string(path) + textureFiles[i] + .jpg);
m_textures
[i] = new Texture2D(image);
m_thumbnails
[i] = new Image(*image, CopyOp::DEEP_COPY_IMAGES);
m_thumbnails
[i]-scaleImage(50, 20, 1);
}
I've also tried a non-copied fresh image and I've got the same error.
Thanks for reading,
Can
2008/10/27 Tomlinson, Gordon [EMAIL PROTECTED]
First guess 'Are you doing this in process with a valid graphics context'
Might help if you provided some basic info such as
How are you scaling the image (code)
What version of osg
What OS
how big is the image
What type of image is it
Graphics card
etc.
have you tried debug the issue? , stepped into the code etc to see what
might be amiss
Gordon
__
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
- Master Tambo Tetsura
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Can T. Oguz
Sent: Monday, October 27, 2008 8:45 AM
To: OpenSceneGraph Users
Subject: [osg-users] gluScaleImage() returns out of memory
Hi,
I'm receiving an out of memory error while trying to scale an image.
File : Image.cpp
Line : 839 (2.6.1)
In Image::scaleImage(), gluScaleImage() returns 1285 : out of memory.
Any ideas?
Can
___
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] gluScaleImage() returns out of memory
Hi,
I'm running OSG in single threaded mode and making the calls right after the
context setup code, but if you think that the scaling operation needs to be
done within the OSG's inner threads; then there's no chance that I could use
this function. If you suggest an alternative, I'll follow.
Regards,
Can
2008/10/27 Robert Osfield [EMAIL PROTECTED]
Hi Can,
You make no mention where about your call the scaleImage from, there
is chance that you think you are calling it from a thread with the
graphics context but don't. Without more info about your usage there
isn't anyone else can say. Please remember the OSG is multi-threaded,
and by default with put the graphics in its own thread per context so
then main thread won't have the context current.
Robert.
On Mon, Oct 27, 2008 at 1:06 PM, Can T. Oguz [EMAIL PROTECTED] wrote:
Hi,
Yes, I've read the previous posts and I have a valid context. I have even
made the calls after the first frame() is executed (to ensure the
context)
Source image is 512x217
Dest image is 50x20
OS : Win XP
Image iss JPG, GL_RGB
Card : NVidia 8800 GT
OSG : 2.6.1
and the code is :
for (UINT i = 0; i 3; i++)
{
Image
* image = readImageFile(string(path) + textureFiles[i] + .jpg);
m_textures
[i] = new Texture2D(image);
m_thumbnails
[i] = new Image(*image, CopyOp::DEEP_COPY_IMAGES);
m_thumbnails
[i]-scaleImage(50, 20, 1);
}
I've also tried a non-copied fresh image and I've got the same error.
Thanks for reading,
Can
2008/10/27 Tomlinson, Gordon [EMAIL PROTECTED]
First guess 'Are you doing this in process with a valid graphics
context'
Might help if you provided some basic info such as
How are you scaling the image (code)
What version of osg
What OS
how big is the image
What type of image is it
Graphics card
etc.
have you tried debug the issue? , stepped into the code etc to see what
might be amiss
Gordon
__
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
- Master Tambo Tetsura
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Can T.
Oguz
Sent: Monday, October 27, 2008 8:45 AM
To: OpenSceneGraph Users
Subject: [osg-users] gluScaleImage() returns out of memory
Hi,
I'm receiving an out of memory error while trying to scale an image.
File : Image.cpp
Line : 839 (2.6.1)
In Image::scaleImage(), gluScaleImage() returns 1285 : out of memory.
Any ideas?
Can
___
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] Problem with computeIntersections for nodes below post render camera
Hi Robert,
For my usage of computeIntersections, as I said, I put the test scene into
the osgpick example. From there it is quite clear that the picking results
do not return what I believe most people will expect for that scene.
I was aware that the computeIntersections method is a wrapper for the
IntersectionVisitor class, but this class shows the same symptoms when used
directly. My intention was to give the most condensed example of the problem
in the hope the people would clearly understand the scenario that I think is
misbehaving. Ho hum. ;-)
So, I decided to put my miners helmet on and deleve into the subterranean
depths of the osg machine. I think I have discovered that something is
missing from 'IntersectionVisitor::accept(Camera)' because is makes the
assumption that all cameras have an absolute coordinate frame. This is an
assumption that neither PickVisitor::appy(Camera) or
CullVisitor::apply(Camera) makes. So I have merged the relevant code from
CullVistor into IntersectionVisitor and this now seems to function
correctly.
Please can you check the attached file with changes appied to
IntersectionVisitor.cpp (from osg 2.6).
[Also posted to submissions list]
Chris.
Date: Sun, 26 Oct 2008 15:53:19 +
From: Robert Osfield [EMAIL PROTECTED]
Subject: Re: [osg-users] Problem with computeIntersections for nodes
below post render camera.
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1
Hi Chris,
There isn't enough info about how you are calling computeIntersections
to really know what is going on - there are several
computeIntersections methods, so I can't say whether it's a bug, or
code misuse.
As a general note, the computeIntersections methods are just
convenience methods for the most common needs, but they are just
implemented on top the general purpose
IntersectionVisitor/*Intersector classes. These classes aren't
difficult to use so you just implement your work on these.
Robert.
On Sun, Oct 26, 2008 at 10:28 AM, Chris Denham [EMAIL PROTECTED]
wrote:
I have a problem with Viewer:computeIntersections for nodes below a
subgraph
rendering camera that doesn't have the ABSOLUTE_RF reference frame. In
fact,
computeIntersections results are exactly as though an ABSOLUTE_RF has
been
set on the camera, even though it has not. The code below creates a
simple
scene the exhibits the problem. I used this in the osgpick example to
show
computed intersections.
Is this a bug, or is this to be expected? If it is to be expected, how
can I
get picking to work for nodes below my post render camera?
Chris.
osg::Group* group = new osg::Group();
osg::Geode* sphere = new osg::Geode();
sphere-setName(Sphere);
sphere-addDrawable(new osg::ShapeDrawable(new osg::Sphere()));
osg::Geode* cube = new osg::Geode();
cube-setName(Cube);
cube-addDrawable(new osg::ShapeDrawable(new osg::Box()));
osg::Camera* camera = new osg::Camera();
camera-setRenderOrder(osg::Camera::POST_RENDER);
camera-setClearMask(GL_DEPTH_BUFFER_BIT);
//camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
group-addChild(sphere);
group-addChild(camera);
camera-addChild(cube);
___
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osgUtil/IntersectionVisitor
#include osg/PagedLOD
#include osg/Transform
#include osg/Projection
#include osg/Camera
#include osg/Geode
#include osg/Billboard
#include osg/Geometry
#include osg/Notify
#include osg/io_utils
using namespace osgUtil;
///
//
// IntersectorGroup
//
IntersectorGroup::IntersectorGroup()
{
}
void IntersectorGroup::addIntersector(Intersector* intersector)
{
_intersectors.push_back(intersector);
}
void IntersectorGroup::clear()
{
_intersectors.clear();
}
Intersector* IntersectorGroup::clone(osgUtil::IntersectionVisitor iv)
{
IntersectorGroup* ig = new IntersectorGroup;
// now copy across all intersectors that arn't disabled.
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if (!(*itr)-disabled())
{
ig-addIntersector( (*itr)-clone(iv) );
}
}
return ig;
}
bool IntersectorGroup::enter(const osg::Node
[osg-users] setViewMatrixAsLook at and getViewMatrixAsLookAt
Hi, I am using these two methods: setViewMatrixAsLookAt(eye, center, up) and getViewMatrixAsLookAt(eye, center, up) with the viewer's camera in this order and WITHOUT manipulating the camera elsewhere in my code. I don't have much experience with OSG but isn't the last method supposed to return in the eye, center and up objects the same parameters that I have used to set the view matrix before? I've made a simple test: viewer.getCamera()-setViewMatrixAsLookAt(osg::Vec3f(10., -10., 2.), osg::Vec3f(0., 0., 0.), osg::Z_AXIS); osg::Vec3f eye; osg::Vec3f center; osg::Vec3f up; viewer.getCamera()-getViewMatrixAsLookAt(eye, center, up); cout eye eye.x() eye.y() eye.z() endl; cout center center.x() center.y() center.z() endl; cout up up.x() up.y() up.z() endl; And what I've got from the cout's was: eye: 10 -10 2 (OK) center: 9.29986 -9.29986 1.85997 up: -0.0990148 0.0990148 0.990148 What am I doing wrong here? Did I misunderstand the purpose of the method? Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] gluScaleImage() returns out of memory
Hi Can,
The osgViewer::Viewer by default now releases the context after
frame() even in single threaded - this is required to handle users
calling multiple viewers from one frame loop. In
include/osgViewer/ViewerBase you'll find the method:
/** Hint to tell the renderingTraversals() method whether to
call relaseContext() on the last
* context that was made current by the thread calling
renderingTraverals(). Note, when
* running multi-threaded viewer no threads will be made
current or release current.
* Setting this hint to false can enable the frame loop to be
lazy about calling makeCurrent
* and releaseContext on each new frame, helping performance.
However, if you frame loop
* is managing multiple graphics context all from the main
frame thread then this hint must
* be left on, otherwise the wrong context could be left
active, introducing errors in rendering.*/
void setReleaseContextAtEndOfFrameHint(bool hint) {
_releaseContextAtEndOfFrameHint = hint; }
So you can call :
viewer.setReleaseContextAtEndOfFrameHint(false);
And you'll be able to call OpenGL op's after frame(), but... your code
will be working on a wing and prayer - as later you might want to go
multi-threaded, or use multiple graphics context in which case the
main thread once more won't have the graphics context current.
The way to fix this robustly is do add the ops via a Camera Pre or
PostDrawCallback as no matter what the threading model it'll work.
Robert.
On Mon, Oct 27, 2008 at 1:29 PM, Can T. Oguz [EMAIL PROTECTED] wrote:
Hi,
I'm running OSG in single threaded mode and making the calls right after the
context setup code, but if you think that the scaling operation needs to be
done within the OSG's inner threads; then there's no chance that I could use
this function. If you suggest an alternative, I'll follow.
Regards,
Can
2008/10/27 Robert Osfield [EMAIL PROTECTED]
Hi Can,
You make no mention where about your call the scaleImage from, there
is chance that you think you are calling it from a thread with the
graphics context but don't. Without more info about your usage there
isn't anyone else can say. Please remember the OSG is multi-threaded,
and by default with put the graphics in its own thread per context so
then main thread won't have the context current.
Robert.
On Mon, Oct 27, 2008 at 1:06 PM, Can T. Oguz [EMAIL PROTECTED] wrote:
Hi,
Yes, I've read the previous posts and I have a valid context. I have
even
made the calls after the first frame() is executed (to ensure the
context)
Source image is 512x217
Dest image is 50x20
OS : Win XP
Image iss JPG, GL_RGB
Card : NVidia 8800 GT
OSG : 2.6.1
and the code is :
for (UINT i = 0; i 3; i++)
{
Image
* image = readImageFile(string(path) + textureFiles[i] + .jpg);
m_textures
[i] = new Texture2D(image);
m_thumbnails
[i] = new Image(*image, CopyOp::DEEP_COPY_IMAGES);
m_thumbnails
[i]-scaleImage(50, 20, 1);
}
I've also tried a non-copied fresh image and I've got the same error.
Thanks for reading,
Can
2008/10/27 Tomlinson, Gordon [EMAIL PROTECTED]
First guess 'Are you doing this in process with a valid graphics
context'
Might help if you provided some basic info such as
How are you scaling the image (code)
What version of osg
What OS
how big is the image
What type of image is it
Graphics card
etc.
have you tried debug the issue? , stepped into the code etc to see
what
might be amiss
Gordon
__
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
- Master Tambo Tetsura
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Can T.
Oguz
Sent: Monday, October 27, 2008 8:45 AM
To: OpenSceneGraph Users
Subject: [osg-users] gluScaleImage() returns out of memory
Hi,
I'm receiving an out of memory error while trying to scale an image.
File : Image.cpp
Line : 839 (2.6.1)
In Image::scaleImage(), gluScaleImage() returns 1285 : out of memory.
Any ideas?
Can
___
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
Re: [osg-users] setViewMatrixAsLook at and getViewMatrixAsLookAt
The center isn't stored in the matrix, of course. Once the matrix is constructed, the center could be any random point along the view direction vector. You'll need to specify an eye distance, or scale the value yourself. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Renan Mendes Sent: Monday, October 27, 2008 7:46 AM To: OSG Mailing List Subject: [osg-users] setViewMatrixAsLook at and getViewMatrixAsLookAt Hi, I am using these two methods: setViewMatrixAsLookAt(eye, center, up) and getViewMatrixAsLookAt(eye, center, up) with the viewer's camera in this order and WITHOUT manipulating the camera elsewhere in my code. I don't have much experience with OSG but isn't the last method supposed to return in the eye, center and up objects the same parameters that I have used to set the view matrix before? I've made a simple test: viewer.getCamera()-setViewMatrixAsLookAt(osg::Vec3f(10., -10., 2.), osg::Vec3f(0., 0., 0.), osg::Z_AXIS); osg::Vec3f eye; osg::Vec3f center; osg::Vec3f up; viewer.getCamera()-getViewMatrixAsLookAt(eye, center, up); cout eye eye.x() eye.y() eye.z() endl; cout center center.x() center.y() center.z() endl; cout up up.x() up.y() up.z() endl; And what I've got from the cout's was: eye: 10 -10 2 (OK) center: 9.29986 -9.29986 1.85997 up: -0.0990148 0.0990148 0.990148 What am I doing wrong here? Did I misunderstand the purpose of the method? Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setViewMatrixAsLook at and getViewMatrixAsLookAt
Hi Renan, The answer to your problem can be found in the implementation of the getViewMatrixAsLookAt(), note the last optional parameter. /** Get to the position and orientation of a modelview matrix, using the same convention as gluLookAt. */ void getViewMatrixAsLookAt(osg::Vec3d eye,osg::Vec3d center,osg::Vec3d up,double lookDistance=1.0); Basically what the problem boils down to is that a view matrix doesn't have enough information to recover all the look at parameters that your input. It can recover the eye and up vectors accurately, but not the center as the conversion to a matrix looses everything by the direction vector between the eye and center. This is where lookDistance comes in, if you provide the original lookDistance then the method can compute the eye, up, and look direction, then using the lookDistance compute the center. Robert. On Mon, Oct 27, 2008 at 1:46 PM, Renan Mendes [EMAIL PROTECTED] wrote: Hi, I am using these two methods: setViewMatrixAsLookAt(eye, center, up) and getViewMatrixAsLookAt(eye, center, up) with the viewer's camera in this order and WITHOUT manipulating the camera elsewhere in my code. I don't have much experience with OSG but isn't the last method supposed to return in the eye, center and up objects the same parameters that I have used to set the view matrix before? I've made a simple test: viewer.getCamera()-setViewMatrixAsLookAt(osg::Vec3f(10., -10., 2.), osg::Vec3f(0., 0., 0.), osg::Z_AXIS); osg::Vec3f eye; osg::Vec3f center; osg::Vec3f up; viewer.getCamera()-getViewMatrixAsLookAt(eye, center, up); cout eye eye.x() eye.y() eye.z() endl; cout center center.x() center.y() center.z() endl; cout up up.x() up.y() up.z() endl; And what I've got from the cout's was: eye: 10 -10 2 (OK) center: 9.29986 -9.29986 1.85997 up: -0.0990148 0.0990148 0.990148 What am I doing wrong here? Did I misunderstand the purpose of the method? Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB bug or faulty data?
Hi Ralph, I am using the last versions from svn. Perhaps this warning from gdalinfo gives a hint on what is wrong with this data? gdalinfo volcanes.tif Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength because otherwise it recognizes that there is no projection but has all georeferencing information needed. Coordinate System is `' Origin = (-99.000,20.000) Pixel Size = (0.0002778,-0.0002778) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -99.000, 20.000) Lower Left ( -99.000, 19.000) Upper Right ( -97.000, 20.000) Lower Right ( -97.000, 19.000) Center ( -98.000, 19.500) I built it with gdal_translate directly from the BIL file gdal_translate -of GTiff -co TILED=YES MDE-n20s19e097o099.bil volcanes.tif The header of the BIL file says: NROWS 3600 NCOLS 7200 NBANDS 1 NBITS 16 BYTEORDER I LAYOUT BIL SKIPBYTES 0 NODATA 0.00 BYTEORDER I XDIM 0.000278 YDIM 0.000278 ULXMAP -98.999862 ULYMAP 19.9998612 Apparently it misses vertical information, but that is not the problem right now. Regards, -- A. On Mon, Oct 27, 2008 at 1:06 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro Im not 100% here, but I think you still need to specify some sort of projection basis, even plain lat lon uses some defenition of the geoid like WGS84 og similar. Natrally it could be a problem with you GTiff file. What version of VPB OSG are you using? Brgs. Ralf 2008/10/27 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hi, Actually the data has no projections, it is in plain longitude/latitude coordinates. Which is the recomended projection for data about 1 or two degrees long so I can have it in kilometers? Regards, -- A. On Sun, Oct 26, 2008 at 2:04 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro It seams you are missing projection information in the createt geotiff file. VPB needs some sort of projection system information in the input or you should specify the projection in the commandline for VPB It will be faster if you project your source data using ie gdalwarp, adal translate can also encode the projection data if its missing and you know what it should be. Brgs. Ralf Stokholm 2008/10/26 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hello: I got DEM data from INEGI (Mexican Geographic Institute) and convert it to Geo Tiff. gdal_translate -of GTiff -co TILED=YES MDE-n20s19e097o099.bil volcanes.tif gdaladdo -r average volcanes.tif 2 4 8 16 32 gdalinfo volcanes.tif Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength Driver: GTiff/GeoTIFF Files: volcanes.tif Size is 7200, 3600 Coordinate System is `' Origin = (-99.000,20.000) Pixel Size = (0.0002778,-0.0002778) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -99.000, 20.000) Lower Left ( -99.000, 19.000) Upper Right ( -97.000, 20.000) Lower Right ( -97.000, 19.000) Center ( -98.000, 19.500) Band 1 Block=256x256 Type=UInt16, ColorInterp=Gray NoData Value=0 Overviews: 3600x1800, 1800x900, 900x450, 450x225, 225x113 Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength If I try to create the terrain database this way I get only a line osgdem -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive so I have to give approximate pixel size with xx and yy and it apparently works. osgdem --xx 33 --yy 33 -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive Is there not enough information in the geotiff file? or this is a bug? Regards, -- A. ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping
Hi John, On Mon, Oct 27, 2008 at 4:07 PM, John Cummings [EMAIL PROTECTED] wrote: In the process of finding a small example, I've realized that indeed the reference document is not clear at for this feature. The reference documents say nothing about texture wrap modes at all. Given that this is important feature of texturing the format feels really outdated and insufficient for the job in hand. I am attaching a sample model. Thanks, data illustrating problems are virtual gold dust :-) It is simple a slice of earth with tiled images. I have also attached some screenshots- one with the old behavior in the latest release of OSG, one with the current SVN version, and one with a screeshot of AC3D (sorry about the angle on that one). You will notice that a thin slice of the desert in Africa show up in the Atlantic and vice versa. Clearly not correct. However, AC3D renders it that way- leading me to think our old custom implementation simply papered over the issue. I suspect small OpenGL drivers changing over the last 10 years has lead slightly different intrepretions of texcoords on fragments, such that the 0.99 that appear in your ac file are resulting in fragments being computed with values 1.0 despite the tex coords on the vertices never getting greater than 1.0 or less than 0.0. It used to be the case that values like these would be find with a wrap value of CLAMP, or probably even REPEAT. These days though you have to use CLAMP_TO_EDGE to get the intended behaviour. My guess AC3D was developed quite a while ago, making assumptions about CLAMP/REPEAT working fine with the near to edge tex coordinates that you've used, but with modern drivers things are now broken because the cards are computing the tex coords on fragment slightly differently. Other parts of the OSG have migrated from use CLAMP to CLAMP_TO_EDGE over the years just because of this issue. Things use to work fine with CLAMP, then drivers started popping up that broke this, and required CLAMP_TO_EDGE. I vaguely recall that it might of been ATI drivers that were the first to have problems w.r.t this. I see it now on this dataset on my Nvidia card so it's probably an industry wide migration. I am going to start a discussion on the AC3D forum as well since I think perhaps there is a feature in AC3D that I have not discovered as yet that would allow this behavior. Any other AC3D'ers on this list have some insight? I can't provide any insight as I'm no AC3D user. On the OSG side I think the only thing we could do is parse the tex coord arrays on geometries and if they fit into the 0 to 1.0 range to use CLAMP_TO_EDGE, otherwise use REPEAT. Perhaps an new osgUtil::Optimizer visitor would be appropriate for handling this type of issue. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB bug or faulty data?
Hi Alejandro, There is no coordinate systeml information for VPB to go on, and empty string for the coordinate system is not sufficient for determining the coordinate system, the origin and pixel size info aren't sufficient on their own. Robert. On Mon, Oct 27, 2008 at 4:32 PM, Alejandro Aguilar Sierra [EMAIL PROTECTED] wrote: Hi Ralph, I am using the last versions from svn. Perhaps this warning from gdalinfo gives a hint on what is wrong with this data? gdalinfo volcanes.tif Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength because otherwise it recognizes that there is no projection but has all georeferencing information needed. Coordinate System is `' Origin = (-99.000,20.000) Pixel Size = (0.0002778,-0.0002778) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -99.000, 20.000) Lower Left ( -99.000, 19.000) Upper Right ( -97.000, 20.000) Lower Right ( -97.000, 19.000) Center ( -98.000, 19.500) I built it with gdal_translate directly from the BIL file gdal_translate -of GTiff -co TILED=YES MDE-n20s19e097o099.bil volcanes.tif The header of the BIL file says: NROWS 3600 NCOLS 7200 NBANDS 1 NBITS 16 BYTEORDER I LAYOUT BIL SKIPBYTES 0 NODATA 0.00 BYTEORDER I XDIM 0.000278 YDIM 0.000278 ULXMAP -98.999862 ULYMAP 19.9998612 Apparently it misses vertical information, but that is not the problem right now. Regards, -- A. On Mon, Oct 27, 2008 at 1:06 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro Im not 100% here, but I think you still need to specify some sort of projection basis, even plain lat lon uses some defenition of the geoid like WGS84 og similar. Natrally it could be a problem with you GTiff file. What version of VPB OSG are you using? Brgs. Ralf 2008/10/27 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hi, Actually the data has no projections, it is in plain longitude/latitude coordinates. Which is the recomended projection for data about 1 or two degrees long so I can have it in kilometers? Regards, -- A. On Sun, Oct 26, 2008 at 2:04 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro It seams you are missing projection information in the createt geotiff file. VPB needs some sort of projection system information in the input or you should specify the projection in the commandline for VPB It will be faster if you project your source data using ie gdalwarp, adal translate can also encode the projection data if its missing and you know what it should be. Brgs. Ralf Stokholm 2008/10/26 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hello: I got DEM data from INEGI (Mexican Geographic Institute) and convert it to Geo Tiff. gdal_translate -of GTiff -co TILED=YES MDE-n20s19e097o099.bil volcanes.tif gdaladdo -r average volcanes.tif 2 4 8 16 32 gdalinfo volcanes.tif Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength Driver: GTiff/GeoTIFF Files: volcanes.tif Size is 7200, 3600 Coordinate System is `' Origin = (-99.000,20.000) Pixel Size = (0.0002778,-0.0002778) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -99.000, 20.000) Lower Left ( -99.000, 19.000) Upper Right ( -97.000, 20.000) Lower Right ( -97.000, 19.000) Center ( -98.000, 19.500) Band 1 Block=256x256 Type=UInt16, ColorInterp=Gray NoData Value=0 Overviews: 3600x1800, 1800x900, 900x450, 450x225, 225x113 Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength If I try to create the terrain database this way I get only a line osgdem -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive so I have to give approximate pixel size with xx and yy and it apparently works. osgdem --xx 33 --yy 33 -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive Is there not enough information in the geotiff file? or this is a bug? Regards, -- A. ___ 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
Re: [osg-users] VPB bug or faulty data?
Hi Robert and Umit, As probably you already read it, my data is georeferenced but has no projection info (plain latitude, l,ongitude). Using plain osgdem produces a wrong 1 dimension field (a line). osgdem -d volcanes.tif -l 8 -v 1.0 -o kk I have to give some approximated --xx and --yy data to make it work and even so it does wrongly, creating the mirror image in the Y direction, as you can see comparing the texture image with the produced terrain. Any hint? Where can I find documentation about vpbmaster, vpbcache and vpbsize? Regards, -- A. On Mon, Oct 27, 2008 at 3:40 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Umit, On Mon, Oct 27, 2008 at 9:25 AM, Ümit Uzun [EMAIL PROTECTED] wrote: Thanks for clarification. But I remember that, VPB can manipulate only WGS84 referenced data. But it may be valid for only BlueMarble viewer. Sorry for wrong comment :) When building geocentric databases VPB reprojects the data into WGS84 and then builds the data, if you are using vpbmaster then you'll need to do this reprojection as a prior step to calling vpbmaster. The vpbcache utility can do this reprojection for you. If you are just using osgdem standalone then it can do the reprojection for you. The key is that your source data should have at least a projection that GDAL recognizes otherwise you end up having to build your own projection. GDAL has tools to allow you to do this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org attachment: texture.jpgattachment: terrain.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB bug or faulty data?
Hi Robert: Yes but they are perfectly georeferenced. What shoud I do? --geocentric is enough? -- A. On Mon, Oct 27, 2008 at 10:38 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Alejandro, There is no coordinate systeml information for VPB to go on, and empty string for the coordinate system is not sufficient for determining the coordinate system, the origin and pixel size info aren't sufficient on their own. Robert. On Mon, Oct 27, 2008 at 4:32 PM, Alejandro Aguilar Sierra [EMAIL PROTECTED] wrote: Hi Ralph, I am using the last versions from svn. Perhaps this warning from gdalinfo gives a hint on what is wrong with this data? gdalinfo volcanes.tif Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength because otherwise it recognizes that there is no projection but has all georeferencing information needed. Coordinate System is `' Origin = (-99.000,20.000) Pixel Size = (0.0002778,-0.0002778) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -99.000, 20.000) Lower Left ( -99.000, 19.000) Upper Right ( -97.000, 20.000) Lower Right ( -97.000, 19.000) Center ( -98.000, 19.500) I built it with gdal_translate directly from the BIL file gdal_translate -of GTiff -co TILED=YES MDE-n20s19e097o099.bil volcanes.tif The header of the BIL file says: NROWS 3600 NCOLS 7200 NBANDS 1 NBITS 16 BYTEORDER I LAYOUT BIL SKIPBYTES 0 NODATA 0.00 BYTEORDER I XDIM 0.000278 YDIM 0.000278 ULXMAP -98.999862 ULYMAP 19.9998612 Apparently it misses vertical information, but that is not the problem right now. Regards, -- A. On Mon, Oct 27, 2008 at 1:06 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro Im not 100% here, but I think you still need to specify some sort of projection basis, even plain lat lon uses some defenition of the geoid like WGS84 og similar. Natrally it could be a problem with you GTiff file. What version of VPB OSG are you using? Brgs. Ralf 2008/10/27 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hi, Actually the data has no projections, it is in plain longitude/latitude coordinates. Which is the recomended projection for data about 1 or two degrees long so I can have it in kilometers? Regards, -- A. On Sun, Oct 26, 2008 at 2:04 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro It seams you are missing projection information in the createt geotiff file. VPB needs some sort of projection system information in the input or you should specify the projection in the commandline for VPB It will be faster if you project your source data using ie gdalwarp, adal translate can also encode the projection data if its missing and you know what it should be. Brgs. Ralf Stokholm 2008/10/26 Alejandro Aguilar Sierra [EMAIL PROTECTED] Hello: I got DEM data from INEGI (Mexican Geographic Institute) and convert it to Geo Tiff. gdal_translate -of GTiff -co TILED=YES MDE-n20s19e097o099.bil volcanes.tif gdaladdo -r average volcanes.tif 2 4 8 16 32 gdalinfo volcanes.tif Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength Driver: GTiff/GeoTIFF Files: volcanes.tif Size is 7200, 3600 Coordinate System is `' Origin = (-99.000,20.000) Pixel Size = (0.0002778,-0.0002778) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -99.000, 20.000) Lower Left ( -99.000, 19.000) Upper Right ( -97.000, 20.000) Lower Right ( -97.000, 19.000) Center ( -98.000, 19.500) Band 1 Block=256x256 Type=UInt16, ColorInterp=Gray NoData Value=0 Overviews: 3600x1800, 1800x900, 900x450, 450x225, 225x113 Warning 1: TIFFReadDirectory:volcanes.tif: Wrong StripByteCounts field, ignoring and calculating from imagelength If I try to create the terrain database this way I get only a line osgdem -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive so I have to give approximate pixel size with xx and yy and it apparently works. osgdem --xx 33 --yy 33 -d volcanes.tif -l 8 -v 1.0 -o volcanes.ive Is there not enough information in the geotiff file? or this is a bug? Regards, -- A. ___ 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
Re: [osg-users] VPB bug or faulty data?
Hi Alejandro, Your data *is* the problem, please add the coordinate system info. Using the --xx etc options really is not a good solution going forward. Use properly set up data and things will work fine. Please go check out the gdal website for info on how to set up your data. As for VPB docs, I haven't had a chance to write full docs for all the utilities yet. There are some notes online. Robert. On Mon, Oct 27, 2008 at 4:43 PM, Alejandro Aguilar Sierra [EMAIL PROTECTED] wrote: Hi Robert and Umit, As probably you already read it, my data is georeferenced but has no projection info (plain latitude, l,ongitude). Using plain osgdem produces a wrong 1 dimension field (a line). osgdem -d volcanes.tif -l 8 -v 1.0 -o kk I have to give some approximated --xx and --yy data to make it work and even so it does wrongly, creating the mirror image in the Y direction, as you can see comparing the texture image with the produced terrain. Any hint? Where can I find documentation about vpbmaster, vpbcache and vpbsize? Regards, -- A. On Mon, Oct 27, 2008 at 3:40 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Umit, On Mon, Oct 27, 2008 at 9:25 AM, Ümit Uzun [EMAIL PROTECTED] wrote: Thanks for clarification. But I remember that, VPB can manipulate only WGS84 referenced data. But it may be valid for only BlueMarble viewer. Sorry for wrong comment :) When building geocentric databases VPB reprojects the data into WGS84 and then builds the data, if you are using vpbmaster then you'll need to do this reprojection as a prior step to calling vpbmaster. The vpbcache utility can do this reprojection for you. If you are just using osgdem standalone then it can do the reprojection for you. The key is that your source data should have at least a projection that GDAL recognizes otherwise you end up having to build your own projection. GDAL has tools to allow you to do this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setViewMatrixAsLook at and getViewMatrixAsLookAt
Thanks, Paul and Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] What can I do with the NodeKit osgSim?
Hello all, I've a simply question about the NodeKit osgSim. Can everybody explain me when it's commendable to use. What is the benefit? I used never before. Cheers, Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.4 dev release
Hi All, I'm just prepping for the OpenSceneGraph-2.7.4 dev release, so am once again looking for help in testing! There have been lots of bug and build fixes checked in since 2.7.3, and feature refinements but as always this might come with their own regressions, so please do a check out of svn/trunk and test the build and execution of this baby :-) Major changes are: Compression/Decompression related support: New gz plugin for reading files from .gz compressed files. Support for zlib compression directly in .ive files. (use osgconv myfile.ive compress.ive -O compress). Support for compressing HeightField use byte/shorts in place of float arrays, and special handling of single height HeightField. (note, VirtualPlanetBuilder supports this new compression) Improvements to DatabasePager New support for controlling the number of threads that the DatabasePager uses. New scheme for managing the expiry of inactive PagedLOD in the DatabasePager, the new scheme allows you to set a taget maximum number PagedLODs. Improvements to DatabasePager's handling of the case of using no pre compile so it performs is now much better when using osgTerrain based datasets. New osgDB::FileCache class for managing local file cache of files download from the internet. All these changes together improve substantially improve performance of streaming paged databases over http. For 2.7.4 I'll build a database and upload to openscenegraph.org for you guys to try out ;-) Robert. -- All 51 check-ins since 2.7.3 are: 2008-10-27 17:11 + [r9066-9067] robert: * Merged in comment split code from the old flt plugin so that FLT comments string with returns in them are put into separate description entries. * From Wojciech Lewandowski, I am sending a really minor fix for StatsHandler::reset method. We dynamically add and remove slave cameras in our application. StatsHandler does not automatically adapt to this situation, and we call StatsHandler::reset to force it to update number of cameras and their graphs. Unfortunately, if stats were already drawn, reset would not remove former graph drawables and they would remain frozen below new stats. This update fixes it. 2008-10-27 16:16 + [r9065] robert: * From Chris Denham, default scene that tests the use of in scene graph Camera which has a RELATIVE_RF ReferenceFrame. 2008-10-27 16:06 + [r9064] robert: * From Chris Denham, fixed support of in scene graph osg::Camera's with ReferenceFrame of RELATIVE_RF. 2008-10-27 15:26 + [r9063] robert: * From Katharina Plugge, I found a bug in the OpenFlight-Plugin. When exporting to OpenFlight it could happen that palettes of an external reference like the texture palette are set wrong, because they are overwritten by parent settings (userData), which actually do not refer to palette entries respectively ParentPools (happens for example if a Transform is parent of a ProxyNode). The static cast from userData to ParentPools should therefore be a dynamic cast. --- function FltExportVisitor::writeExternalReference( const osg::ProxyNode proxy ): Line 423 in file expPrimaryRecords.cpp has to be changed from const ParentPools* pp = static_castconst ParentPools*(proxy.getUserData() ); to const ParentPools* pp = dynamic_castconst ParentPools*(proxy.getUserData() ); 2008-10-27 13:09 + [r9062] robert: * Various warning fixes 2008-10-27 11:49 + [r9061] robert: * Updated wrappers 2008-10-27 11:08 + [r9060] robert: * From Mathias Froehlich, This change is a result of a recent thread on osg-users. The semantic change that went into the ac loader with the past patch was incorrect wrt the document describing the behaviour of ac files and inconsistent with what ac3d itself displays for that files. This attached change reverts the behaviour to the original one. The infrastructure to change this is left in place. The change is based on rev 9045. 2008-10-27 10:42 + [r9058-9059] robert: * From Blasius Czink, Among other things I added support for atomic operations on BSD-like systems and additional methods (for and, or, xor). and a later post the same osg-submissions thread: it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using OpenThreads in a communication/synchronisation library (without OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static
[osg-users] Fwd: Problem with computeIntersections for nodes below post render camera
On Mon, Oct 27, 2008 at 5:18 PM, Chris Denham [EMAIL PROTECTED] wrote: Thanks Robert, I hadn't anticipated you checking also checking in the modified osgpick example. This may not be quite what you might intend, since the default scene used to be fountain.osg, but now has my rather disconcerting scene. Perhaps my test scene would be better to be the default if the default fountain.osg is not found. I'll submit the osgpick.cpp file again if you think that is better. Ohh, yes that would be better, must admit in my rush of tackling a whole range of issue this afternoon I obviously didn't review your change to osgpick critically enough, I was just pleased to have a problem reproducable. Having your little test dataset as a command line option would probably be the best solution. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setViewMatrixAsLook at and getViewMatrixAsLookAt
Now that you have explained to me how it works, maybe you could give me an idea on how to solve a small problem I have. In my application, the user can move the camera freely (all directions and eye positions), but when the camera's direction is close to a given one, it snaps into that given direction, maintaining though, the distance from the objects of the scene. My doubt is on how to set the new view matrix if I can't get from the old matrix the true center of my view... Any ideas? Thanks. Renan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setViewMatrixAsLook at and getViewMatrixAsLookAt
Hi Renan, You'll need to store basic parameters that you use to compute your view matrix, for instance the eye point, center, up, or whatever is most suitable for the type of camera manipulation you wish to undertake. For instance the osgGA CameraManipulator's all have there own camera model that use use internally and on each frame compute the view matrix from these. Robert. On Mon, Oct 27, 2008 at 6:50 PM, Renan Mendes [EMAIL PROTECTED] wrote: Now that you have explained to me how it works, maybe you could give me an idea on how to solve a small problem I have. In my application, the user can move the camera freely (all directions and eye positions), but when the camera's direction is close to a given one, it snaps into that given direction, maintaining though, the distance from the objects of the scene. My doubt is on how to set the new view matrix if I can't get from the old matrix the true center of my view... Any ideas? Thanks. Renan ___ 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] Sharing PrimitiveSets between Geometrys
Folks, Can primitivesets be shared between geometrys similarly to vertexes, colors, and texcoords? Brian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setViewMatrixAsLook at and getViewMatrixAsLookAt
Ditto Robert's comments, with the following info: setViewMatrixAsLookAt doesn't do anything magical, it just fills in the matrix with four vectors to create the orthonormal basis and origin of a new coordinate system. You already have the necessary data to compute this matrix yourself. See the source code for setViewMatrixAsLookAt for guidance. -Paul Hi Renan, You'll need to store basic parameters that you use to compute your view matrix, for instance the eye point, center, up, or whatever is most suitable for the type of camera manipulation you wish to undertake. For instance the osgGA CameraManipulator's all have there own camera model that use use internally and on each frame compute the view matrix from these. Robert. On Mon, Oct 27, 2008 at 6:50 PM, Renan Mendes [EMAIL PROTECTED] wrote: Now that you have explained to me how it works, maybe you could give me an idea on how to solve a small problem I have. In my application, the user can move the camera freely (all directions and eye positions), but when the camera's direction is close to a given one, it snaps into that given direction, maintaining though, the distance from the objects of the scene. My doubt is on how to set the new view matrix if I can't get from the old matrix the true center of my view... Any ideas? Thanks. Renan ___ 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-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB bug or faulty data?
Hi Alejandro You can use gdalwarp to (stamp) the projection information into you data. try using something similar to the following: //call gdalwarp to project my data to wgs84 //This will create a virtual raster (vrt) which does not copy the data of the original raster //but creates a sort of filter for reading the data. gdal_translate -of vrt -a_srs EPSG:4326 volcanes.tif volcanes.vrt //Then use the vrt as input osgdem -d volcanes.vrt -l 8 -v 1.0 -o kk EPSG:4326 is short form defenition of a basic lat lon coordinate system, same format you will receive ie landsat data in. Hope this helps. Brgs. Ralf Stokholm 2008/10/27 Robert Osfield [EMAIL PROTECTED] Hi Alejandro, Your data *is* the problem, please add the coordinate system info. Using the --xx etc options really is not a good solution going forward. Use properly set up data and things will work fine. Please go check out the gdal website for info on how to set up your data. As for VPB docs, I haven't had a chance to write full docs for all the utilities yet. There are some notes online. Robert. On Mon, Oct 27, 2008 at 4:43 PM, Alejandro Aguilar Sierra [EMAIL PROTECTED] wrote: Hi Robert and Umit, As probably you already read it, my data is georeferenced but has no projection info (plain latitude, l,ongitude). Using plain osgdem produces a wrong 1 dimension field (a line). osgdem -d volcanes.tif -l 8 -v 1.0 -o kk I have to give some approximated --xx and --yy data to make it work and even so it does wrongly, creating the mirror image in the Y direction, as you can see comparing the texture image with the produced terrain. Any hint? Where can I find documentation about vpbmaster, vpbcache and vpbsize? Regards, -- A. On Mon, Oct 27, 2008 at 3:40 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Umit, On Mon, Oct 27, 2008 at 9:25 AM, Ümit Uzun [EMAIL PROTECTED] wrote: Thanks for clarification. But I remember that, VPB can manipulate only WGS84 referenced data. But it may be valid for only BlueMarble viewer. Sorry for wrong comment :) When building geocentric databases VPB reprojects the data into WGS84 and then builds the data, if you are using vpbmaster then you'll need to do this reprojection as a prior step to calling vpbmaster. The vpbcache utility can do this reprojection for you. If you are just using osgdem standalone then it can do the reprojection for you. The key is that your source data should have at least a projection that GDAL recognizes otherwise you end up having to build your own projection. GDAL has tools to allow you to do this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] QT4 ViewerQOSG and Q_OBJECT
Not a question so much as a note for the archives. If you want ViewerQOSG to be able to handle signals it must have a Q_OBJECT definition. In order to do this the viewerQT example must swap the order of the definition to class ViewerQOSG : public QOSGWidget, public osgViewer::Viewer The QT moc assumes that the parent class derived from QObject is first in the list. In addition QOSGWidget must not have a Q_OBJECT since you cannot inherit from multiple Q_OBJECT defined classes. Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB bug or faulty data?
Hi Ralph, It works, thank you very much! :) -- A. On Mon, Oct 27, 2008 at 1:57 PM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Alejandro You can use gdalwarp to (stamp) the projection information into you data. try using something similar to the following: //call gdalwarp to project my data to wgs84 //This will create a virtual raster (vrt) which does not copy the data of the original raster //but creates a sort of filter for reading the data. gdal_translate -of vrt -a_srs EPSG:4326 volcanes.tif volcanes.vrt //Then use the vrt as input osgdem -d volcanes.vrt -l 8 -v 1.0 -o kk EPSG:4326 is short form defenition of a basic lat lon coordinate system, same format you will receive ie landsat data in. Hope this helps. Brgs. Ralf Stokholm 2008/10/27 Robert Osfield [EMAIL PROTECTED] Hi Alejandro, Your data *is* the problem, please add the coordinate system info. Using the --xx etc options really is not a good solution going forward. Use properly set up data and things will work fine. Please go check out the gdal website for info on how to set up your data. As for VPB docs, I haven't had a chance to write full docs for all the utilities yet. There are some notes online. Robert. On Mon, Oct 27, 2008 at 4:43 PM, Alejandro Aguilar Sierra [EMAIL PROTECTED] wrote: Hi Robert and Umit, As probably you already read it, my data is georeferenced but has no projection info (plain latitude, l,ongitude). Using plain osgdem produces a wrong 1 dimension field (a line). osgdem -d volcanes.tif -l 8 -v 1.0 -o kk I have to give some approximated --xx and --yy data to make it work and even so it does wrongly, creating the mirror image in the Y direction, as you can see comparing the texture image with the produced terrain. Any hint? Where can I find documentation about vpbmaster, vpbcache and vpbsize? Regards, -- A. On Mon, Oct 27, 2008 at 3:40 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Umit, On Mon, Oct 27, 2008 at 9:25 AM, Ümit Uzun [EMAIL PROTECTED] wrote: Thanks for clarification. But I remember that, VPB can manipulate only WGS84 referenced data. But it may be valid for only BlueMarble viewer. Sorry for wrong comment :) When building geocentric databases VPB reprojects the data into WGS84 and then builds the data, if you are using vpbmaster then you'll need to do this reprojection as a prior step to calling vpbmaster. The vpbcache utility can do this reprojection for you. If you are just using osgdem standalone then it can do the reprojection for you. The key is that your source data should have at least a projection that GDAL recognizes otherwise you end up having to build your own projection. GDAL has tools to allow you to do this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping
FYI, here is the link to the discussion on the Ac3D forum: http://www.inivis.com/forum/showthread.php?t=5090 It seems to be headed in the same direction as Robert's comments regarding keeping track of the UV ranges. -John -- Original Message -- Subject: Re: [osg-users] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping Date: Monday 27 October 2008 From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Hi John, On Mon, Oct 27, 2008 at 4:07 PM, John Cummings [EMAIL PROTECTED] wrote: In the process of finding a small example, I've realized that indeed the reference document is not clear at for this feature. The reference documents say nothing about texture wrap modes at all. Given that this is important feature of texturing the format feels really outdated and insufficient for the job in hand. I am attaching a sample model. Thanks, data illustrating problems are virtual gold dust :-) It is simple a slice of earth with tiled images. I have also attached some screenshots- one with the old behavior in the latest release of OSG, one with the current SVN version, and one with a screeshot of AC3D (sorry about the angle on that one). You will notice that a thin slice of the desert in Africa show up in the Atlantic and vice versa. Clearly not correct. However, AC3D renders it that way- leading me to think our old custom implementation simply papered over the issue. I suspect small OpenGL drivers changing over the last 10 years has lead slightly different intrepretions of texcoords on fragments, such that the 0.99 that appear in your ac file are resulting in fragments being computed with values 1.0 despite the tex coords on the vertices never getting greater than 1.0 or less than 0.0. It used to be the case that values like these would be find with a wrap value of CLAMP, or probably even REPEAT. These days though you have to use CLAMP_TO_EDGE to get the intended behaviour. My guess AC3D was developed quite a while ago, making assumptions about CLAMP/REPEAT working fine with the near to edge tex coordinates that you've used, but with modern drivers things are now broken because the cards are computing the tex coords on fragment slightly differently. Other parts of the OSG have migrated from use CLAMP to CLAMP_TO_EDGE over the years just because of this issue. Things use to work fine with CLAMP, then drivers started popping up that broke this, and required CLAMP_TO_EDGE. I vaguely recall that it might of been ATI drivers that were the first to have problems w.r.t this. I see it now on this dataset on my Nvidia card so it's probably an industry wide migration. I am going to start a discussion on the AC3D forum as well since I think perhaps there is a feature in AC3D that I have not discovered as yet that would allow this behavior. Any other AC3D'ers on this list have some insight? I can't provide any insight as I'm no AC3D user. On the OSG side I think the only thing we could do is parse the tex coord arrays on geometries and if they fit into the 0 to 1.0 range to use CLAMP_TO_EDGE, otherwise use REPEAT. Perhaps an new osgUtil::Optimizer visitor would be appropriate for handling this type of issue. 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] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping
On Mon, Oct 27, 2008 at 10:42 PM, John Cummings [EMAIL PROTECTED] wrote: FYI, here is the link to the discussion on the Ac3D forum: http://www.inivis.com/forum/showthread.php?t=5090 It seems to be headed in the same direction as Robert's comments regarding keeping track of the UV ranges. Which, unfortunately, would still break our app (flightgear), as we have default texture coordinates within the 0,1 range, but later we change those dynamically and assume texture repeat. Of course we could work around that ourselves if absolutely necessary. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TrackballManipulator Question
The TrackballManipulator does not support a zoom function. Rather, the right mouse button pans the Camera along the view direction vector. This is a different effect from zoom, which is a change to the field of view without changing the Camera position. With an orthographic Projection matrix, moving the Camera along the view direction vector obviously has no visual effect; the Camera does not have a distance in an orthographic Projection. So the short answer is that the TrackballManipulator doesn't support the zoom function that you require. Your options? Create a new Manipulator that supports zoom by changing the field of view. To do this correctly, you need to support both changing the field of view in a perspective Projection matrix, as well as changing the left/right/bottom/top values for an orthographic Projection. Hope that helps, -Paul Hello Everyone, I'm trying to use a TrackballManipulator in conjunction with an orthographic camera (i.e., I'm using osg::Camera::setProjectionMatrixAsOrtho()). The problem is that model scaling (with right mouse button) does not work. This is because TrackballManipulator achieves a scaling effect by changing the distance between the camera and the model. Unfortunately, this doesn't have the desired effect when using an orthographic camera. The model does not change size at all in the display window. Then, when I zoom far enough, I start to see parts disappear due to clipping issues. Is there a way for me to use TrackballManipulator (with an ortho camera) more effectively such that I don't see this behavior? If not, is there another built-in manipulator that would work better for my purposes? If not, what are your other recommendations? Thank you very much! Rob PS - I'm using OSG v 2.2 but, from a code inspection, (I think) I've determined that the behavior is the same in version 2.6. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TrackballManipulator Question
Thank you Paul. That does help me out a lot. I have one follow-up question, however. It is not clear to me how to fashion a manipulator so that it automatically modifies the projection matrix. I noticed that osgViewer::Viewer will automatically ask its camera manipulator for the model view matrix when appropriate (via the osgGA::MatrixManipulator::get*Matrix() functions). There doesn't seem to be a similar API for those two classes to pass information about the projection matrix, however. Do you have any advice as to how I should handle this? Thank you so much! Rob *Paul Martz* pmartz at skew-matrix.com mailto:osg-users%40lists.openscenegraph.org?Subject=Re%3A%20%5Bosg-users%5D%20TrackballManipulator%20QuestionIn-Reply-To=%3C0EB1FC78DFF641B88B4D49BBD70D473E%40Supreme%3E /Mon Oct 27 19:26:21 PDT 2008/ * Previous message: [osg-users] TrackballManipulator Question 017960.html * *Messages sorted by:* [ date ] date.html#17961 [ thread ] thread.html#17961 [ subject ] subject.html#17961 [ author ] author.html#17961 The TrackballManipulator does not support a zoom function. Rather, the right mouse button pans the Camera along the view direction vector. This is a different effect from zoom, which is a change to the field of view without changing the Camera position. With an orthographic Projection matrix, moving the Camera along the view direction vector obviously has no visual effect; the Camera does not have a distance in an orthographic Projection. So the short answer is that the TrackballManipulator doesn't support the zoom function that you require. Your options? Create a new Manipulator that supports zoom by changing the field of view. To do this correctly, you need to support both changing the field of view in a perspective Projection matrix, as well as changing the left/right/bottom/top values for an orthographic Projection. Hope that helps, -Paul Rob Radtke wrote: Hello Everyone, I'm trying to use a TrackballManipulator in conjunction with an orthographic camera (i.e., I'm using osg::Camera::setProjectionMatrixAsOrtho()). The problem is that model scaling (with right mouse button) does not work. This is because TrackballManipulator achieves a scaling effect by changing the distance between the camera and the model. Unfortunately, this doesn't have the desired effect when using an orthographic camera. The model does not change size at all in the display window. Then, when I zoom far enough, I start to see parts disappear due to clipping issues. Is there a way for me to use TrackballManipulator (with an ortho camera) more effectively such that I don't see this behavior? If not, is there another built-in manipulator that would work better for my purposes? If not, what are your other recommendations? Thank you very much! Rob PS - I'm using OSG v 2.2 but, from a code inspection, (I think) I've determined that the behavior is the same in version 2.6. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] updateCalculatedNearFar problem
hi all,
It seems that there is a problem with
CullVisitor::updateCalculatedNearFar,I have the code like this:
osgViewer::Viewer viewer;
class MCallBack : public osg::NodeCallback
{
public:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osg::PositionAttitudeTransform *pat =
dynamic_castosg::PositionAttitudeTransform *(node);
if( pat != NULL )
{
osg::Camera *camera=viewer.getCamera();
osg::Matrixd pMatrix = camera-getViewMatrix();
pat -setAttitude(pMatrix.getRotate());
}
}
};
osg::Node* fun()
{
osg::Geode* geode=new osg::Geode;
geode-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0,0,0),0.1)));
osg::MatrixTransform *mt=new osg::MatrixTransform ;
Matrix matrix;
matrix.setTrans(osg::Vec3(1,0,0));
mt-setMatrix(matrix);
mt-addChild(geode);
osg::PositionAttitudeTransform * tran = new osg::PositionAttitudeTransform;
tran-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
tran-setPosition(osg::Vec3(5,5,0));
tran-addChild(mt);
tran-setUpdateCallback(new MCallBack());
osg::Projection* ProjectionMatrix = new osg::Projection;
ProjectionMatrix-setMatrix(osg::Matrix::ortho2D(0,10,0,10));
ProjectionMatrix-addChild(tran);
return ProjectionMatrix;
}
int _tmain(int argc, _TCHAR* argv[])
{
osg::Node* mRoot =fun();
viewer.setSceneData(mRoot);
return viewer.run();
}
when i rotate the scene,the scene is culled not exactly.
Is there a bug with osg or something wrong with my code?
thanks for any advice.
best regards
forest___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
