Re: [osg-users] Do any one know
Hi Sunitha, please only ask a question once and use more descriptive subjects. As for your question, you have to realize that the model you are loading is usually stored as a subgraph, so the particular stateset you are looking for doesn't have to be on the root node of your model (hence you get null). You can see this by converting your .iv model to .osg with osgconv and inspecting the result with a text editor. In your program you would tipically use a NodeVisitor in order to traverse your model nodes and get the stateset you are interested in. I recommend you to read the OSG Quick Start Guide by Paul Martz. Is available at http://stores.lulu.com/pmartz Regards, Alberto El Martes 03 Febrero 2009ES 07:50:05 sunitha sunagad escribió: -- Hi, I am loading an iv file in Osg i need to know the StateSet of the particular node i pick in the iv file loaded on to the osg iv file has its Attributes in itthat is applied to the mode i need the information from it I am getting the picked node information and in turn i need to know the StateSet Atrributes of the current picked node... I am using the Pickednode-getStateSet() i get null each time Is ther any way that i have to set the attributes ON while Loading the mode Please Let me know Regards Sunitha. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash errors/warnings
On Mon, Feb 2, 2009 at 10:25 PM, Shue, John A john.s...@mantech.com wrote: Robert, This latest CMakeLists.txt file works on my machine. Horahh!!! :-) Let's just hope it works under CMake 2.4.8 as well. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (no subject)
HI Sunitha, In future posts could you use a relevant subject line as this helps with mail clients to thread appropriately, and also for others down the line to find threads on particular topics in the archives. When you load a scene graph from any of the 3d loaders you'll get a complete scene graph with a single node at it's root, the StateSets that contain the OpenGL state will be distributed across this graph, and will rarely just be contained at the root node. This means you'll need to traverse the scene graph to find the StateSets, to do this the best way is to write a custom NodeVisitor. There are many examples of custom NodeVisitor all over the OSG source code and examples - just do a search for NodeVisitor to see it in action. Robert. On Tue, Feb 3, 2009 at 6:42 AM, sunitha sunagad sunithassuna...@gmail.com wrote: -- How can i get the staeset of the model i have lodeaded to the openScenegraph I am loading an iv file which has the state set attribute in it i need the current state set attribute does any one know... I am using getStateset but its returning null. Always Keep Smiling! Defeat the defeat before defeat defeats you Regards Sunitha.S.Sunagad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS et. al, On Mon, Feb 2, 2009 at 8:51 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Sooo... What are you planning as an upload area for packages? :-) You said we'd put them into SVN, but do you plan to give all of us commit access to a given area of the SVN? Perhaps an FTP would be easier, we could just upload and people would download and then once we've confirmed the packages are good you can commit the packages to SVN... After the last discussion on this topic I end up leaning towards not using svn for binaries. The server supports webdav as well as ftp. I'll go an experiment with these routes and report back. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi, svn rev 9631 builds correctly on CentOS 4.7: - Kernel: 2.6.9-78.0.8.ELsmp - gcc: 3.4.6-10 I have also setup a continuous build for trunk which will keep on building until 2.8 is out! Appreciate everybody's effort in getting 2.8 out asap;) Best regards, John Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Best regards, John WeatherOne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Melchoir, On Tue, Feb 3, 2009 at 7:33 AM, Melchior FRANZ melchior.fr...@gmail.com wrote: Just for the record: I've had several segfaults in OSG's particle code (threading related) since I updated a few days ago. I'll post a backtrace when I run into it again. The particle code has changed very little in the last year, and only a tiny tweak recently that won't effect threading stability. It could be an old problem that has only just now surfaced, or perhaps just a build consistency issue. Do any of the standard particle examples reproduce the crash? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Umit, On Tue, Feb 3, 2009 at 3:58 AM, Ümit Uzun umituzu...@gmail.com wrote: Sorry for late but I have already tried 2.8 :) There are some problem, while using osgviewer sometimes there was a Error: [Screen #0] GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers problem. And almost all examples working on my system but osgprecipictation example make my computer lock and after I run this example I get push emergency shutdown button :) Maybe because of my system's configuration. But I have no luck to figure it out what was the problem because of there was no message in deadlock mode :( My System : XP Pro SP3, Core2 2.2GHz, ATI Mobility Radeon HD 2300, 2 GB Ram I suspect the problems are caused by dodgy ATI drivers - both the swap buffers and the preciptation rendering. I have seen first hand ATIcards really struggling with osgpreciptiation, it looks like drivers are errors in particle sizing that in turn causes huge fill requirements that in turn leads to very low framerate, which makes the particles even larger due to the motion blurr that osgparticle implememts, which makes things worse... With decent drivers osgparticle works well even on relatively low hardwre, but it has to support GLSL properly. Thanks for Ver-2.8 to OSG-Family and especially Robert by 9 passion hardworking years :) Thanks. This morning it occurred to me that it's now 2009, which means it's actually a decade now since I started putting significant amounts of time into the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
ok, but what I have to do to change xine by ffmpeg for example ? I have to write other plugin ? On Tue, Jan 13, 2009 at 9:34 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Carlos, From your description this does sound like a threading issue with xinelib. xinelib wasn't really designed for how we use it, rather it's a lib designed for writing conventional movies players, and to get video support under Linux I had to fit this square peg through a round hole. When I wrote this plugin a few years back I looked at various alternatives but none were mature enough/amenable enough to be squished through our usage requirements, xinelib ended up being the best of bad lot. Things under Linux haven't stood still, gstreamer is probably viable now, and J.P mentions about a ffmpeg plugin that actually been developed and might even be open source soon. My guess is that now both gstreamer and ffmpeg are probably better routes for video support under Linux. Robert. On Tue, Jan 13, 2009 at 11:18 AM, Carlos Sanches ces...@gmail.com wrote: if I play only one movie there are no problem . the movie play well. if I wish play the second movie . the problem occours when I call play . if I try use the same video to first and second , when I play the second the program crash. the movies are ok . I play it in mplayer I m trying to play avi movies without compression . Remembering if I play only one all is fine . :( On Mon, Jan 12, 2009 at 8:42 PM, Gerwin de Haan gerwindeh...@gmail.com wrote: Dear Carlos, from my experiments some time ago (osg 2.4, ubuntu 7.10), playing _multiple_ movies through ImageStream instances using the osgdb xine plugin result in sporadic crashes and funny playback/pause behavior, most probably caused by threading issues. At the time I did not have the time to go into the problem too deeply, but I recall I found it suspicious that only a single xine player instance was responsible for handling multiple movies. Again, crashes might also have been caused by some video codec used inside xine. What type of movie (container, codec, sound, size etc.) are you trying to play? regards, Gerwin ps. I was hoping for some public ffmpeg plugin implementation to pop up on the list, but either I missed it or it's not yet been released. On Mon, Jan 12, 2009 at 6:51 PM, Carlos Sanches ces...@gmail.com wrote: Excuse-me I m going crazy. My version is OpenSceneGraph Library 2.7.7 OS Ubuntu 8.04 My program load the movies. I play the first but when I will play the second the program crash . This is what is happening ... *** glibc detected *** ./OSG: double free or corruption (out): 0xafd31008 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6[0xb7444a85] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb74484f0] /usr/local/lib/osgPlugins-2.7.7/osgdb_xine.so[0xb5add753] /usr/lib/libxine.so.1[0xb5aa54d8] === Memory map: 08048000-08071000 r-xp 08:12 6046911 /dados/workspace/desenv/OSG/Debug/OSG 08071000-08072000 rw-p 00028000 08:12 6046911 /dados/workspace/desenv/OSG/Debug/OSG 08072000-0fd3 rw-p 08072000 00:00 0 [heap] a1778000-a1779000 ---p a1778000 00:00 0 a1779000-a1f79000 rwxp a1779000 00:00 0 a1f79000-a20a5000 rw-s 2c15f000 00:0e 13809 /dev/nvidia0 a20a5000-a22ff000 rw-p a20a5000 00:00 0 a22ff000-a230 ---p a22ff000 00:00 0 a230-a2b0 rwxp a230 00:00 0 a2b0-a2bd4000 rw-p a2b0 00:00 0 a2bd4000-a2c0 ---p a2bd4000 00:00 0 a2c0-a2c6c000 rw-p a2c0 00:00 0 a2c6c000-a2d0 ---p a2c6c000 00:00 0 a2d0-a2dfc000 rw-p a2d0 00:00 0 a2dfc000-a2e0 ---p a2dfc000 00:00 0 a2f0-a2ffe000 rw-p a2f0 00:00 0 a2ffe000-a300 ---p a2ffe000 00:00 0 a310-a31f7000 rw-p a310 00:00 0 a31f7000-a320 ---p a31f7000 00:00 0 a330-a33fc000 rw-p a330 00:00 0 a33fc000-a340 ---p a33fc000 00:00 0 a350-a35f9000 rw-p a350 00:00 0 a35f9000-a360 ---p a35f9000 00:00 0 a370-a37fc000 rw-p a370 00:00 0 a37fc000-a380 ---p a37fc000 00:00 0 a390-a39fe000 rw-p a390 00:00 0 a39fe000-a3a0 ---p a39fe000 00:00 0 a3b0-a3bff000 rw-p a3b0 00:00 0 a3bff000-a3c0 ---p a3bff000 00:00 0 a3d0-a3df9000 rw-p a3d0 00:00 0 a3df9000-a3e0 ---p a3df9000 00:00 0 a3f0-a3fed000 rw-p a3f0 00:00 0 a3fed000-a400 ---p a3fed000 00:00 0 a400-a40fb000 rw-p a400 00:00 0 a40fb000-a410 ---p a40fb000 00:00 0 a410-a41ff000 rw-p a410 00:00 0 a41ff000-a420 ---p a41ff000 00:00 0 a430-a440 rw-p a430 00:00 0 a450-a45fc000 rw-p a450 00:00 0 a45fc000-a460 ---p a45fc000 00:00 0 a470-a47fc000 rw-p a470 00:00 0 a47fc000-a480 ---p a47fc000 00:00 0 a490-a49f9000 rw-p a490
Re: [osg-users] Histroy Buffer Implementation / Suggestion
Thanks for the tip Adrian but so far I'am facing problems with PSSM . I get the following output : RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: FrameBufferObject: could not create the FBO RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x0 Warning: FrameBufferObject: could not create the FBO RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x0 FRAGMENT glCompileShader FAILED glLinkProgram FAILED I don't know why. I have tested FBO support with osgprerender --hdr --fbo cow.osg and it works. On Mon, Feb 2, 2009 at 9:31 AM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Hello all You should use lispsm or pssm shadow : even for terrain this gives nice looking shadows (with pssm you can limit the max far distance, use this say 250m, and you will get nice shadows) but once we have the latest idea implemented, the shadow quality gets much better, this would be of sure true, but may the performance will be very bad. so i am looking for high performance and robust technic. I don't really like to implement this with osgPPU, because of the problem robert told (see submission discussion) not tha osgPPU is bad, but it would better be nicely integrated into osg and osgShadow, not only for osgShadow and its quality the histroy buffer could have high impact, also for others shaders. Then for the default shader in openscenegraph may we should think to redesign them, because actually we have shaders in shadow, ... , but each of the re-writes the very basics, may we could think about of GLSL shader modules, code modules then we can put them together, this would be greate. i have some idea how this could be solved. but i have to think about more of this idea. /adrian 2009/2/1 Simon Loic simon1l...@gmail.com It would be very interested to see the resulting shadows of this method in osg. I'am currently using the basic shadow technic and the rendering is so aliased! Maybe I'am not using it in the right way. On Fri, Jan 30, 2009 at 4:44 PM, Art Tevs stud_in...@yahoo.de wrote: Hi Adrian, for all 2D effects there exists already a pipeline with couple of examples (gauss blurr, depth of field, hdr and so on), however you maybe have heard about it already. Take a look into osgPPU. I took a small look into the paper and saw that the main method is just to combine N previous images in some sense together to achieve nice results. As you said, using the history buffer. Using pure osg components, one could for example setup N cameras with corresponding textures and switch them framewise. Then current rendering camera use the input of other N-1 cameras to produce its new output. Using osgPPU, I would suggest to implement new class UnitHistoryBuffer, which will do this trick, by collecting the inputs in some buffer, e.g. 3D texture or 2D texture array. Output of this unit can then be combined with current rendering camera in the way as described in the paper. This shouldn't be a big trick, yeah, maybe I can do this for the upcoming v0.4 release ;) I am wonder if one could use this technique for some sreen space effects, not only for motionblur, but also for optical flow detection or something similar ??? Maybe for something like hybrid ray tracing approach, where some kind of heuristic function could use this information to retrace only neccessary rays. cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5545#5545 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Loïc Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Loïc Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash errors/warnings
Hi John, I've just checked the dashboard and spotted that your FreeBSD 6 build has generated many warnings, all of the type warning: format not a string literal, argument types not checked, and all of which stem from locale_facets.h, which is part of gcc's std library support. This looks to be an issue with gcc rather than OSG, as the OSG files that instigate the error are just of the form ostream double, which is perfectly valid C++. Since this looks very much to be a false positive, resolving it may have to be bumping down the aggressive warning level, or explictly disabling this warning. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
About the stats display problem, it's resolved here, thanks ! On Tue, Feb 3, 2009 at 10:15 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Umit, On Tue, Feb 3, 2009 at 3:58 AM, Ümit Uzun umituzu...@gmail.com wrote: Sorry for late but I have already tried 2.8 :) There are some problem, while using osgviewer sometimes there was a Error: [Screen #0] GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers problem. And almost all examples working on my system but osgprecipictation example make my computer lock and after I run this example I get push emergency shutdown button :) Maybe because of my system's configuration. But I have no luck to figure it out what was the problem because of there was no message in deadlock mode :( My System : XP Pro SP3, Core2 2.2GHz, ATI Mobility Radeon HD 2300, 2 GB Ram I suspect the problems are caused by dodgy ATI drivers - both the swap buffers and the preciptation rendering. I have seen first hand ATIcards really struggling with osgpreciptiation, it looks like drivers are errors in particle sizing that in turn causes huge fill requirements that in turn leads to very low framerate, which makes the particles even larger due to the motion blurr that osgparticle implememts, which makes things worse... With decent drivers osgparticle works well even on relatively low hardwre, but it has to support GLSL properly. Thanks for Ver-2.8 to OSG-Family and especially Robert by 9 passion hardworking years :) Thanks. This morning it occurred to me that it's now 2009, which means it's actually a decade now since I started putting significant amounts of time into the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, So are we ready for the OSG-2.8 branch?? It looks like we are a good position to tag. Please raise your hand now if there is something amiss that I need to address. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgAnimation Issue
You're welcome In fact i did not know that in blender we could do it this way that's why the exporter does not hnadle the case because i dont use it. It's a good opportunity to improve the exporter to manage this case. I will try to add that soon. Cheers, Cedric Ryan Morris wrote: Cedric, Thanks for taking the time to look into this. I did have a revelation a few days ago that lead me to the same conclusion. Basically I had to go back and assign vertices to the named vgroups. not a big deal once I figured it out I was just going crazy thinking I was doing something completely wrong. I figured the exporter should recognize this but it works perfectly if I do the following: -select a vgroup -select the vertices I want in the group -click the assign button that seemed to fix my issues. Again thanks Cedric for all your help and hard work! -Russ ___ 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:morni...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SVN (2.8) bugs in osgviewerQt
Hi Robert,
I first posted about these problems in the Test 2.8 thread. I still
see two problems in the osgviewerQt example and managed to reproduce
both in the attached modified file.
1. Unable to spin/throw a model using QOSGWidget as a viewer.
2. viewer-addView doesn't work if the composite viewer is empty and
trying to add a new view at runtime.
These problems can be reproduced with the following command line (and
the above modified file):
osgviewerQt cessna.osg --QOSGWidget --CompositeViewer
Apart from this issue, 2.8 works fine in my application.
Thanks for all the effort you put into OSG, it really is an excellent library!
Cheers,
Morne
/* OpenSceneGraph example, osganimate.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#if USE_QT4
#include QtCore/QString
#include QtCore/QTimer
#include QtGui/QKeyEvent
#include QtGui/QApplication
#include QtGui/QtGui
#include QtGui/QWidget
using Qt::WindowFlags;
#else
class QWidget;
#include qtimer.h
#include qgl.h
#include qapplication.h
#define WindowFlags WFlags
#endif
#include osgViewer/Viewer
#include osgViewer/CompositeViewer
#include osgViewer/ViewerEventHandlers
#include osgViewer/GraphicsWindow
#include osgViewer/ViewerEventHandlers
#if defined(WIN32) !defined(__CYGWIN__)
#include osgViewer/api/Win32/GraphicsWindowWin32
typedef HWND WindowHandle;
typedef osgViewer::GraphicsWindowWin32::WindowData WindowData;
#elif defined(__APPLE__) // Assume using Carbon on Mac.
#include osgViewer/api/Carbon/GraphicsWindowCarbon
typedef WindowRef WindowHandle;
typedef osgViewer::GraphicsWindowCarbon::WindowData WindowData;
#else // all other unix
#include osgViewer/api/X11/GraphicsWindowX11
typedef Window WindowHandle;
typedef osgViewer::GraphicsWindowX11::WindowData WindowData;
#endif
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include osgDB/ReadFile
#include iostream
#include sstream
class QOSGWidget : public QWidget
{
public:
QOSGWidget( QWidget * parent = 0, const char * name = 0, WindowFlags f
= 0, bool overrideTraits = false);
virtual ~QOSGWidget() {}
osgViewer::GraphicsWindow* getGraphicsWindow() { return _gw.get(); }
const osgViewer::GraphicsWindow* getGraphicsWindow() const { return
_gw.get(); }
protected:
void init();
void createContext();
virtual void mouseDoubleClickEvent ( QMouseEvent * event );
virtual void closeEvent( QCloseEvent * event );
virtual void destroyEvent( bool destroyWindow = true, bool
destroySubWindows = true);
virtual void resizeEvent( QResizeEvent * event );
virtual void keyPressEvent( QKeyEvent* event );
virtual void keyReleaseEvent( QKeyEvent* event );
virtual void mousePressEvent( QMouseEvent* event );
virtual void mouseReleaseEvent( QMouseEvent* event );
virtual void mouseMoveEvent( QMouseEvent* event );
osg::ref_ptrosgViewer::GraphicsWindow _gw;
bool _overrideTraits;
};
QOSGWidget::QOSGWidget( QWidget * parent, const char * name, WindowFlags f,
bool overrideTraits):
#if USE_QT4
QWidget(parent, f), _overrideTraits (overrideTraits)
#else
QWidget(parent, name, f), _overrideTraits (overrideTraits)
#endif
{
createContext();
#if USE_QT4
setAttribute(Qt::WA_PaintOnScreen);
setAttribute(Qt::WA_NoSystemBackground);
setFocusPolicy(Qt::ClickFocus);
#else
setBackgroundMode(Qt::NoBackground);
#endif
}
void QOSGWidget::createContext()
{
osg::DisplaySettings* ds = osg::DisplaySettings::instance();
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-readDISPLAY();
if (traits-displayNum0) traits-displayNum = 0;
traits-windowName = osgViewerQt;
traits-screenNum = 0;
traits-x = x();
traits-y = y();
traits-width = width();
traits-height =
Re: [osg-users] Bug in 2.7.9 with collada
Patrice Bouvier wrote: Hi All, I'm working under ubuntu 8.04 Hardy. I've just installed the OSG 2.7.9 version. Unfortunately i've a problem with a collada scene, no textures are loaded. With the 2.6.1 version it was ok. I use the collada dom 2.0 version. Could someone give me a fix for that problem ? Thanks Patrice Without any information a fix will be difficult :-) Can you at least supply a copy of your osg notify log. If your model is a large one it would be good if you could cut it down to a single geometry node which fails to show a texture and post that. Collada files are xml and quite easy to hand edit. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hi Davide, On Tue, Feb 3, 2009 at 9:57 AM, Davide Bacchet davide.bacc...@gmail.com wrote: I compared a Macbook core2Duo 2GHz, intel graphics with a dell dimension laptop, pentium 4 2.0GHz and nvidia graphics. What it is feeling strange to me is that there is almost no difference in performances if I use GLUT (like in the osgviewerGLUT example) but a huge difference if I use the plain osgviewer class (like in the osgviewer example) I'm setting up a very simple example to try to reproduce the problem with a single file, I will post it tomorrow morning as soon as I can access a windows machine There shouldn't be a performance difference between osgviewerGLUT and osgviewer like your seeing, rather if you see a performance difference it should be that the standard viewer should be faster as multi-threading should be use. For such a small difference it'd a small difference, but it should be there. The fact that you aren't see a performance improvement, rather than opposite suggets to me that the OpenGL driver/Carbon is not creating a properly accelerated graphics context, and may well be dropping down to software rendering. It shouldn't be doing this, but it's the only thing I can think of that might explain this pattern. I've used quite a few macs over the years, including a brief look at using a Mac mini that had Intel graphics and it worked OK with the standard osgviewer. Fill rate was very poor, but it was still able to do the cow.osg at 60Hz. None of my previous Mac experience has seen a drop down to software rendering though. One test it would be worth doing is resizing the window to see if this affects performance, if it does then this scream out that the graphics context is being done on the CPU. BTW, do you see performance issues with osgviewer cow.osg? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender, On Tue, Feb 3, 2009 at 11:26 AM, Sukender suky0...@free.fr wrote: Uh??? I sent you a 7z file... it's okay if it's binary, isn't it? There wasn't an extension on the end of the file, I didn't get to find out that it was a 7z file... Here is a zip with only the CSV inside (the txt is about 360 ko). Please tell me if it's okay. This came through fine. CSV doesn't add anything, straight compiler output is actually the most convenient for me, as I don't need remove an non essential stuff like the warning number in the list. From looking at the file was is very clear is that include\osgIntrospection\TypedMethodInfo generates almost all the warnings. So I'd suggest we using a #pragma to disable the specific C4121 warning for this header. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender, On Tue, Feb 3, 2009 at 11:41 AM, Robert Osfield robert.osfi...@gmail.com wrote: From looking at the file was is very clear is that include\osgIntrospection\TypedMethodInfo generates almost all the warnings. So I'd suggest we using a #pragma to disable the specific C4121 warning for this header. To the include/osg/TypedefMethodInfo header I've added: #if defined(_MSC_VER) // disable for this header the VS warning C4121 : alignment of a member was sensitive to packing #pragma warning( push ) #pragma warning( disable : 4121) #endif ... #if defined(_MSC_VER) #pragma warning( pop ) #endif In attempt to disable this specific warning for just this file, in the hope that it'll quieten things done. This change is now checked in. File also attached. Could you try a rebuild to see if this warning is now gone? If this doesn't work we'll need to remove the push/pop. I'll now look at the other warnings. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Building on Windows XP, Visual Studio 2008 sp1. All builds fine, but
getting same warnings as Sukender (haven't tried your latest updates
Robert...about to rebuild with latest revision).
Examples run good except getting crash in osgTexture2D with a map/set
iterator not incrementable error. This error goes away if I add
viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded ); to the
example...maybe thread safety issue with incrementing _currPos??
Stack Trace:
msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x017ab278, const
wchar_t * file=0x0178, unsigned int line=304) Line 24C++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator==(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 304 + 0x17 bytesC++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator!=(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 316 + 0xc bytesC++
osg55-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1746 + 0x33
bytesC++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1368C++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1252C++
osg55-osgd.dll!osg::Drawable::draw(osg::RenderInfo renderInfo={...})
Line 898 + 0x13 bytesC++
osg55-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 60 + 0x19
bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 419 +
0x19 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 469 +
0x35 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line
1253C++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8, bool
doCopyTexture=false) Line 848C++
osg55-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 1108 +
0x1b bytesC++
osg55-osgUtild.dll!osgUtil::SceneView::draw() Line 1540 + 0x37
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::draw() Line 451 + 0xf
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 693 + 0xf bytesC++
osg55-osgd.dll!osg::GraphicsContext::runOperations() Line 688 + 0x33
bytesC++
osg55-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 135C++
osg55-osgd.dll!osg::GraphicsOperation::operator()(osg::Object *
object=0x0277fb30) Line 50 + 0x19 bytesC++
osg55-osgd.dll!osg::OperationThread::run() Line 413 + 0x26 bytes
C++
osg55-osgd.dll!osg::GraphicsThread::run() Line 40C++
ot11-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void *
data=0x026f82ac) Line 116 + 0xf bytesC++
msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytesC
msvcr90d.dll!_threadstartex(void * ptd=0x026f9830) Line 331C
kernel32.dll!7c80b713()
- Donny
On Mon, Feb 2, 2009 at 9:01 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi All,
I've now finished all the merges/bug/features fixes that is required
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Donald,
This looks to be a threading issue with the text label being updated
while being rendered.
There was no text-setDataVariance(DYNAMIC) so I've added this, and
checked this change into svn/trunk. Could you please test. Modified
osgtexture2D.cpp also attached.
Robert.
On Tue, Feb 3, 2009 at 12:35 PM, Donald Cipperly osgc...@gmail.com wrote:
Building on Windows XP, Visual Studio 2008 sp1. All builds fine, but
getting same warnings as Sukender (haven't tried your latest updates
Robert...about to rebuild with latest revision).
Examples run good except getting crash in osgTexture2D with a map/set
iterator not incrementable error. This error goes away if I add
viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded ); to the
example...maybe thread safety issue with incrementing _currPos??
Stack Trace:
msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x017ab278, const
wchar_t * file=0x0178, unsigned int line=304) Line 24C++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator==(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 304 + 0x17 bytesC++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator!=(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 316 + 0xc bytesC++
osg55-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1746 + 0x33
bytesC++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1368C++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1252C++
osg55-osgd.dll!osg::Drawable::draw(osg::RenderInfo renderInfo={...})
Line 898 + 0x13 bytesC++
osg55-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 60 + 0x19
bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 419 +
0x19 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 469 +
0x35 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line
1253C++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8, bool
doCopyTexture=false) Line 848C++
osg55-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 1108 +
0x1b bytesC++
osg55-osgUtild.dll!osgUtil::SceneView::draw() Line 1540 + 0x37
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::draw() Line 451 + 0xf
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 693 + 0xf bytesC++
osg55-osgd.dll!osg::GraphicsContext::runOperations() Line 688 + 0x33
bytesC++
osg55-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 135C++
osg55-osgd.dll!osg::GraphicsOperation::operator()(osg::Object *
object=0x0277fb30) Line 50 + 0x19 bytesC++
osg55-osgd.dll!osg::OperationThread::run() Line 413 + 0x26 bytes
C++
osg55-osgd.dll!osg::GraphicsThread::run() Line 40C++
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Five min. ago trunk works on Suse 10.3, but if I use --QOSGWidget a vertical black band appears on the right side of the window. No black band if I omit --QOSGWidget Hope it helps mario Morné Pistorius wrote: Hi Robert, I first posted about these problems in the Test 2.8 thread. I still see two problems in the osgviewerQt example and managed to reproduce both in the attached modified file. 1. Unable to spin/throw a model using QOSGWidget as a viewer. 2. viewer-addView doesn't work if the composite viewer is empty and trying to add a new view at runtime. These problems can be reproduced with the following command line (and the above modified file): osgviewerQt cessna.osg --QOSGWidget --CompositeViewer Apart from this issue, 2.8 works fine in my application. Thanks for all the effort you put into OSG, it really is an excellent library! Cheers, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Data Analysis Group | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Mario, On Tue, Feb 3, 2009 at 12:45 PM, Mario Valle mva...@cscs.ch wrote: Five min. ago trunk works on Suse 10.3, but if I use --QOSGWidget a vertical black band appears on the right side of the window. No black band if I omit --QOSGWidget How big is the black band? This suggests that the window sizes are wrong. I don't see the black band, with kubuntu 8.10, for qt version I get: pkg-config QtCore --modversion 4.4.3 What version of Qt are you using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender,
If we can't work out what it's on a bout and the warning looks benign,
should we just suppress it?
Robert.
On Tue, Feb 3, 2009 at 1:56 PM, Sukender suky0...@free.fr wrote:
Hi Robert,
Not many ideas, but:
- This may be related to the IC class used at this moment. Unfortunately,
there is no clue in the log about which IC causes it, except it's in osgDB
wrapper. So this may be the DatabasePager. Perhaps is it linked to:
I_StaticMethod0(osgDB::DatabasePager *, create,
__DatabasePager_P1__create_S,
create a DatabasePager by cloning
DatabasePager::prototype(). ,
);
in DatabasePager.cpp?
- Could this be related to the fact that ConstructorInfo is private
inheritance? I guess no, but...
- Just for info, the help says VC generates 4702 when a catch() block cannot
be reached (when functions called in try() are all C, because extern C
functions are assumed to not throw).
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 14:32:59 +0100, Robert Osfield robert.osfi...@gmail.com
a écrit:
Hi All,
I'm look at the follow warning under Windows. I can't figure out why
there is a warning of this type:
152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36)
: warning C4702: unreachable code
The code is:
templatetypename C, typename IC
struct TypedConstructorInfo0: ConstructorInfo
{
TypedConstructorInfo0(const ParameterInfoList plist,
std::string briefHelp = std::string(), std::string detailedHelp =
std::string())
:ConstructorInfo(typeof(C), plist, briefHelp, detailedHelp)
{
}
Value createInstance(ValueList /*args*/) const
{
return IC::create();
} This is line 36 for which the warning is being emited.
};
The offending line is overriding a virtual createInstance(ValueList)
const method from the ConstructorInfo base class. This usage pattern
is also used in the many other template classes in
include/osgIntrospection/TypedConstructorInfo but none generate
warnings...
Strange, any chance that someone can shine some light on this warning?
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] OsgManipulator Dragger Matrix
Hum, sorry I was not really awoken ... I was modifying the wrong matrix. Dragger get its own matrix for the geometry, Selection is the Matrix which modify the dragged node. Sorry for the inconvenience, Regards, Vincent. 2009/2/3 Vincent Bourdier vincent.bourd...@gmail.com Hi all, I'm currently working a code to save/load a Dragger just with text datas. So I know its position, children, ... and I save its Matrix rotation (Quat) to load the exact position of the dragged node. But when I set the matrix of the dragger on loading, the node under Dragger seems to be unmodified. To be clear : I have a node along Z axis (cylinder) and its parent is a cylinder Dragger along Y (Y is axis of rotation). When I use the dragger, the cylinder rotate as requested. I get the Dragger's matrix rotation in a quat and save it. When I want to make the dragger on loading, I create all my scene graph, get the dragger and set its matrix like is was using the Quat. But the node under the dragger seems not rotated... I assume that the Dragger children are transformated only during a Drag event... isn't it ? Is there a way to set a dragger in the state it was, without having to save the scenegraph, but just using the datas ? (position, rotation, ...) Thanks for you help, Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, hi all,
const T *v: When T is a function, I guess the compiler reads pointer to a
const function instead of const pointer to a function. Thus the const
applied on a function has no meaning. I don't know, however, how to avoid this,
since const (T *) v will result in a parse error.
Any idea?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 14:41:21 +0100, Robert Osfield robert.osfi...@gmail.com a
écrit:
Hi All,
I can't quite fathom the following warning either...
164..\..\include\osgIntrospection/Value(373) : warning C4180:
qualifier applied to function type has no meaning; ignored
164..\..\include\osgIntrospection/TypedMethodInfo(84) : see
reference to function template instantiation
'osgIntrospection::Value::Valuebool(osg::Object ,osgDB::Input )(T
(__cdecl *))' being compiled
164with
164[
164T=bool (osg::Object ,osgDB::Input )
164]
164..\..\include\osgIntrospection/TypedMethodInfo(77) : while
compiling class template member function 'osgIntrospection::Value
osgIntrospection::TypedMethodInfo0C,R::invoke(const
osgIntrospection::Value ,osgIntrospection::ValueList ) const'
164with
164[
164C=osgDB::DotOsgWrapper,
164R=osgDB::DotOsgWrapper::ReadFunc
164]
164.\osgDB\DotOsgWrapper.cpp(58) : see reference to class
template instantiation 'osgIntrospection::TypedMethodInfo0C,R' being
compiled
164with
164[
164C=osgDB::DotOsgWrapper,
164R=osgDB::DotOsgWrapper::ReadFunc
164]
templatetypename T Value::Value(const T *v)
{
_inbox = new Ptr_instance_boxconst T *(v);This is
line 373, which generates the warning
_type = _inbox-type();
_ptype = _inbox-ptype();
}
I have other stuff to chase up so I'll leave this is the hands of
those more community to see if they figure it out and suggest a way to
resolve the problem.
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] Blender osgAnimation Issue
On Mon, 2009-02-02 at 22:46 -0800, Ryan Morris wrote: Cedric, Thanks for taking the time to look into this. I did have a revelation a few days ago that lead me to the same conclusion. Basically I had to go back and assign vertices to the named vgroups. not a big deal once I figured it out I was just going crazy thinking I was doing something completely wrong. I figured the exporter should recognize this but it works perfectly if I do the following: -select a vgroup -select the vertices I want in the group -click the assign button I had no idea this WASN'T the way to do it--I'm surprised Blender supports another method. that seemed to fix my issues. Again thanks Cedric for all your help and hard work! -Russ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Morne, On Tue, Feb 3, 2009 at 2:54 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, I think in VS, specifiying something as just unsigned causes the compiler to read unsigned int. If you change the line to return static_castunsigned long const volatile (_value); I think the warning will disappear. This will just then invoke an implicit case from unsigned long to unsigned int, it's better to keep the cast explict. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Sukender wrote: Hi Robert, hi all, const T *v: When T is a function, I guess the compiler reads pointer to a const function instead of const pointer to a function. Thus the const applied on a function has no meaning. I don't know, however, how to avoid this, since const (T *) v will result in a parse error. I don't think you can avoid it, as it seems that the Value constructor in question (Value::Value(const T* v)) is used when T is a function type. The different variations of it (const T* v, T* v, const T v) make sense in general, just not all for a function type. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, After the last discussion on this topic I end up leaning towards not using svn for binaries. The server supports webdav as well as ftp. I'll go an experiment with these routes and report back. OK, let me know. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
HI Window dev's, I've now checked in fixes for the majority of the warnings that Sukender reported, there are a few left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) : warning C4702: unreachable code For the first of these it looks like the should be removed. For the GLUT one, this is a header issue, nothing to do with our code so the only avenue is to ignore or suppress it. The last two errors generated in osgIntrospection look to me like pretty unhelpful warnings, and neither look to be ones that point to a problem that needs to be solved code wise, so I'm inclined to suppress it. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Robert,
That did indeed fix the issue.
Thanks,
Donny
On Tue, Feb 3, 2009 at 6:43 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Donald,
This looks to be a threading issue with the text label being updated
while being rendered.
There was no text-setDataVariance(DYNAMIC) so I've added this, and
checked this change into svn/trunk. Could you please test. Modified
osgtexture2D.cpp also attached.
Robert.
On Tue, Feb 3, 2009 at 12:35 PM, Donald Cipperly osgc...@gmail.com
wrote:
Building on Windows XP, Visual Studio 2008 sp1. All builds fine, but
getting same warnings as Sukender (haven't tried your latest updates
Robert...about to rebuild with latest revision).
Examples run good except getting crash in osgTexture2D with a map/set
iterator not incrementable error. This error goes away if I add
viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded ); to the
example...maybe thread safety issue with incrementing _currPos??
Stack Trace:
msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x017ab278,
const
wchar_t * file=0x0178, unsigned int line=304) Line 24C++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator==(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 304 + 0x17 bytesC++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator!=(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 316 + 0xc bytesC++
osg55-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1746 + 0x33
bytesC++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1368C++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1252C++
osg55-osgd.dll!osg::Drawable::draw(osg::RenderInfo
renderInfo={...})
Line 898 + 0x13 bytesC++
osg55-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 60 +
0x19
bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 419
+
0x19 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384
+
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 469
+
0x35 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line
1253C++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384
+
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8, bool
doCopyTexture=false) Line 848C++
osg55-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 1108
+
0x1b bytesC++
osg55-osgUtild.dll!osgUtil::SceneView::draw() Line 1540 + 0x37
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::draw() Line 451 + 0xf
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext
*
context=0x0277fb30) Line 693 + 0xf bytesC++
osg55-osgd.dll!osg::GraphicsContext::runOperations() Line 688 +
0x33
bytesC++
osg55-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 135C++
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hello Morné, Sorry, not enough info :) Pressing 'a' will add a view, 'r' will remove it. It works as expected until the last view is removed. Another way to see it is to construct the composite viewer without adding any views at compile time, and then trying to add one pressing 'a' at runtime. We're doing something similar to this (as you might have seen in previous discussions about CompositeViewer::addView() in the past month or so). There's one major difference though, we create a new GraphicsWindow for each view (because we want Qt to manage the split between windows, and we want each window to be undockable). For us it works well, and it should for you too. Just so you know, we're using Qt 4.4.x on Windows. I've tested your example, and I see the two issues you do: - The trackball manipulator does not throw (since Robert does not see this we can assume this is a Windows-specific problem, either caused by Qt on Windows or GraphicsWindowWin32's event handling) - When there are no views in the CompositeViewer (either because none were added at startup, or because all existing views were removed with 'r') then adding views doesn't have any visible effect (the window contains either what it contained when the last view was removed, or if you put another window over it then it doesn't repaint). I'm looking into this to see if I can find out what we're doing differently (other than a different graphics context for each view) that could fix your issues. I've tried some things (realizing the viewer, stopping/starting threading manually, etc.) but nothing has worked yet. I'll be checking this on my off time between other tasks though, so you might have to wait a day or two until I've had enough total time to work on it. I'll get back to you soon. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi again Morné,
- The trackball manipulator does not throw (since Robert does not see
this we can assume this is a Windows-specific problem, either caused by
Qt on Windows or GraphicsWindowWin32's event handling)
I've found out why this is. Since QOSGWidget uses GraphicsWindowWin32
directly, the graphics window already sends mouse events to the event
queue. So in QOSGWidget::mouse*Event (Press, DoubleClick, Release,
Move), you don't want to call _gw-getEventQueue()-mouseButton*()
because then it means that the same event is sent twice. This has the
effect that if two release events are received by the
TrackballManipulator, it stops the throw since the mouse speed when it
gets the second release is 0.
I would still send the events to QWidget though, just to be sure, so I
would replace those methods by:
void QOSGWidget::mousePressEvent( QMouseEvent* event )
{
QWidget::mousePressEvent(event);
}
(or just not override them) and so on for all other event methods. The
actual event will be put in the event queue in
GraphicsWindowWin32::handleNativeWindowingEvent().
In our project, we had run into the same problem, but we resolved it
differently. We subclassed GraphicsWindowWin32 to ignore all events, and
instead add them in the event queue in the overridden QOSGWidget
methods. I don't remember why we did it this way, but I think the above
is more general, in addition to not requiring a subclass.
I'm still looking for the cause/solution to the addView() problem.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hi Ulrich, thanks for answering too :) Hi Davide, (...) That could be your problem right there... especially when you're using lots of textures, shaders(!) and such. I think I'm doing something wrong or missing some important call while setting up the application. Or more probably misinterpreting the results. I was not using textures or shaders; the scene I was representing contains only 20 cubes and 20 spheres. What kind of setups are you comparing it against? I compared a Macbook core2Duo 2GHz, intel graphics with a dell dimension laptop, pentium 4 2.0GHz and nvidia graphics. What it is feeling strange to me is that there is almost no difference in performances if I use GLUT (like in the osgviewerGLUT example) but a huge difference if I use the plain osgviewer class (like in the osgviewer example) I'm setting up a very simple example to try to reproduce the problem with a single file, I will post it tomorrow morning as soon as I can access a windows machine Thanks!!Davide ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Tue, Feb 3, 2009 at 10:41 AM, Tony Horrobin a.j.horro...@its.leeds.ac.uk wrote: I believe it is due to virtual inheritence of Object as in CullCallback - NodeCallback - Object. Ahh... good clue... I've added an explicit initialization of the osg::Object and checked it in, fingers crossed it'll fix the warning. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Guys, Since I've had no feedback on the remaining WIndows warnings I've gone ahead and added pragma's to suppress the following warnings that seemed to be appropriate for supression given that fixes aren't possible/don't look easily resolvable, and the warnings don't point to a real problem in the code either. 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) warning C4702: unreachable code An svn update should fix these warnings. In case of osgIntrospection I've added the warning disable pragma's to the include/osgIntrospection/Export rather each header as doing so ended up many lines of coding for just a single warning disable, not good news when each code change comes with a potential from introducing typo's + associated build/runtime problems. This leaves one warning left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' For this I think the proper solution is to remove the . Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in 2.7.9 with collada
Hi All, I'm working under ubuntu 8.04 Hardy. I've just installed the OSG 2.7.9 version. Unfortunately i've a problem with a collada scene, no textures are loaded. With the 2.6.1 version it was ok. I use the collada dom 2.0 version. Could someone give me a fix for that problem ? Thanks Patrice ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Morne, On Tue, Feb 3, 2009 at 10:50 AM, Morné Pistorius mpistorius@googlemail.com wrote: I first posted about these problems in the Test 2.8 thread. I still see two problems in the osgviewerQt example and managed to reproduce both in the attached modified file. I've just downloaded and tested your modified file. 1. Unable to spin/throw a model using QOSGWidget as a viewer. For me at least, the spinning and throwing works for both of the cessna models. What platform and Qt version are you working with? 2. viewer-addView doesn't work if the composite viewer is empty and trying to add a new view at runtime. How do I reproduce this problem? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Robert, Removing the generates another warning: warning C4197: 'volatile const unsigned int' : top-level volatile in cast is ignoredc:\OpenSceneGraphSVN\src\OpenThreads\common\Atomic.cpp133 OpenThreads However, changing line 133 to just return _value; generates no warnings on Visual Studio 2008 sp1. I also see these warnings: warning C4701: potentially uninitialized local variable 'qu' used c:\openscenegraphsvn\src\osg\matrixdecomposition.cpp281osg warning C4512: 'CopyPointsToVertexArrayVisitor' : assignment operator could not be generatedc:\OpenSceneGraphSVN\src\osgUtil\Simplifier.cpp 1654osgUtil - Donny On Tue, Feb 3, 2009 at 10:44 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Guys, Since I've had no feedback on the remaining WIndows warnings I've gone ahead and added pragma's to suppress the following warnings that seemed to be appropriate for supression given that fixes aren't possible/don't look easily resolvable, and the warnings don't point to a real problem in the code either. 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) warning C4702: unreachable code An svn update should fix these warnings. In case of osgIntrospection I've added the warning disable pragma's to the include/osgIntrospection/Export rather each header as doing so ended up many lines of coding for just a single warning disable, not good news when each code change comes with a potential from introducing typo's + associated build/runtime problems. This leaves one warning left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' For this I think the proper solution is to remove the . Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Resolving CDash errors/warning
Hi OSG build/CDash contributors!! I am am poised to make the OpenSceneGraph-2.8 and the first 2.8.0-rc1 but.. I don't want to do it when there are known build problems lurking, otherwise we'll just have to go for another rc2 right away after rc1 - we should at least get rc1 is a state that is good to try out as a proper release candidate. So... looking at CDash we have: http://www.cdash.org/CDashPublic/index.php?project=OpenSceneGraph There are couple of reds (errors) and oranges (warnings) on the board... The warnings should have been dealt with by my work today, so an svn update and rebuild should tells us how I've done on that score. This leaves the reds left to resolve. I believe these are CMake configuration issues rather than code issues, resolving these may need tweak in the CMake build system, or perhaps just the local environment of the build being fixed. To help fix these I need to coordinate with those doing the builds, so please step forward and discuss if you are one of the ones with a broken build. There are two builds that have failed, the first is a mingw build, and related to an issue finding the rsvg-2 library, which suggests a path or CMake variable problem mingw-cross.office.jester http://www.cdash.org/CDashPublic/buildSummary.php?buildid=8534 To resolve this I think we'll need to have a look at the OpenSceneGraph/CMakeCache.txt. Could the person responsible for this build please post this into osg-users or send it to me directly. The second problem looks to be a CMake/GDAL configuration issue, or perhaps just a problem with something odd happending with GLU: dhcp17.weatherone.int http://www.cdash.org/CDashPublic/buildSummary.php?buildid=8614 The errors here are quite odd. It makes me wonder if OpenGL hasn't been installed incorrectly, or that CMake is screwing up in some way. What version of CMake is being used here? Which version of GDAL? Which version of OpenGL? How was it installed? Are their multiple versions of OpenGL installed? Unfortunately I can't do anything about these problems without help from those kicking off these builds. I would very much like to see them resolved, or confirmed that they aren't related to issues with the OSG source code/build system itself, as I'm currently holding back making the OpenSceneGraph-2.8 branch to make sure that all resolvable build problems are solved before we attempt an rc1. Thanks in advance for your help, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi J-S,
Thank you so much for the help, much appreciated. I downloaded and
built Qt 4.4.3 today, thinking it might have been a Qt problem, since
I was using an older version than Robert.
I will replace the event methods with your suggestion.
W.r.t the composite viewer, I would really rather use it with multiple
views in single context. In our application, these tiled views could
be very many at once and I think context switching between all of them
would be bad for performance.
Again, I appreciate your help looking into this!
Thanks,
Morné
On Tue, Feb 3, 2009 at 4:21 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hi again Morné,
- The trackball manipulator does not throw (since Robert does not see this
we can assume this is a Windows-specific problem, either caused by Qt on
Windows or GraphicsWindowWin32's event handling)
I've found out why this is. Since QOSGWidget uses GraphicsWindowWin32
directly, the graphics window already sends mouse events to the event queue.
So in QOSGWidget::mouse*Event (Press, DoubleClick, Release, Move), you don't
want to call _gw-getEventQueue()-mouseButton*() because then it means that
the same event is sent twice. This has the effect that if two release events
are received by the TrackballManipulator, it stops the throw since the mouse
speed when it gets the second release is 0.
I would still send the events to QWidget though, just to be sure, so I would
replace those methods by:
void QOSGWidget::mousePressEvent( QMouseEvent* event )
{
QWidget::mousePressEvent(event);
}
(or just not override them) and so on for all other event methods. The
actual event will be put in the event queue in
GraphicsWindowWin32::handleNativeWindowingEvent().
In our project, we had run into the same problem, but we resolved it
differently. We subclassed GraphicsWindowWin32 to ignore all events, and
instead add them in the event queue in the overridden QOSGWidget methods. I
don't remember why we did it this way, but I think the above is more
general, in addition to not requiring a subclass.
I'm still looking for the cause/solution to the addView() problem.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Donald, On Tue, Feb 3, 2009 at 5:03 PM, Donald Cipperly osgc...@gmail.com wrote: Removing the generates another warning: warning C4197: 'volatile const unsigned int' : top-level volatile in cast is ignoredc:\OpenSceneGraphSVN\src\OpenThreads\common\Atomic.cpp133 OpenThreads However, changing line 133 to just return _value; Tempting to go with this, but there must have been a motivation for the use of volatile here. I'll track down the original author. generates no warnings on Visual Studio 2008 sp1. I also see these warnings: warning C4701: potentially uninitialized local variable 'qu' used c:\openscenegraphsvn\src\osg\matrixdecomposition.cpp281osg warning C4512: 'CopyPointsToVertexArrayVisitor' : assignment operator could not be generatedc:\OpenSceneGraphSVN\src\osgUtil\Simplifier.cpp 1654osgUtil I've just checked in fixes for these, could you do an svn update and let me know how things build. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hello Morné, W.r.t the composite viewer, I would really rather use it with multiple views in single context. In our application, these tiled views could be very many at once and I think context switching between all of them would be bad for performance. Oh, I was not suggesting you do it the same way as we do... We do it that way for specific reasons which you might not share. It's a case of doing it the right way for your own project - both ways should work. Still looking, but I'm running out of options... I'll get back to you. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Robert, I set up a simple test, with only a rotating cube displayed with: 1) osgviewer using GLUT 2) osgviewer standalone class in both I used double-buffered 800x600 window. I only tested on my mac yet, but tomorrow I will test on windows too. The results are: ** standalone ** cpu time: 1001.35 milliseconds effective time: 16.796 seconds average fps: 59.538 ** using glut ** cpu time: 458.949 milliseconds effective time: 2.71029 seconds average fps: 368.964 I think that you were right and I was misinterpreting the results: it is evident that the standalone osgviewer version is fixed on 60Hz, which is my laptop display refresh rate. The glut version seems not to be bound to the display refresh but the doublebuffering is enabled... Probably there is something I still ignore just under the hood, on how the refresh is handled. The same difference appears with the standard osgviewer and osgviewerGLUT applications built with cmake (in both 2.4.0 and 2.6.0) Tomorrow I will try on windows, with the same code. For what I observed, I expect to have a fps higher to 60Hz there, I will let you know. Just in case, is it possible to attach the testcase to a message directed to the mailing list? thanks! Message: 8 Date: Tue, 3 Feb 2009 11:09:12 + From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] OSX issue with the osgviewer class To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 7ffb8e9b0902030309g7ed6464cjca4962cb51186...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Davide, On Tue, Feb 3, 2009 at 9:57 AM, Davide Bacchet davide.bacc...@gmail.com wrote: I compared a Macbook core2Duo 2GHz, intel graphics with a dell dimension laptop, pentium 4 2.0GHz and nvidia graphics. What it is feeling strange to me is that there is almost no difference in performances if I use GLUT (like in the osgviewerGLUT example) but a huge difference if I use the plain osgviewer class (like in the osgviewer example) I'm setting up a very simple example to try to reproduce the problem with a single file, I will post it tomorrow morning as soon as I can access a windows machine There shouldn't be a performance difference between osgviewerGLUT and osgviewer like your seeing, rather if you see a performance difference it should be that the standard viewer should be faster as multi-threading should be use. For such a small difference it'd a small difference, but it should be there. The fact that you aren't see a performance improvement, rather than opposite suggets to me that the OpenGL driver/Carbon is not creating a properly accelerated graphics context, and may well be dropping down to software rendering. It shouldn't be doing this, but it's the only thing I can think of that might explain this pattern. I've used quite a few macs over the years, including a brief look at using a Mac mini that had Intel graphics and it worked OK with the standard osgviewer. Fill rate was very poor, but it was still able to do the cow.osg at 60Hz. None of my previous Mac experience has seen a drop down to software rendering though. One test it would be worth doing is resizing the window to see if this affects performance, if it does then this scream out that the graphics context is being done on the CPU. BTW, do you see performance issues with osgviewer cow.osg? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All,
I can't quite fathom the following warning either...
164..\..\include\osgIntrospection/Value(373) : warning C4180:
qualifier applied to function type has no meaning; ignored
164..\..\include\osgIntrospection/TypedMethodInfo(84) : see
reference to function template instantiation
'osgIntrospection::Value::Valuebool(osg::Object ,osgDB::Input )(T
(__cdecl *))' being compiled
164with
164[
164T=bool (osg::Object ,osgDB::Input )
164]
164..\..\include\osgIntrospection/TypedMethodInfo(77) : while
compiling class template member function 'osgIntrospection::Value
osgIntrospection::TypedMethodInfo0C,R::invoke(const
osgIntrospection::Value ,osgIntrospection::ValueList ) const'
164with
164[
164C=osgDB::DotOsgWrapper,
164R=osgDB::DotOsgWrapper::ReadFunc
164]
164.\osgDB\DotOsgWrapper.cpp(58) : see reference to class
template instantiation 'osgIntrospection::TypedMethodInfo0C,R' being
compiled
164with
164[
164C=osgDB::DotOsgWrapper,
164R=osgDB::DotOsgWrapper::ReadFunc
164]
templatetypename T Value::Value(const T *v)
{
_inbox = new Ptr_instance_boxconst T *(v);This is
line 373, which generates the warning
_type = _inbox-type();
_ptype = _inbox-ptype();
}
I have other stuff to chase up so I'll leave this is the hands of
those more community to see if they figure it out and suggest a way to
resolve the problem.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in 2.7.9 with collada
Hi Patrice, Could you post the problem model? We'll need to textures as well. Robert. On Tue, Feb 3, 2009 at 10:38 AM, Patrice Bouvier bouv...@univ-mlv.fr wrote: Hi All, I'm working under ubuntu 8.04 Hardy. I've just installed the OSG 2.7.9 version. Unfortunately i've a problem with a collada scene, no textures are loaded. With the 2.6.1 version it was ok. I use the collada dom 2.0 version. Could someone give me a fix for that problem ? Thanks Patrice ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi, I believe it is due to virtual inheritence of Object as in CullCallback - NodeCallback - Object. Cheers, -Tony [quote=Jeremy Moles]On Mon, 2009-02-02 at 17:32 +, Robert Osfield wrote: [quote]HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor The warning remains with the latest revision; osg::Object must also be initialized for this warning to go away. Why this is the case, I do not know. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5734#5734 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
The band width is proportional to the window width. It is approx. 1/5 of the client area. My Qt version: 4.3.1 Ciao! mario Robert Osfield wrote: Hi Mario, On Tue, Feb 3, 2009 at 12:45 PM, Mario Valle mva...@cscs.ch wrote: Five min. ago trunk works on Suse 10.3, but if I use --QOSGWidget a vertical black band appears on the right side of the window. No black band if I omit --QOSGWidget How big is the black band? This suggests that the window sizes are wrong. I don't see the black band, with kubuntu 8.10, for qt version I get: pkg-config QtCore --modversion 4.4.3 What version of Qt are you using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Data Analysis Group | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Ümit, There are some problem, while using osgviewer sometimes there was a Error: [Screen #0] GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers problem. And almost all examples working on my system but osgprecipictation example make my computer lock and after I run this example I get push emergency shutdown button :) Maybe because of my system's configuration. I cannot reproduce either of these two problems. Perhaps it's a driver issue on your side? I'm on Vista 32bit, nVidia 9800GTX+, driver 180.48 J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: OSG Training in Washington DC
Just another reminder about the upcoming course and special pricing that ends February 9th. Interest spiked after the courses were announced on both khronos.org and opengl.org, so please register soon to reserve space. Thanks, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Wednesday, January 21, 2009 7:14 PM To: 'OpenSceneGraph Users' Subject: [osg-users] ANN: OSG Training in Washington DC Hi all -- I'm pleased to announce that registration is now open for our next public OSG training course, to be held in Washington DC, March 9-12, 2009. To view course information and register online, please visit: http://www.skew-matrix.com/training.html http://www.skew-matrix.com/training.html Register before February 9 for all three courses and receive a $440 discount! Hope to see you in DC. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OsgManipulator Dragger Matrix
Hi all, I'm currently working a code to save/load a Dragger just with text datas. So I know its position, children, ... and I save its Matrix rotation (Quat) to load the exact position of the dragged node. But when I set the matrix of the dragger on loading, the node under Dragger seems to be unmodified. To be clear : I have a node along Z axis (cylinder) and its parent is a cylinder Dragger along Y (Y is axis of rotation). When I use the dragger, the cylinder rotate as requested. I get the Dragger's matrix rotation in a quat and save it. When I want to make the dragger on loading, I create all my scene graph, get the dragger and set its matrix like is was using the Quat. But the node under the dragger seems not rotated... I assume that the Dragger children are transformated only during a Drag event... isn't it ? Is there a way to set a dragger in the state it was, without having to save the scenegraph, but just using the datas ? (position, rotation, ...) Thanks for you help, Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Sukender wrote: Hi Robert, hi all, const T *v: When T is a function, I guess the compiler reads pointer to a const function instead of const pointer to a function. That's not specific to functions, as const C *c where C is a class means the same: c is a pointer to a const instance of C. If you want a const pointer you would have to write C *const c. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert,
Not many ideas, but:
- This may be related to the IC class used at this moment. Unfortunately,
there is no clue in the log about which IC causes it, except it's in osgDB
wrapper. So this may be the DatabasePager. Perhaps is it linked to:
I_StaticMethod0(osgDB::DatabasePager *, create,
__DatabasePager_P1__create_S,
create a DatabasePager by cloning
DatabasePager::prototype(). ,
);
in DatabasePager.cpp?
- Could this be related to the fact that ConstructorInfo is private
inheritance? I guess no, but...
- Just for info, the help says VC generates 4702 when a catch() block cannot be
reached (when functions called in try() are all C, because extern C functions
are assumed to not throw).
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 14:32:59 +0100, Robert Osfield robert.osfi...@gmail.com a
écrit:
Hi All,
I'm look at the follow warning under Windows. I can't figure out why
there is a warning of this type:
152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36)
: warning C4702: unreachable code
The code is:
templatetypename C, typename IC
struct TypedConstructorInfo0: ConstructorInfo
{
TypedConstructorInfo0(const ParameterInfoList plist,
std::string briefHelp = std::string(), std::string detailedHelp =
std::string())
:ConstructorInfo(typeof(C), plist, briefHelp, detailedHelp)
{
}
Value createInstance(ValueList /*args*/) const
{
return IC::create();
} This is line 36 for which the warning is being emited.
};
The offending line is overriding a virtual createInstance(ValueList)
const method from the ConstructorInfo base class. This usage pattern
is also used in the many other template classes in
include/osgIntrospection/TypedConstructorInfo but none generate
warnings...
Strange, any chance that someone can shine some light on this warning?
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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All,
I'm look at the follow warning under Windows. I can't figure out why
there is a warning of this type:
152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36)
: warning C4702: unreachable code
The code is:
templatetypename C, typename IC
struct TypedConstructorInfo0: ConstructorInfo
{
TypedConstructorInfo0(const ParameterInfoList plist,
std::string briefHelp = std::string(), std::string detailedHelp =
std::string())
:ConstructorInfo(typeof(C), plist, briefHelp, detailedHelp)
{
}
Value createInstance(ValueList /*args*/) const
{
return IC::create();
} This is line 36 for which the warning is being emited.
};
The offending line is overriding a virtual createInstance(ValueList)
const method from the ConstructorInfo base class. This usage pattern
is also used in the many other template classes in
include/osgIntrospection/TypedConstructorInfo but none generate
warnings...
Strange, any chance that someone can shine some light on this warning?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Robert, On Tue, Feb 3, 2009 at 11:21 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, On Tue, Feb 3, 2009 at 10:50 AM, Morné Pistorius mpistorius@googlemail.com wrote: I first posted about these problems in the Test 2.8 thread. I still see two problems in the osgviewerQt example and managed to reproduce both in the attached modified file. I've just downloaded and tested your modified file. 1. Unable to spin/throw a model using QOSGWidget as a viewer. For me at least, the spinning and throwing works for both of the cessna models. What platform and Qt version are you working with? I am on Windows Vista, using Qt 4.3.3. Do you think it is a Qt problem? When trying to debug it, I could rotate the model, but not throw it. TrackballManipulator::IsMouseMoving() always returned false on a mouse button RELEASE event. This only happens for the QOSGWidget though, I can throw it fine using the QGLWidget. 2. viewer-addView doesn't work if the composite viewer is empty and trying to add a new view at runtime. How do I reproduce this problem? Sorry, not enough info :) Pressing 'a' will add a view, 'r' will remove it. It works as expected until the last view is removed. Another way to see it is to construct the composite viewer without adding any views at compile time, and then trying to add one pressing 'a' at runtime. Cheers, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert,
I think in VS, specifiying something as just unsigned causes the
compiler to read unsigned int.
If you change the line to
return static_castunsigned long const volatile (_value);
I think the warning will disappear.
Cheers,
Morne
On Tue, Feb 3, 2009 at 2:48 PM, Robert Osfield robert.osfi...@gmail.com wrote:
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender, Could you send the file as an ascii file, just came through as binary here. W.r.t warnings, if we can't fix them easily and non-intrusively then we'll have to suppress them. Robert. On Tue, Feb 3, 2009 at 10:12 AM, Sukender suky0...@free.fr wrote: Hi Robert, As the dashboard limits the warnings to 50, I did a full rebuild of rev. 9631 (VC8sp1) for you. So attached is an archive containing: - The full log (maybe useless, but who knows?) - The warnings as a CSV file (Tab separated, '' as text separator). Enjoy these 1841 warnings... ;) Well of course, most of them can be ignored since 1738 of them are alignment of a member was sensitive to packing for introspection, and there are some assignment operator could not be generated too. Just sort by description :) Hope it helps. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:54:34 +0100, Sukender suky0...@free.fr a écrit: Hi Robert, Second experimental build launched. (SUKENDER1 2009-02-02 on the dashboard, rev 9631, VC8sp1, all inclusive). Maybe you'll have the result before going to sleep (= To all: this is a joke... Robert NEVER sleeps! :D Even kill_and_go_to_bed -9 can't get rid of him!!!) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:36:03 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender (et. al) On Mon, Feb 2, 2009 at 4:20 PM, Sukender suky0...@free.fr wrote: Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I've now gone through all the 50 warnings reported on Dashbord from your VS build, I have applied fixes for them all. Whether they are fixed or not... we I can't say till you or others do another build. I have checked my changes into svn/trunk. Since the at the end of Dashboard log there the line: The maximum number of reported warnings or errors has been reached!!! I suspect there are more warnings lurking, and even if I fix these 50, more will pop up in their place. How many we'll have to wait an see. Could everyone do another svn update on svn/trunk and build to see how things are now hanging. Posting your results on Dashboard helps me keep track of things. Thanks, 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
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Morne, I've been able to reproduce the rendering issue with CompositeViewer with no View's using your modified example, and rather than dive into QT code that I'm not so familiar with I thought I'd recreate a similar usage of CompositeViewer in the osgcompositeviewer example. I've now start coding up additions but have come unstuck in trying to work out how to create an CompositeViewer which has its own window that it renders to without there being any Camera's assigned to the viewer, as without any views you don't have any cameras, and it's the camera's that hold the references to the graphics windows, so there is no way to actually specify the type of viewer setup your propose, without changing to quite a different model. In your QT example you have a window that is created for you, and an graphics context assigned to it, then you assign this to viewer, even if you didn't assign it to a viewer you would have a window. Also if your delete all the views you'd still have the window as the window is owned by Qt rather than by the viewer. This makes the set up quite different than a standard osgViewer based viewer that owns everything. The way to replicate the QT viewer setup would be to keep a reference to the GraphicsWindow in the application main loop, so that even when you remove all the views you still keep the window alive. Once all the views were removed the viewer itself wouldn't know about the GraphicsWindow so it wouldn't be able to do any. This would mean that the application main loop would need to step in an do it's own clear and swap buffers on the GraphicsWindow while the viewer was inactive without a view to render. I guess a similar viewer.frame() by pass could be done in the QT case for when the viewer has no views. The other approach might be to create an empty View that does nothing, has no scene, but at least has a Camera with the GraphicsWindow assigned to it. It's viewport could be zero sized so would be litte more than a non op, and you have have the GraphicsWindow do the clear each frame for you. This approach why a bit inelegant would probably prevent the problems you are seeing, and would just require an additionally couple of lines of set up code at the creation time, thereafter you'd just ignore this extra View. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Resolving CDash errors/warning
Hi Robert, I just added a nightly build scheduled task on my machine, and ran it a few times to see how it ran. You can see WHITESTAR is me. (incidentally, I changed my site name to WHITESTAR_jean-sebastien_guay at one time, but didn't change it the next time - anyone know how to remove an unused entry in the CDash page? :-) ) It seems to me that using /build will not really be useful to track warnings, since only changed .cpp files and files that depend on changed headers will be recompiled each time, so getting 0 warnings doesn't mean there are 0 warnings in the whole build, just in the subset of files compiled. I tried using /rebuild, but that seems to only rebuild the CMake configuration, not the individual projects (the WHITESTAR_jean-sebastien_guay build was done with /rebuild, and you can see that only one file was compiled if you look at the build log). So using devenv OpenSceneGraph.sln /rebuild Release /project Nightly doesn't seem to work as expected. I used /build and instead deleted my build directory's contents in order to rebuild everything. Perhaps I'm doing something wrong. Anyways, I'm on board, so we'll see how it goes. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, I'm still waiting on feedback from a few emails regarding failed builds reported on CDash, and email from Mathias Froehlich on the Atomic.cpp volatile related warning, but as it's into the evening here at the westerly end of Europe I'd guess we won't get a reply tonight. I could press ahead and make the branch, but right now I'd rather wait till the morning. This gives you all a chance to do some more testing of svn/trunk :-) As long as there are no show stoppers reported overnight I'll press ahead with the OpenSceneGraph-2.8 branch + 2.8.0-rc1 tomorrow morning. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Sukender wrote:
Hi Robert, hi all,
const T *v: When T is a function, I guess the compiler reads pointer to a
const function instead of const pointer to a function.
That's not specific to functions, as const C *c where C is a class
means the same: c is a pointer to a const instance of C. If you want a
const pointer you would have to write C *const c.
Paul
Hi Robert and Paul,
Yes, that sounds logical when T is a class to give the const object
pointer/reference method. However, it's useless for functions. Actually, the
code would look like:
#if T is a not a function
Value::Value(const T *v) { ... }
#endif
Of course, we can't do *that* simple. If the whole Value class was templated,
we could partially specialize the templated class (= removing the
Value::Value(const T *v) definition in the specialization when T is a
function). But this is not the case.
May we use something similar to boost::add_const type traits then? Something
that adds a const only if possible:
templatetypename T Value(add_constT::type *v);
But I don't understand one point with functions: why don't the compiler
complain about having twice the same constructor then, since we have
Value::Value(const T *v) and Value::Value(T *v), and that the const is
ignored?
If the last point is not a problem, then I suggest we use an add_const-like
solution.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
My mistake, I meant that the volatile and should be removed (not the
whole static_cast).
May static_castunsigned int do it? (since I'm not certain volatile here is
useful, because we simply return a copy).
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 22:28:26 +0100, Sukender suky0...@free.fr a écrit:
I don't even understand the reason of the static_cast... why it is there?
IMHO, it should be removed, but I'm no Atomic/Threads/etc expert.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 15:48:03 +0100, Robert Osfield robert.osfi...@gmail.com
a écrit:
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Sorry about not anwsering sooner, but I was very busy this late afternoon. I sum up: About the #1 and #3 warnings (C4239 nonstandard extension, and C4180), I suggested in previous posts static_castunsigned int and an add_const-like solution... does it make sense for you? About C4702 unreachable code, well, I'm really stuck. I told this may be from DatabasePager, but I don't have more clues. ... And sorry about not having much time to test these solutions... maybe later... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Tue, 03 Feb 2009 16:28:04 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: HI Window dev's, I've now checked in fixes for the majority of the warnings that Sukender reported, there are a few left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) : warning C4702: unreachable code For the first of these it looks like the should be removed. For the GLUT one, this is a header issue, nothing to do with our code so the only avenue is to ignore or suppress it. The last two errors generated in osgIntrospection look to me like pretty unhelpful warnings, and neither look to be ones that point to a problem that needs to be solved code wise, so I'm inclined to suppress it. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] modelling geodes with children?
Use Group nodes. One child is a Geode for the handlebars, the other children are the attachments. This doesn't seem clumsy to me, this seems clean and straightforward. If you want to derive your own class from Group that has a built-in Geode member variable, this is also an option, and useful in some cases. For example, I have a HandNode that derives from Transform and displays an articulatable hand model. The hand is a scene graph that is owned by the HandNode, but not exposed other than via an interface for articulating the fingers. Because HandNode is a Transform, you can add children, which are then transformed as the hand is transformed (position and orientation in space), useful for adding a text label or debugging/visualization aids. Traversing both the hand subgraph and the actual children is handled by overriding the traverse() method. However, I'd never do something like this for the general-purpose case you describe with the handlebars and attachments; just use off-the-shelf OSG for that and save yourself a code maintenance headache. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cory Riddell Sent: Tuesday, February 03, 2009 1:09 PM To: OpenSceneGraph Users Subject: [osg-users] modelling geodes with children? I'm looking for advice on typical patterns when modeling something that has attachments (which may in turn have other attachments). I first looked for a node type that was a composition of Geode and Group but of course I didn't find anything. An example might help here. Say I want to model bicycle handlebars. Attached to the handlebar are grips, a light, and a bell. Attached to the grips are streamers. So, the handlebars have geometry and has children (grips, light, and bell). The light and bell have geometry, but no children. The grips though, have geometry and a child (the streamers). The streamers have geometry only. How could I model this? I thought about using a group node for any item that has both a geometry and children, but that seems clumsy (see the attached pic). I have a feeling that there is a simple solution that I'm just not seeing here. Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] modelling geodes with children?
Are you suggesting that my root would be a group node and under that would be all the leaf nodes? I don't like that idea because it loses the hierarchy: streamer is attached to grip, grip is attached to handlebar. If I delete the grip node, the streamer should go away as well. Your HandNode example is very similar to what I'm talking about. The streamer location is relative to the grip. If the grip is moved, the streamer should maintain is relative position. In my original picture, I think all the group nodes are actually transform nodes. It seems like I really do want a Group node with geometry. I guess my choices are to do something like your HandNode (probably using object composition rather than inheritance) or pair every Geode with a Group node. Cory On Tue, Feb 3, 2009 at 3:46 PM, Paul Martz pma...@skew-matrix.com wrote: Use Group nodes. One child is a Geode for the handlebars, the other children are the attachments. This doesn't seem clumsy to me, this seems clean and straightforward. If you want to derive your own class from Group that has a built-in Geode member variable, this is also an option, and useful in some cases. For example, I have a HandNode that derives from Transform and displays an articulatable hand model. The hand is a scene graph that is owned by the HandNode, but not exposed other than via an interface for articulating the fingers. Because HandNode is a Transform, you can add children, which are then transformed as the hand is transformed (position and orientation in space), useful for adding a text label or debugging/visualization aids. Traversing both the hand subgraph and the actual children is handled by overriding the traverse() method. However, I'd never do something like this for the general-purpose case you describe with the handlebars and attachments; just use off-the-shelf OSG for that and save yourself a code maintenance headache. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com +1 303 859 9466 -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Cory Riddell *Sent:* Tuesday, February 03, 2009 1:09 PM *To:* OpenSceneGraph Users *Subject:* [osg-users] modelling geodes with children? I'm looking for advice on typical patterns when modeling something that has attachments (which may in turn have other attachments). I first looked for a node type that was a composition of Geode and Group but of course I didn't find anything. An example might help here. Say I want to model bicycle handlebars. Attached to the handlebar are grips, a light, and a bell. Attached to the grips are streamers. So, the handlebars have geometry and has children (grips, light, and bell). The light and bell have geometry, but no children. The grips though, have geometry and a child (the streamers). The streamers have geometry only. How could I model this? I thought about using a group node for any item that has both a geometry and children, but that seems clumsy (see the attached pic). I have a feeling that there is a simple solution that I'm just not seeing here. Cory ___ 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] modelling geodes with children?
Hi Cory, It seems like I really do want a Group node with geometry. I guess my choices are to do something like your HandNode (probably using object composition rather than inheritance) or pair every Geode with a Group node. I think the image you sent is a logical arrangement. A Group (or a Transform) does not itself have any geometry, it just specifies how it's children are arranged (in the case of a Transform). So yes, your groups in your image would actually be Transforms, and you would have one or many Geodes under that, and also more Transforms for the sub-objects. That's a very standard scene graph structure, used all the time, and very general/flexible. A Transform does not itself have any geometry, because its job is just to transform its children (whatever those children may be). I don't know why you think it's clumsy... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] When is right time to update text on the screen
Is there a proper time to make changes to an osgText object's text? I seem to be having a problem where if I update some text in an update callback function it causes a segfault when I'm running the viewer in multi-threaded mode, but not in single threaded mode. I'm guessing because the text object is modified while is it being used by the render thread. Is there something wrong with how I am doing it? Thanks. Alex ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] modelling geodes with children?
On Tue, Feb 3, 2009 at 4:43 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: I think the image you sent is a logical arrangement. A Group (or a Transform) does not itself have any geometry, it just specifies how it's children are arranged (in the case of a Transform). So yes, your groups in your image would actually be Transforms, and you would have one or many Geodes under that, and also more Transforms for the sub-objects. That's a very standard scene graph structure, used all the time, and very general/flexible. A Transform does not itself have any geometry, because its job is just to transform its children (whatever those children may be). I don't know why you think it's clumsy... Perhaps the clumsy comment isn't fair. My first exposure to scene graphs was by reading about HOOPS and they support the idea of a geometry node having pointers to child nodes (they call them segments). You can get a pretty good idea of their model by reading this: http://developer.hoops3d.com/documentation/Hoops3DGS/prog_guide/01_2_database_dbase_structure.htmlhttp://developer.hoops3d.com/documentation/Hoops3DGS/prog_guide/01_2_database_dbase_structure.html In my mind, I'm equating the thing with the thing's geometry. And so if something is attached to the thing, I want the data structure to mimic that. Thanks for the advice. It definitely helps. Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] modelling geodes with children?
I'm looking for advice on typical patterns when modeling something that has attachments (which may in turn have other attachments). I first looked for a node type that was a composition of Geode and Group but of course I didn't find anything. An example might help here. Say I want to model bicycle handlebars. Attached to the handlebar are grips, a light, and a bell. Attached to the grips are streamers. So, the handlebars have geometry and has children (grips, light, and bell). The light and bell have geometry, but no children. The grips though, have geometry and a child (the streamers). The streamers have geometry only. How could I model this? I thought about using a group node for any item that has both a geometry and children, but that seems clumsy (see the attached pic). I have a feeling that there is a simple solution that I'm just not seeing here. Cory attachment: handlebars.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] possible bug in cfg plugin
That change seemed to fix it on my computer. Thanks. Alex -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 28, 2009 1:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] possible bug in cfg plugin Hi Alexander, I didn't see the crash (I work under Linux) but a code review of the RenderSurface constructor did reveal that it was lacking a number of member variable initializers. I have added these back including the missing _realized = false; line. These changes are now checked in. I've also attached the changed src/osgPlugins/cfgRenderSurface.cpp. Could you test and let me know if it fixes things. FYI, you don't need to svn access to check svn - you can do it all on the website - just go to Browse Source link from the front page. Our svn server also support https, there is a chance this might work for you. Robert. On Tue, Jan 27, 2009 at 11:53 PM, Pecoraro, Alexander N alexander.n.pecor...@lmco.com wrote: I noticed a bug in the 2.6.0 version of the API with the viewer config file reader plugin. I can't access the latest developer source code right now so I can't verify that the bug still exists in the 2.7 version of the API, but I've attached the config file that I used to reproduce the problem. The problem is that the plugin causes a segfault when it reads that configuration file because the _realized member variable of the RenderSurface class defined in src/osgPlugins/cfg/RenderSurface.cpp is never given an initial value. Interestingly enough this problem does not occur on my Linux box, which is running Redhat Enterprise Client 5. However, on my Windows box with Visual Studio 2005 Professional the _realized variable is auto-initialized to true which ends up causing the segfault to occur. I'm guessing, but haven't verified, that the reason it works on my Linux box is because the GCC compiler auto-initializes the variable to false which prevents the bug from occurring. Here is how I ran the osgviewer to get it to crash: osgviewer -c oneWindow.cfg name of osg file I also found that once I went into the ReaderSurface's constructor and added _realized = false; to it then the bug went away. Alex ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Morné, The other approach might be to create an empty View that does nothing, has no scene, but at least has a Camera with the GraphicsWindow assigned to it. It's viewport could be zero sized so would be litte more than a non op, and you have have the GraphicsWindow do the clear each frame for you. This approach why a bit inelegant would probably prevent the problems you are seeing, and would just require an additionally couple of lines of set up code at the creation time, thereafter you'd just ignore this extra View. Yep, in my testing what Robert suggests would work since as long as you have at least one view there is no problem. It's removing that last view and then adding others that brings up the problem. Sorry I couldn't find anything more definitive on my end. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
I don't even understand the reason of the static_cast... why it is there?
IMHO, it should be removed, but I'm no Atomic/Threads/etc expert.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 15:48:03 +0100, Robert Osfield robert.osfi...@gmail.com a
écrit:
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] When is right time to update text on the screen
I seem to have fixed the problem by setting the data variance on my osgText object to DYNAMIC. I'm wondering if this is the proper way to handle this situation though - because when I look at the StatsHandler for an example it appears to be modifying it's osgText nodes, but it does not set the data variance to DYNAMIC. Why does it work for the StatsHandler, but not for my code? Is it because the StatsHandler modifies its text during the event traversal and I modify my text during the update traversal? Should I be modifying it during event traversal only? Thanks. Alex From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Pecoraro, Alexander N Sent: Tuesday, February 03, 2009 4:26 PM To: OpenSceneGraph Users Subject: [osg-users] When is right time to update text on the screen Is there a proper time to make changes to an osgText object's text? I seem to be having a problem where if I update some text in an update callback function it causes a segfault when I'm running the viewer in multi-threaded mode, but not in single threaded mode. I'm guessing because the text object is modified while is it being used by the render thread. Is there something wrong with how I am doing it? Thanks. Alex ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Getting Started with OpenSceneGraph on Ubuntu
Hi, I am just new in Linux, and I don't know where to start. Currently I am using Ubuntu 8.10, and install osg through Synaptic package manager, and using Code::Block as a C++ IDE. Writing program in Linux is so different with in Windows, and stilll I can't have the osg HelloWorld runable. I have googled for a while but no hope. Can somebody help me with this newbie stuff, please. You may provide me how to install osg, or what IDE I should use, and how I will configure that, with detail step by step. You may give me some useful links, any help is muck appreciate. I am completely lost. Thanks in advance -- TnTonly Corporation === Home: http://www.tntonly.co.cc Mail: http://mail.tntonly.co.cc Forum: http://www.tntonly.co.cc/forum Blog: http://www.tntonly.co.cc/blog OS: http://www.tntonly.co.cc/os (Limited Service) === ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSGEarth precision
Hi, Is OSGEarth suitable to use, as a part of a terrain simulator, together with objects that needs to be positioned with about cm precision - or will I run into problems with precision? I found this page about how they handled it in NASA's World Wind: http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-precision.html How is this handled in OSGEarth? Thanks, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
