Re: [osg-users] own load implementation for pagedLOD
Thanks for your reply. That was very helpful, its working perfect now. Just a note for other who may have the same problem: For 1. and 3.: I searched a little for some examples, so i found that the "osgphotoalbum" is exactly the example i needed. For QImage<->Texture conversion the following code did the trick, maybe it could be a little bit optimized: Code: // get QImage QImage* tempqimage=YOUR_IMAGE_GETTER_FUNCTION(); // create OSG texture osg::Texture2D* Texture = new osg::Texture2D; Texture->setDataVariance(osg::Object::DYNAMIC); // create OSG image osg::Image* img = new osg::Image(); img->setAllocationMode(osg::Image::USE_NEW_DELETE); img->setOrigin(osg::Image::TOP_LEFT); img->allocateImage(tempqimage->width(), tempqimage->height(), 32, GL_RGBA, GL_UNSIGNED_BYTE ); // convert QImage to ARGB (i tried RGB but it seems to be not working) QImage tempqimage2=tempqimage->convertToFormat(QImage::Format_ARGB32); memcpy(img->data(),tempqimage2.bits(),tempqimage2.byteCount()); // assign the texture to the image Texture->setImage(img); delete tempqimage; -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25313#25313 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture with independent framerate
Hi Georg, maybe have a look at this: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/49423 you can render to texture with the main camera "disabled". jp Georg Martius wrote: Hello, I am using OSG for a robotics simulator [1] already a while. Now I want to implement a "camera sensor", meaning the simulation of a physical camera mounted on a robot. I got it to work with Render to Texture. However I have the following problem: The rendering of the normal graphics is detached from the physical simulation speed. E.g. I can run the physics as fast as I can and render still only 25fps. However, the camera sensor needs to be synchronized with the physical simulation. How can I render the scene explicitly into the texture indepently of the viewer? At the moment the scene graph looks as follows: Viewer with main cam - Root - HUD display (with another camera overlay to see the texture) - Camera sensor (RRT) - World - World - Shadow - Scene I have also problems with the shadow when the RRT camera is used. I read [2-3] to use slave views, but did not success. Any suggestions would be highly appreciated. Cheers, Georg [1] http://robot.informatik.uni-leipzig.de/videos [2] http://www.mail-archive.com/osg- us...@lists.openscenegraph.org/msg33512.html [3] http://www.mail-archive.com/osg- us...@lists.openscenegraph.org/msg36229.html -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgMovie and the ImageStream Object
I had a bit of trouble tracking down where the ImageStream object is handled, and I think I've worked it out, but it's quite odd, even for a demo. As far as I can tell, an Image is created from the provided file name and held in a pointer. That image is cast to an imagestream for some housework. A texture is created and the image is set as it's source - this is all a pointer, as far as I can tell, not the refPtr I expected to see. Then, the main thread seems to forget about the image/s, and moves on. It then goes into a visitor, which finds any images and makes a ref pointer list to them. Is that about right? So there's a ref pointer and a raw pointer floating around at once? And for a while, only a pointer? Isn't that a pretty nasty situation? Am I missing some C++ kung-fu to make refPtrs in the texture or earlier? Is there an example with a 'better' management of image/stream objects? Regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Textures on loaded models are flipped.
Hi, In some cases when I'm loading models with textures (jpeg or tga was tested so far), my textures are flipped horizontally on 180 degrees see attached picture. I can reproduce this problem with my application and with osgviewer as well. What the problem is and how could I solve this issue? Thank you! Cheers, Danny -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25309#25309 Attachments: http://forum.openscenegraph.org//files/fliiped_158.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGEXP building problem...
I solved this like this: #if MAX_VERSION_MAJOR < 12 //MAX2010 TCHAR* renderBinName; #else const MCHAR* renderBinName; #endif for all TCHAR* in OSGHelpers.cpp (3x) and once "TCHAR *name;" in MtlKeeper.cpp. Laurens. alessandro terenzi wrote: Don't know if this is the right place to ask for help, but I'm trying to build OSGExp wrt OSG 2.9.7 and Max SDK 2010 and I get compile errors (many like this): 1>..\..\src\OSGExp\OSGHelpers.cpp(220) : error C2664: 'BOOL IParamBlock2::GetValue(ParamID,TimeValue,float &,Interval &,int)' : cannot convert parameter 3 from 'TCHAR *' to 'float &' I'm building using Visual C++ 2008 Express. Anyone having the same problem? Any suggestion? Thanks in advance. Kind regards. Alessandro ___ 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] Could not find plugin on Mac OS X 10.6.2
Hi, I am having the same problem and struggling to find a solution. I'm building using the XCode project, and everything was working fine in 2.8.2, the plugins were found. However, since updating to 2.9.6 it appears the OSG_PLUGIN_EXTENSION is not set - Where should this be set please? I get the following when adding some debug... using libraryName osgPlugins-2.9.6/osgdb_3dsOSG_PLUGIN_EXTENSION Trying /Users/tobiasduckworth/Library/Application Support/OpenSceneGraph/PlugIns/osgPlugins-2.9.6/osgdb_3dsOSG_PLUGIN_EXTENSION Trying /Library/Application Support/OpenSceneGraph/PlugIns/osgPlugins-2.9.6/osgdb_3dsOSG_PLUGIN_EXTENSION Trying /Users/tobiasduckworth/Library/Application Support/OpenSceneGraph/PlugIns/osgdb_3dsOSG_PLUGIN_EXTENSION Trying /Library/Application Support/OpenSceneGraph/PlugIns/osgdb_3dsOSG_PLUGIN_EXTENSION I found a recent post about the freetype mingw changes, which apparently caused this problem - However looking at the diffs from 22nd January 2010 (revision 10983) which revert this change I cannot see how the OSG_PLUGIN_EXTENSION definition is affected. Please could somebody explain where OSG_PLUGIN_EXTENSION should be set? Many thanks ... Thank you! Cheers, Tobias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25294#25294 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vicon tracking
On Wed, Mar 3, 2010 at 10:56 AM, Mel Av wrote: > Hey all, > > Many thanks for your answers. > The Vicon system uses a z-up coordinate system, with millimeter units. It > sends x,y,z coordinates for a given tracked object(in that case the cap you > are wearing) as well as rotation information in axis/angle form. The client > I'm using converts this to three different forms I can use interchangeably: > 1. Euler angles > 2. Global rotation matrix > 3. Quaternion > > Right now I am just using the viewer->getCamera()->setViewMatrix() call > before the viewer.frame() call. The problem seems to be that the matrix I > pass to setViewMatrix() does not seem to be correct. I use the x,y,z > coordinates for the cap to set the translation matrix ( tr.makeTranslate() ) > and the quaternion to set the rotation matrix ( rot.makeRotate() ). I then > multiply tr * rot and pass this to setViewMatrix(). The result is that when > I move closer to the projected image, the rendered objects seems to come > closer, which is correct behavior, but when i rotate my head this causes the > rendered objects to rotate in the opposite direction. The code I use is from > the OSG Quick start guide and it was supposed to change the view according > to its description. However this does not seem to be the case for two > reasons, from what I found out last night reading one old camera tutorial: > 1. You have to inverse the tr*rot result first > 2. After you do that, you have to rotate -90 degrees about the x-axis > because Matrix classes use a Y-up coordinate frame whereas the viewer uses a > Z-up coordinate frame. > > Will these two corrections solve the problem? Will I also need to do > something more advanced like dynamically changing the frustum according to > the head position? > yup, you will need to re-compute the proper frustum dynamically. To do that, you will need to know the position/orientation of sensor coordinate system is w.r.t. the 'window'. Then you need to transform where your head is with respect to the window. Finally you will need to know where your 'window' (what you see the world through) is w.r.t. your model world coordinate system. And of course you will need to know this for the left/right eye positions. Doing a good job to solve for these transformations might take you a little thought/time depending on your set up. But, as it seems like you have figured out as much, you can see that it can all be realized pretty easily with OSG matrix objects once you obtain the needed transformations. Sometimes, as you start to chain your transformations together, it might make things easier to break it down into smaller steps and test out what you see. With so many different conventions, etc... > > Thank you! > > Cheers, > Mel > > P.S Sorry if my questions seem nub. I just thought I had the necessary > background for understanding rotation and translation transformations but > I'm completely confused by how OSG handles these and why it uses different > coordinate frames in different situations. Anw, perhaps I'm confused by > DirectX because camera manipulation was much easier with the separation of > the Modelview matrix in two different matrices whereas in OpenGL you may be > moving/rotating objects instead of the actual camera viewpoint. > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=25121#25121 > > > > > > ___ > 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] fixes for warnings in vs2008.
Thanks Robert, I will checkout the latest and let you know if I find any problems. Martin. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 05 March 2010 13:07 To: OpenSceneGraph Users Subject: Re: [osg-users] fixes for warnings in vs2008. Hi Martin et. al, On the topic of masks and the debate that Tom pointed to. At the time said I would let the issue lie and return to it once I'm come to conclusion once things had settled. It's one of these issues where it's six of one and half a dozen of the other. Time has gone on and your post has spurred me to finally make my mind up. Masks to be unsigned int or int? On considering all the different possibilities and issues I've come to conclusion that types for masks where enum's are the most natural way of specify the options then int's should be used. Traditionally the OSG code bases uses unsigned int in this situation, and I've always felt it more natural that a mask would be an unsigned int, but... enum's are int's and with compilers getting more a more picky about types the use of unsigned int for masks that we use in conjunction with enum. Either we'd have to ditch the use of enum's in this context and adopted #define or static const unsigned int usage in it's place, or adopt int's. The later seems like the line of least resistance, and easist to maintain long term (as it's the most minimal code wise) and the easiest for OSG users as it should avoid the need to introducing casting that users previous had to do to avoid some warnings. I have now gone through the OSG headers and source files and updated them to using int's for the mask types where appropriate. One place - osgSim::ObjectRecordData I've kept unsigned int as this matched the OpenFlight file format that it was mapping, and have replaced the previous enum with a series of static const unsigned int declarations in the headers. This combination avoids warnings. These changes are now checked into svn/trunk. Fingers crossed there won't be any build breakages, and hopefully should address some of the warnings - it's fixed some for me ;-) Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with glass door in front of glass shelf.
Thanks Paul, I'll look into that. I was also wondering if it was possible to use kd tree to solve ordering problem, but not got round to investigating yet. I know there's code already in osg for dealing with bsp and kd trees, so, is there an easy way to use that code to solve my glass problem? Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25304#25304 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
