Re: [osg-users] Osgdem created terrains not displaying textures on MacOS
Thanks for the advice. Remo, it appears we are having some success with OSG 3.6.3. We still need to build and test our main project, but it looks like osgviewer is able to show both the terrain and the texture on a Mac. Chris: we were not able to immediately see anything meaningful in the OSG Notify output, but we may keep digging on that front. Your suggestion of GL debugging tools is one we had not thought of, yet. We may pursue that line of research as time permits. Thanks, again... D.J. On Wed, Oct 24, 2018 at 4:29 PM Chris Hanson wrote: > > Have you cranked up the OSG Notify level higher to see if OSG is logging any > particular OpenGL errors? > > Have you tried running it under a GL debugging tool like Nvidia's NSight > Eclipse ( https://developer.nvidia.com/nsight-eclipse-edition ) or APItrace ( > https://apitrace.github.io/ )? > > Either of those might be able to pinpoint what extension you're trying to use > that isn't working, or other OpenGL MacOS issues that are triggering the > failure. > > If you don't pin it down, email me privately and I can give you some other > suggestions. We've worked on similar tools and multiple platforms and we > should chat anyway. > > > On Wed, Oct 24, 2018 at 10:10 PM Remo Eichenberger wrote: >> >> Hi, >> >> Try to use OSG 3.6.3 with activated GLCore on MacOSX. For example: We only >> have minor issues with osgEarth on MacOSX. It works great. >> >> Cheers, >> Remo >> >> -- >> Read this topic online here: >> http://forum.openscenegraph.org/viewtopic.php?p=75120#75120 >> >> >> >> >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > -- > Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com > http://www.alphapixel.com/ > Training • Consulting • Contracting > 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • > GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL > Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • > Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • > Android > @alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] > ___ > 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] Osgdem created terrains not displaying textures on MacOS
We have run into an issue using textured terrain files under the MacOS that have been created using the osgdem utilities of Virtual Planet Builder. The terrains have been created on both Linux and the Mac directly and display OK under Linux. On the Mac we are seeing the following error when displaying the terrain file “Warning: detected OpenGL error ‘invalid operation’ at after RenderBin::draw(..)”. The terrain is displayed but no texture is displayed. We have a cross platform software system developed for solar system scale visualization of spacecraft systems that runs under Windows, Linux and Mac. The Mac port is a recent addition. We provide the ability to have terrain for planets and moons. These terrain files are working fine under Windows and Linux, but are not displaying properly (as described above) on the Mac. We are using OSG 3.4 and VPB-master as of that release. We have created terrain files on both the Linux and Mac systems with the resultant model files working on Linux, regardless of where the files were created. Neither work on Mac properly. The Mac Laptop is running 10.12.6 Sierra with a GeForce GT750M 2G graphics card. Some additional information: Other model files of all different formats seem to work fine on the Mac including ive, osgb, flt, fbx, and obj. These models display fine with their textures on the Mac. A simple test we ran was downloading the Blue Marble imagery, specifically world.topo.bathy.200410.3x5400x2700.jpg and created a whole earth model using “osgdem --terrain --geocentric --radius-polar 6371000 --radius-equator 6371000 --whole-globe -t world.topo.bathy.200410.3x5400x2700.jpg –l 4 -o wholeEarthBlueMarbleTest.ive”. This displays fine on our Linux machine but not the Mac. We created the terrain on both machines for testing purposes. We have also added the texture type options, trying compressed, rgba-compressed, rgba, rgb-16. Any insight into this problem would be appreciated. Thanks... D.J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
Paul, Have you done a search in this mailing list/forum for nvidia 275? Follow some of the threads you find, and see if any help you track down or fix your problem. Due to previous discussions on the topic, I have been careful to generally avoid this specific driver. I hope this helps... D.J. On Mon, Nov 14, 2011 at 5:08 PM, Paul Palumbo paul1...@yahoo.com wrote: dglenn wrote: Greetings! Since your so lucky to try out one of NVidea Beta Drivers, have you ran this across the NVidia test team first? Also, I didn't get what Graphics Card you are using! That is where I would go with this! OSG works on top of OpenGL other than that it is doing nothing directly with the card. If your using beta, I would look towards the fact that it may be still buggy! Also, it has been my experience with NVidia that newer drivers in Linux, don't necessary mean that it's an improvement. I have had to backtrack on drivers even on my OpenGL code stuff because Nividia broke something in the process. They are more concerned over a Windows driver than Linux I think! Sorry that's about all I can help you at this point! I was given this Beta driver by NVIDIA to fix another problem. That other problem seems to have been fixed but then two other problems showed up. One I found a work around for and this is the other. As I said in my earlier post, my Point-Of-Contact at NVIDIA seems to dismiss the new problem as an OSG problem even though the problem showup with only a drive change. I've tried new non-beta drivers and I believe I have the same problem. FYI: I'm using a Quadro 5000. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43876#43876 ___ 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] set material basic question
Hi Gianni, In addition to the combined flag, I just noticed we are also applying the material as close to the geometry as possible. Let's say you have a top level group node that is your root. The children of that group can either be geometry nodes or other groups. In our project, when applying the new material, we essentially traverse each group node in search of geometry, and then only apply the material to the geometry nodes. I would warn you that this approach probably will not work very well for level of detail nodes, since the geometry is dynamically loaded/unloaded as needed as a function of viewing distance. In that case, you should probably apply the material to the top level node returned from the geometry loader, since that node is probably the only persistent node for that geometry. This is the approach we have taken, and we just accept whatever results we get. I would have expected your original approach to work, but, since it appears that does not work, you might try something like the above approach. I would hope this would get you closer to the results you're looking for, but I can't make any guarantees. How you would implement that approach will have to be up to you, since you know your goals and your system best. I hope this helps... D.J. On Wed, Nov 2, 2011 at 6:38 AM, Gianni Ambrosio ga...@vi-grade.com wrote: Hi D.J. unfortunately even with OVERRIDE | ON it doesn't work. Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43684#43684 ___ 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] set material basic question
...I hate it when I do this... What about PROTECTED states? Could the nodes that aren't being correctly affected by your material have a PROTECTED state, which prevents your material from being applied? See the thread Override of an Override for more information. Good luck... D.J. On Wed, Nov 2, 2011 at 4:43 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote: Hi, again, Gianni... I think our design approach is largely due to the fact that we only wanted to apply our material to very specific parts of the scene graph, and applying a material at a group node in our scene might cause unwanted material changes in other areas of the scene graph. So, I don't think it will actually help you in your case (but I could be wrong; it happens often enough). Still, the approach has some merit if you want that fine tuned control (and if it worked the way you wanted it to work). Sorry I couldn't help more... D.J. On Wed, Nov 2, 2011 at 1:13 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote: Hi Gianni, In addition to the combined flag, I just noticed we are also applying the material as close to the geometry as possible. Let's say you have a top level group node that is your root. The children of that group can either be geometry nodes or other groups. In our project, when applying the new material, we essentially traverse each group node in search of geometry, and then only apply the material to the geometry nodes. I would warn you that this approach probably will not work very well for level of detail nodes, since the geometry is dynamically loaded/unloaded as needed as a function of viewing distance. In that case, you should probably apply the material to the top level node returned from the geometry loader, since that node is probably the only persistent node for that geometry. This is the approach we have taken, and we just accept whatever results we get. I would have expected your original approach to work, but, since it appears that does not work, you might try something like the above approach. I would hope this would get you closer to the results you're looking for, but I can't make any guarantees. How you would implement that approach will have to be up to you, since you know your goals and your system best. I hope this helps... D.J. On Wed, Nov 2, 2011 at 6:38 AM, Gianni Ambrosio ga...@vi-grade.comwrote: Hi D.J. unfortunately even with OVERRIDE | ON it doesn't work. Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43684#43684 ___ 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] set material basic question
Hi, again, Gianni... I think our design approach is largely due to the fact that we only wanted to apply our material to very specific parts of the scene graph, and applying a material at a group node in our scene might cause unwanted material changes in other areas of the scene graph. So, I don't think it will actually help you in your case (but I could be wrong; it happens often enough). Still, the approach has some merit if you want that fine tuned control (and if it worked the way you wanted it to work). Sorry I couldn't help more... D.J. On Wed, Nov 2, 2011 at 1:13 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote: Hi Gianni, In addition to the combined flag, I just noticed we are also applying the material as close to the geometry as possible. Let's say you have a top level group node that is your root. The children of that group can either be geometry nodes or other groups. In our project, when applying the new material, we essentially traverse each group node in search of geometry, and then only apply the material to the geometry nodes. I would warn you that this approach probably will not work very well for level of detail nodes, since the geometry is dynamically loaded/unloaded as needed as a function of viewing distance. In that case, you should probably apply the material to the top level node returned from the geometry loader, since that node is probably the only persistent node for that geometry. This is the approach we have taken, and we just accept whatever results we get. I would have expected your original approach to work, but, since it appears that does not work, you might try something like the above approach. I would hope this would get you closer to the results you're looking for, but I can't make any guarantees. How you would implement that approach will have to be up to you, since you know your goals and your system best. I hope this helps... D.J. On Wed, Nov 2, 2011 at 6:38 AM, Gianni Ambrosio ga...@vi-grade.comwrote: Hi D.J. unfortunately even with OVERRIDE | ON it doesn't work. Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43684#43684 ___ 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] set material basic question
Hi Gianni, On my project, we are using OSG 2.8.3, and we combine the osg::StateAttribute::OVERRIDE flag with osg::StateAttribute::ON. You might try: [code] root-getOrCreateStateSet()-setAttribute(material, osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON); [/code] That combination seems to work for us. I hope this helps... D.J. On Thu, Oct 27, 2011 at 10:39 AM, Gianni Ambrosio ga...@vi-grade.comwrote: Hi, great, third topic without any reply. It seems the forum works fine. Thank you! Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43597#43597 ___ 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] [build] osg with QT how to?
Greetings to Jin and fellow OSG/Qt users. Jin, I am glad that you got your setup working. I am unsure of the specific differences between g++ and Visual C++, but I would recommend that you be careful using win32-g++ as your QMAKESPEC when using Visual Studio anything as your build environment, unless you have found a way to use g++ as your compiler/linker within the Visual Studio IDE (in which case, you can probably ignore everything I say below). Using g++ as your compiler/linker within the Visual Studio IDE is completely outside my experience (I do not know if such a thing is even possible). Generally, I have found that http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio is a good place to start for Visual Studio specific instructions for building OSG. Just make sure that you use the correct 3rd party dependencies (it looks like you are using the correct ones). From the error message I read in what I think is your original post, it looks like you may not have added OSG's bin directory and/or the 3rd party bin directory to your path before trying build the example that uses OSG with Qt. If you are using the CMake GUI, use the advanced view to make sure that all the CMake settings are correct before trying to generate project files for the examples; you may have to manually make changes to some of the settings; I am unfamiliar with configuring CMake from the command line. At the time when you saw the error, had you already successfully installed Qt and OSG in the desired debug and release builds? Are you using debug Qt libraries with debug OSG libraries, and release Qt libraries with release OSG libraries? With Visual C++, you can not mix debug binaries with release binaries. I notice in what I think is your original post that you do not mention g++. How did you determine that win32-g++ was the QMAKESPEC you needed? Did you build Qt with a g++ compiler/linker? Are you using an already built Qt SDK? As daunting as it may seem, if you are using a Qt SDK that was not already built with Visual Studio 2008, you may want to consider building Qt from source code yourself. Qt has pretty good instructions on how to do that specific to the version of Qt you want to use. I would start with http://qt.nokia.com/, and follow the links to the version of Qt you want to use with OSG. If I followed the thread correctly, you specifically mentioned VS2008 on Windows 7. Does Qt not offer a Visual Studio 2008 QMAKESPEC? If so, I would recommend using that, unless you are using a version of Qt SDK already built with g++; in that case, you should also consider building OSG with the same type of setup as that used to build the Qt SDK. I do not think that g++ binaries are compatible with Visual C++ binaries. I hope this helps. In any event, good luck in your work with OSG and Qt. D.J. On Thu, May 19, 2011 at 5:28 AM, jin tongo scat...@googlemail.com wrote: Hi, thanks for the reply, I solved the problem. For all of you who struggle, here is how I did this: I downloaded the QTSDK, installed it in C:\ Set environment variables: QTDIR to C:\QtSDK\Desktop\Qt\4.7.3 QMAKESPEC to win32-g++ Since I wanted to work with Microsoft Visual Studio 2008 I added C:\QtSDK\Desktop\Qt\4.7.3\msvc2008\bin to the Path environment variable Updated Microsoft Visual Studio 2008 to SP1, downloaded this update from Microsoft (important, because without Visual Studio SP1 I got linker crashes when compiling osg) - I checked out OpenSceneGraph from the repository - Also checked out the OpenSceneGraph Data (on the website under downloads - SVN) Both into C:\Projects\ I also downloaded the 3rdParty_VC9sp1_x86_x64_V5.7z , just used the x82 Version and packed it all into C:\Projects\3rdParty (next to the OpenSceneGraph Repositories, and made sure the folders for x86 (like bin, include, lib were directly in the 3rdParty folder). Then I ran CMake over my C:\Projects\OpenSceneGraph and created the build folder C:\Projects\OpenSceneGraph\build. Made sure - that the CMake install Path was set to C:\Program_Files(x86)\OpenSceneGraph. - that CMake found the 3rdParty folder and many libraries (ofc. not all of them) - that I checked build OSG examples - that CMake found the QT executable and I checked build QT examples Then I hit generate. I set some environment variables: OSG_FILE_PATH to C:\Projekte\OpenSceneGraph-Data OSG_DIR to C:\Program Files (x86)\OpenSceneGraph added C:\Projekte\3rdParty\bin;C:\Program Files (x86)\OpenSceneGraph\bin to the Path environment variable I opened the .sln file in C:\OpenSceneGraph\build with Visual Studio. Set it to Debug and compiled it (ALL BUILD). The after around 20 min it was finished and i right clicked the INSTALL target and told Visual Studio to build that (which just copies the right files into my CMake install path (C:\Program_Files(x86)\OpenSceneGraph). Then I set Visual Studio to Release and did ALL BUILD again.
Re: [osg-users] Meta-data in core OSG - project started
Hello Sukender,
In response to your backward compatibility suggestions, I believe clear
documentation is the key, and I believe you all are off to a good start in
that regard.
Inlining the deprecated functions with appropriate comment is a good start
for clear documentation in the source code.
It may be a bit redundant, but attempting to drive the point home for the
user, might I suggest the following type of comment for the deprecated
functions:
[code]
/**
* \deprecated
* note: implemented in terms of meta-data; consider using meta-data directly
... */
[/code]
My current opinion is that the two functions you suggest, as straight
forward as they may be to write correctly, may not be useful enough for the
OSG group at large to justify adding even that small wrinkle of complexity
to the design. userData and descriptionList specific functions will be
deprecated features, and, as such, we should probably actively discourage
continued use. clearValuesButUserDataAndDescriptionList and
removeContainerButKeepUserDataAndDescriptionList might put an undo burden on
clients for the sake of supporting functions that are slotted for removal.
I can already see one or two design alternatives using meta-data for my
project to replace descriptionList. We were able to isolate how and where
we were using descriptionList, so the change for us would thankfully be
fairly straight forward.
On a purely aesthetic note, might I suggest for the sake of consistency
using the same spelling of meta-data, meta data, or metadata in all official
documentation. I can be real nit picky, I know. ;-)
Thanks...
D.J.
On Wed, May 4, 2011 at 9:13 AM, Sergey Kurdakov sergey.fo...@gmail.comwrote:
Hi Sukender,
while
templatetypename T
struct VarValue{
VarValue(T _t) : m_T(_t){}
typedef T value_type;
T m_T;
};
was correct in my last mail
T getType() const { return value_type; }
was incorrect, still anyway take a look at how such things are done in
Ogre
http://www.ogre3d.org/docs/api/html/classOgre_1_1Any.html
Regards
Sergey
___
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] Meta-data in core OSG - project started
Hi Gregoire, Sukender, and everyone, While writing this email, I have come to the conclusion that I/we do not really have anything (more) to be concerned about with tying user data and description list to the meta-data system. If you are interested in some of the concerns I already had, and that were further clarified while reviewing the proposed meta-data system, read on. I appreciate the responses I have received thus far. Again, thanks for all the hard work! :-) ...here is what I was thinking... My concern is not so much that the underlying structure will be unavailable, per se. It is that userData and descriptionList will now be tied to the meta-data system, with no built in alternatives. With the proposed implementation, replacing an existing meta-data container would effectively clear any existing userData or descriptionList. Further, if the special hooks for exotic types are part of the container, and that container is not written to handle generic data such as userData and descriptionList, use of userData/descriptionList may cause problems. Really, I am just trying to make sure I/we understand all the implications of tying userData, descriptionList, and meta-data together in the same core feature. Here is one problem scenario that I have some concern about: [code] // load some data osg::Node* p = osgDB::readNodeFile ( ... ); ... p-addDescription ( ... ); ... // if the following third party function calls setValueContainer, // this destroys any existing userData and/or descriptionList thirdParty::doSomeWork ( p ); [/code] In my project, we have been using descriptionList as a work-around to userData and the fact that each osg::Node is restricted to not more than one attached instance of userData. I did not want to interfere with any existing userData generated by geometry and scene files, so I used descriptionList to store our runtime data, because descriptionList appears to have no explicit restrictions beyond that of a std::vector. If a third party function happens to cause the description list to be cleared after we have added some data to it, we would lose the data we need to do some of our runtime work. In reality, the proposed meta-data system does not cause the above problem scenario; the problem has always been there (the third part function could have directly called setDescriptions). However, this is one more way to clear the description list. I suppose, in the end, there really is no need for my concern. You propose (or I have inferred) a required interface with specific guaranteed behavior for writing custom containers; if container providers follow the rules, userData and descriptionList (or whatever a client may want to use) will still be supported. As long as no one takes the opportunity to replace an existing meta-data container without documenting that this is what they are doing, we should be fine. I will review version 5 of your document, and I will give myself some more time to digest what you have written. I already like what I have seen, and the more that I think about it, the better understanding I have of the developing situation. Thanks, again... D.J. On Mon, May 2, 2011 at 10:05 AM, Sukender suky0...@free.fr wrote: Hi D.J., hi all, Here is the v5 update! Not a huge thing but we modified it according to our experiments. Check out the [v5] tags in the document. @DJ: Well, as Gregroire said, the methods are always here to access userData and desriptionList, but you cannot access the members directly, as they disapeared. In core OSG, we spotted that there were very few direct accesses. Do you fear this would not be the same for OSG users? @Gregoire: On the right path you are, padawan! ;) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Gregoire Tarizzo gregoire.tari...@virtuelcity.com a écrit : Hi D.J. , hi all, First, thanks a lot to all, for your feedback and ideas. I’ve been following with a lot of interest your ideas and propositions on this topic and it helped us a lot. The v5 of the documentation will be out soon (likely monday), with more detailed information and the latest changes we made in our implementation. @D.J. About the deprecation of _userData and _descriptions : Well yes, this behaviour is intended. One of the objectives of this meta-data system was to replace _userData and _descriptions from the object and node and by doing so, make it a few bytes lighter when not using any of those, while providing a tool able to handle multiple values from multiple types. Moreover _userData and _descriptions may be removed, but it doesn’t mean that all the _userData and _descriptions methods won’t work anymore. We reforged them so that they use the new metadata system. So hopefully it won’t change anything for the user. One of our first issues was the “protected” access to _userData, meaning we can’t reach the 100% backward compatibility
Re: [osg-users] Meta-data in core OSG - project started
Hi Sukender and fellow interested parties,
I've finally had a chance to review your meta-data doc (version 4) to see
what you all have been designing, and how we might be able to use it in our
project.
Overall, I must say the design looks good. I really appreciate the effort
you have put into it.
I do have a few design points you may (not) find interesting, so feel free
to accept/modify/comment/ignore as you see fit (as long as you take credit
for any mods/comments that you make ;-) ). If you think I've misunderstood
something, feel free to give me pointers where I may have gone off track; I
only hope I am not stating the obvious, thereby wasting people's time.
1) By deprecating user data and description lists, and integrating them into
the proposed meta-data system until those interfaces are removed, you have
some major side effects:
a) With the current proposal, replacing a meta-data container destroys
any legacy user data or descriptions that may already be present. If this
is a desirable side effect, so be it, but users should be explicitly made
aware of this side effect.
b) User data and description lists will not be a viable work around
(because they will are deprecated) for users who cannot, or will not,
convert to the new meta-data system and also do not wish to replace any
existing meta-data on a node. They will be forced to use some other means
(probably external) to store their data. Again, if this is a desirable side
effect, so be it.
c) For data base accessors, user data and/or description lists may (not)
be totally inappropriate when choosing the proxy container route; a
meta-data value that holds a proxy container may be preferred. I have
little to know experience with data bases, so others will have more insight
into this sort of thing, but I thought it worth mentioning.
2) I think you might be missing an interface layer that is necessary for the
type system to work for user defined containers that have proxy values,
but do not want to pay the default cost of storing a T value:
[code]
// slight mod from current design
class ValueBase : public Referenced
{
protected:
// do we not need a virtual destructor here, since containers will
// hold ref_ptr to this?
virtual ~ValueBase() {}
};
// type specific interface for getting type specific values into/out of
// containers, without revealing how the value itself is stored here
templatetypename T ValueT : public ValueBase
{
public:
// interface layer needs to able to virtually assign values; copy
// constructors need more detail, so we must go to the most derived
// type for that, and we should be using clone for that anyway
ValueT operator=(const ValueT val)
{ xassign(val.value()); return *this; }
ValueT operator=(const T val) { xassign(val); return *this; }
virtual T value() = 0;
virtual const T value() const = 0;
// const so we can use it anywhere excpet for assignment to this
// value
operator T() const { return value (); }
protected:
// derived types tend to need explicitly defined destructors
virtual ~ValueT() {}
private:
// yes, this is virtual and private, but client code should not be
// calling this unless we provided set methods other than straight
// assignment; the pattern is unusual, but it works
virtual void xassign(const T val) = 0;
};
// renamed from ValueT with slight mods
templateclass T class BasicValue : public ValueTT
{
public:
//virtual const char * className() const;
/** Constructor*/
BasicValue() {}
/** Contructor from T.*/
BasicValue(const T val) { _value = val; }
/** Copy constructor*/
BasicValue(const BasicValueT val) { _value = val._value; }
BasicValue operator=(const T val) { _value = val; return *this; }
BasicValue operator=(const BasicValue val) { _value = val._value;
return *this; }
T value() { return _value; }
const T value() const { return _value; }
/* Implicit conversion */
// see ValueT, above
//operator T() { return _value; }
protected:
/** the stored value*/
T _value;
// derived types tend to need explicitly defined destructors
virtual ~BasicValue() {}
/** overloaded == operators, we have to be extra careful because T type
doesn't necessarily have ==
* overloaded.*/
friend inline bool operator==(const BasicValueT left,const
BasicValueT right){ return left._value==right._value; }
friend inline bool operator==(const T left,const BasicValueT right){
return left==right._value; }
friend inline bool operator==(const BasicValueT left,const T right){
return left._value==right; }
private:
// virtual assignment for use with the interface layer, ValueTT
virtual void xassign(const T val) { _value = T; }
};
[/code]
By forcing users to derive from the interface template, ValueTT, you can
guarantee a common type safe interface for casting inside your generic
meta-data containers, without the expense of storing T
Re: [osg-users] Meta-data in core OSG - project started
Hi, all...
I just realized, if you write your proxy correctly, your original class
ValueT probably works just fine for more exotic types (when T is your
proxy class giving access to the underlying type), without my proposed
interface layer. In fact, for purposes of reference semantics, the original
is probably preferred.
Perhaps I should have read that doc more than three times...
Regardless, I look forward to your comments and the final product.
D.J.
On Fri, Apr 29, 2011 at 11:01 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote:
Hi Sukender and fellow interested parties,
I've finally had a chance to review your meta-data doc (version 4) to see
what you all have been designing, and how we might be able to use it in our
project.
Overall, I must say the design looks good. I really appreciate the effort
you have put into it.
I do have a few design points you may (not) find interesting, so feel free
to accept/modify/comment/ignore as you see fit (as long as you take credit
for any mods/comments that you make ;-) ). If you think I've misunderstood
something, feel free to give me pointers where I may have gone off track; I
only hope I am not stating the obvious, thereby wasting people's time.
1) By deprecating user data and description lists, and integrating them
into the proposed meta-data system until those interfaces are removed, you
have some major side effects:
a) With the current proposal, replacing a meta-data container destroys
any legacy user data or descriptions that may already be present. If this
is a desirable side effect, so be it, but users should be explicitly made
aware of this side effect.
b) User data and description lists will not be a viable work around
(because they will are deprecated) for users who cannot, or will not,
convert to the new meta-data system and also do not wish to replace any
existing meta-data on a node. They will be forced to use some other means
(probably external) to store their data. Again, if this is a desirable side
effect, so be it.
c) For data base accessors, user data and/or description lists may
(not) be totally inappropriate when choosing the proxy container route; a
meta-data value that holds a proxy container may be preferred. I have
little to know experience with data bases, so others will have more insight
into this sort of thing, but I thought it worth mentioning.
2) I think you might be missing an interface layer that is necessary for
the type system to work for user defined containers that have proxy
values, but do not want to pay the default cost of storing a T value:
[code]
// slight mod from current design
class ValueBase : public Referenced
{
protected:
// do we not need a virtual destructor here, since containers will
// hold ref_ptr to this?
virtual ~ValueBase() {}
};
// type specific interface for getting type specific values into/out of
// containers, without revealing how the value itself is stored here
templatetypename T ValueT : public ValueBase
{
public:
// interface layer needs to able to virtually assign values; copy
// constructors need more detail, so we must go to the most derived
// type for that, and we should be using clone for that anyway
ValueT operator=(const ValueT val)
{ xassign(val.value()); return *this; }
ValueT operator=(const T val) { xassign(val); return *this; }
virtual T value() = 0;
virtual const T value() const = 0;
// const so we can use it anywhere excpet for assignment to this
// value
operator T() const { return value (); }
protected:
// derived types tend to need explicitly defined destructors
virtual ~ValueT() {}
private:
// yes, this is virtual and private, but client code should not be
// calling this unless we provided set methods other than straight
// assignment; the pattern is unusual, but it works
virtual void xassign(const T val) = 0;
};
// renamed from ValueT with slight mods
templateclass T class BasicValue : public ValueTT
{
public:
//virtual const char * className() const;
/** Constructor*/
BasicValue() {}
/** Contructor from T.*/
BasicValue(const T val) { _value = val; }
/** Copy constructor*/
BasicValue(const BasicValueT val) { _value = val._value; }
BasicValue operator=(const T val) { _value = val; return *this; }
BasicValue operator=(const BasicValue val) { _value = val._value;
return *this; }
T value() { return _value; }
const T value() const { return _value; }
/* Implicit conversion */
// see ValueT, above
//operator T() { return _value; }
protected:
/** the stored value*/
T _value;
// derived types tend to need explicitly defined destructors
virtual ~BasicValue() {}
/** overloaded == operators, we have to be extra careful because T type
doesn't necessarily have ==
* overloaded.*/
friend inline bool operator
Re: [osg-users] Meta-data in core OSG - project started
Hi Sukender, I, too, have been following this thread with interest. I have not had the time or resources to go over your documentation, yet, but I hope to do so soon. In my current project, we have adapted the osg::Node::DescriptionList to store some basic run time data at the node level. My hope is that the meta-data system you all are designing will give us a more type safe option that does not require string conversion. Thanks for taking the time and effort to work on this. Even if this turns out not to be the solution I am looking for, I am sure others will be able to leverage it to great effect. D.J. On Wed, Apr 27, 2011 at 10:23 AM, Sukender suky0...@free.fr wrote: Keep up the good work :-) Nice to read it, Robert! ;) And you're right, keep your mind resources for all other important things here! Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Wed, Apr 27, 2011 at 3:09 PM, Sukender suky0...@free.fr wrote: We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? I don't have any comments beyond what others have added so I've been happy to sit back and watch the discussion evolve. I have enough other work to think about so rather than get wrapped up in another topic I am deliberately kept my head down so I can keep my brain capacity and time from being too thinly spread. So me being quiet is not in-acceptance or disinterest, but comfort that all those who've been contributing to the thread look to be going in a resonable direction and don't seem to need any guidance from me. Keep up the good work :-) 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] Download details: Microsoft Visual Studio 2010 Service Pack 1 (Installer)
Hi, Chris. I have been using OSG 2.8.3 built as 64 bit shared libraries with VS2010 (no SP1) on 64 bit Windows 7 for several weeks now, with no real problems. Specifically with OSG, using CMake 2.8.3, I only had problems with the INSTALL target; it appears the .lib, .dll, and .exe files weren't where INSTALL was looking to copy from, so I had to move things manually to where INSTALL could find them. (There's probably been chatter on this, and I just missed it). I didn't suffer from the Hotfix issue that Qt 2.7.x calls out because I also use Qt in my app, and I built Qt first (so I got the hotfix). I won't go into the performance comments; you guys have pretty much covered all the bases. Hope this helps... D.J. On Thu, Mar 17, 2011 at 1:47 PM, Anders Backman ande...@cs.umu.se wrote: I second the one about performance. I have a 4 Core Machine (8 with HT) with 6GB memory. Since I started using VS2010, I feel kidnapped by Microsoft. The Intellisense is extremely slow for larger projects. VS is an editor, but sometimes it feels like a CAD application, it commonly uses 700-800Mb, and it is locks up now and then. Reloading a solution with 30-some projects takes forever... So its not really a huge leap forward from VS2008, which feels like a Ferrari in comparison. Seems that they have merged the Word team with the VS2010 development team... VS2010, is more like Microsoft Word, but with a compiler. For day to day C++ development (not using .NET), its a pain...waiting for the circle most of the time. But the fonts are nicer :-) The one and only thing that really sticks out as a positive improvement is the performance profiler. Thats really really nice. Although it only works for 32bit apps :-( /A On Thu, Mar 17, 2011 at 6:29 PM, Paul Sherman psher...@drizzle.comwrote: Chris, I have not, as of yet, gotten around to building OSG with VS2010SP1, but in general I would say that if you are using VS2010, get the service pack. It fixes quite a few bugs and there are some drastic improvements in performance. The one woefully horrible piece of functionality is Go To Definition which is still pretty slow even after the one time, murderously slow database rebuild. I use 3rd party tools instead. Other than that, I think it is a good set of fixes. -Paul On 3/17/2011 10:09 AM, Chuck Seberino wrote: Chris, I haven't been impressed at all with VS2010. The IDE tends to crash quite a bit - annoying, but not the end of the world. I did have an issue with 64-bit builds, particularly with Qt-4.7.x. Seems that there were byte-alignment issues (http://support.microsoft.com/kb/2280741). After installing the hotfix everything seems OK, at least no problems that I could blame on the compiler :). I haven't tried SP1 yet. I even tried looking for a list of fixes, but it seems that MS doesn't want to publish them. So my suggestion - if there is nothing wrong with the current development setup, don't upgrade. The IDE is slower and buggier than ever. That being said, it is (finally) generating proper binaries in x64 with the hotfix. The last item I forgot to mention is that there are duplicate symbols between osgDB::fstream and std::fstream that require the /FORCE:MULTIPLE linker option to work around. Only an issue on 2010 builds. HTH Chuck On Mar 16, 2011, at 7:06 PM, Chris 'Xenon' Hanson wrote: VC++2010 SP1 is apparently out now. https://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5 I have one client who really wants to use OSG on 2010 (64-bit even!) and I'm curious about people's experiences with stability. Is 2010 generating good solid binaries from the OSG codebase, or are there still issues that we'll need to see if the SP1 fixes? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ 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 -- __ Anders Backman, HPC2N 90187 Umeå University, Sweden and...@cs.umu.se http://www.hpc2n.umu.se Cell: +46-70-392 64 67 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Download details: Microsoft Visual Studio 2010 Service Pack 1 (Installer)
Sorry, everyone. I hit Send too fast before I could remember something else import to my experience. There were some minor changes discussed in the list about adding an include directive to a few header files. Try referring to http://groups.google.com/group/osg-users/browse_thread/thread/459e4bc93cc6922c/1fe07b41ff8b02de?lnk=gstq=iterator+build#1fe07b41ff8b02de for the details (subject line in that thread reads VS 2010 and OSG v2.8.3). This discusses how the iterator header is required in a few places under the VS2010 build of OSG 2.8.3. Good luck... D.J. On Thu, Mar 17, 2011 at 2:13 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote: Hi, Chris. I have been using OSG 2.8.3 built as 64 bit shared libraries with VS2010 (no SP1) on 64 bit Windows 7 for several weeks now, with no real problems. Specifically with OSG, using CMake 2.8.3, I only had problems with the INSTALL target; it appears the .lib, .dll, and .exe files weren't where INSTALL was looking to copy from, so I had to move things manually to where INSTALL could find them. (There's probably been chatter on this, and I just missed it). I didn't suffer from the Hotfix issue that Qt 2.7.x calls out because I also use Qt in my app, and I built Qt first (so I got the hotfix). I won't go into the performance comments; you guys have pretty much covered all the bases. Hope this helps... D.J. On Thu, Mar 17, 2011 at 1:47 PM, Anders Backman ande...@cs.umu.se wrote: I second the one about performance. I have a 4 Core Machine (8 with HT) with 6GB memory. Since I started using VS2010, I feel kidnapped by Microsoft. The Intellisense is extremely slow for larger projects. VS is an editor, but sometimes it feels like a CAD application, it commonly uses 700-800Mb, and it is locks up now and then. Reloading a solution with 30-some projects takes forever... So its not really a huge leap forward from VS2008, which feels like a Ferrari in comparison. Seems that they have merged the Word team with the VS2010 development team... VS2010, is more like Microsoft Word, but with a compiler. For day to day C++ development (not using .NET), its a pain...waiting for the circle most of the time. But the fonts are nicer :-) The one and only thing that really sticks out as a positive improvement is the performance profiler. Thats really really nice. Although it only works for 32bit apps :-( /A On Thu, Mar 17, 2011 at 6:29 PM, Paul Sherman psher...@drizzle.comwrote: Chris, I have not, as of yet, gotten around to building OSG with VS2010SP1, but in general I would say that if you are using VS2010, get the service pack. It fixes quite a few bugs and there are some drastic improvements in performance. The one woefully horrible piece of functionality is Go To Definition which is still pretty slow even after the one time, murderously slow database rebuild. I use 3rd party tools instead. Other than that, I think it is a good set of fixes. -Paul On 3/17/2011 10:09 AM, Chuck Seberino wrote: Chris, I haven't been impressed at all with VS2010. The IDE tends to crash quite a bit - annoying, but not the end of the world. I did have an issue with 64-bit builds, particularly with Qt-4.7.x. Seems that there were byte-alignment issues (http://support.microsoft.com/kb/2280741). After installing the hotfix everything seems OK, at least no problems that I could blame on the compiler :). I haven't tried SP1 yet. I even tried looking for a list of fixes, but it seems that MS doesn't want to publish them. So my suggestion - if there is nothing wrong with the current development setup, don't upgrade. The IDE is slower and buggier than ever. That being said, it is (finally) generating proper binaries in x64 with the hotfix. The last item I forgot to mention is that there are duplicate symbols between osgDB::fstream and std::fstream that require the /FORCE:MULTIPLE linker option to work around. Only an issue on 2010 builds. HTH Chuck On Mar 16, 2011, at 7:06 PM, Chris 'Xenon' Hanson wrote: VC++2010 SP1 is apparently out now. https://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5 I have one client who really wants to use OSG on 2010 (64-bit even!) and I'm curious about people's experiences with stability. Is 2010 generating good solid binaries from the OSG codebase, or are there still issues that we'll need to see if the SP1 fixes? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list
Re: [osg-users] Problems with osg:: sharedObjects
Hello, Werner.
If I read your createObject correctly, you appear to be returning a raw
pointer to an object that gets deleted within the function. Using ref_ptr
in the local scope, but returning a raw pointer, results in the deletion of
the object when you leave the function, since the only live reference is
going out of scope. I would recommend that you either: 1) use ref_ptr as
your return type, or 2) wait to use ref_ptr outside of createObject.
Unfortunately, I can't offer any advice on your testing question, since I
use always Visual Studio to build and use OSG.
I hope this helps...
D.J.
On Wed, Jan 26, 2011 at 12:31 PM, Werner Modenbach wer...@texion.eu wrote:
Dear community,
Maybe someone of you can give me a hint.
I'm running Windows 7 64 Bit and osg 2.8.3.
I have a Qt application working with AdapterWidget.
Al my scene works fine and is displayed the right way.
After deleting my view (derived from AdapterWidget) and reinstantiation of
the view again
I have problems with sharedObjects. The same scene doesn't work any more.
The following trivial sequence of code crashes the program:
someSharedObject * createObject {
osg::ref_ptrsomeSharedObject obj1 = new someSharedObject;
return obj1.get();
}
osg::ref_ptrsomeSharedObject obj2;
obj2 = createObject(); // crashing here
After restarting the program in the console the message appears:
Fault tolerant heap shim applied to current process. This is usually due to
previous crashes.
The only reason I can imagine is the existance of static variables
beeing uninitialized in the second run. Is there any hint where to look for
that?
I'd like to avoid reading tons of code.
Another question in the context of testing:
I found the tool spyGlass for tracking GL-calls. Is there any way to build
it without visual studio?
Like configure;make;make install ?
Or ist there any other recommended tool?
Thanks for any hints.
- Werner -
___
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] osgviewerQtWidget
Hello, Christian. If you overload the virtual function, QOSGWidget::paintEngine, to return 0, you may see improvement. In the past, that is what has worked for me, and the option has been discussed in this list. Do a search on the archives for paintEngine and/or Qt paint for more detail. Also, check out the Qt documentation and source code for possible implications for your project. I hope this helps... D.J. On Tue, Oct 5, 2010 at 10:58 AM, Christian Muggeridge christian.muggeri...@arup.com wrote: Hi, The osgviewerQtWidget is built with the examples in OSG 2.9.9 to demonstrate a Qt/OSG combination. The example loads 4 osg files in 4 separate views (in a Qt window), grouped in a composite view. The example code requires the usage of 3 classes: QOSGWidget, ViewQOSG and CompositeViewerQOSG. QOSGWidget derives from a QWidget object. ViewQOSG derives from QOSGWidget and OSGViewer::View. CompositeViewerQOSG derives from QWidget and OSGViewer::CompositeViewer. I am trying to simplify this example to only use the QOSGWidget/ViewQOSG classes, as I don't require the functionality of the composite viewer. However, it seems as though that the CompositeViewerQOSG contains a virtual paintEvent, which handles the drawing of the OSG models. Thus, by eliminating the composite viewer along with the paint event, when a model is loaded (e.g. cow.osg), a solid black view persists in the area where the cow should load. My question is, to create a simple osg viewer in a Qt window WITHOUT the composite viewer, will I need to reorganize the classes built in the example file (e.g, cut out code, add new paintEvent etc.) to get a simplified example working? Has anyone tried this with the OSG 2.9.9 example? Thank you! Cheers, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32402#32402 ___ 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] osgviewerQtWidget
Hi, Christian, I am using OSG 2.8.3, and I haven't had a chance to work with the newer code and examples. Your suggestion of reorganizing the classes might help, but since I haven't looked at the code myself, that's as much as I can say about that. With more detail about your source code, maybe someone with more experience can offer some advice and/or alternatives. Good luck... D.J. On Tue, Oct 5, 2010 at 11:40 AM, Christian Muggeridge christian.muggeri...@arup.com wrote: The virtual paintEngine is actually already in place. I believe that this virtual paint engine helped a flickering problem. In my case, there is no flickering, but only a solid black view. Any other suggestions? Thanks, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32405#32405 ___ 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] Visual Studio 2010 and VPB
Brad, Sorry for the confusion, but reverting to GDAL 1.6 was our work-around. :( We haven't had time to investigate exactly what the cause of the problem was or how to fix it. If and when we do find a way to use a more current version of GDAL, I'll try to remember to let you all know, especially since we only use it for building/using VPB. Again, I'm sorry if I caused confusion. Good luck... D.J. On Thu, Jun 17, 2010 at 8:35 PM, Christiansen, Brad brad.christian...@thalesgroup.com.au wrote: Hi, I am interested as I would like to move to the latest gdal version. I have reverted back to 1.6 for now for different reasons but would like to upgrade. Please do share hw you worked around the runtime problems. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of D.J. Caldwell Sent: Friday, 18 June 2010 1:26 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Visual Studio 2010 and VPB Hi Brad. We have only been using VPB 0.9.10 with OSG 2.8.3 for a little while, but we found using GDAL 1.6 worked, but 1.7 did not. I'm not sure what the exact problem was, but I think we had a runtime error (I know, you're experiencing linker problems) having to do with mapping the texture to the geometry. Another caveat, we're still using VS2005, but we're hoping to upgrade soon! :) Anyway, I thought you might be interested in the runtime problem, and how we worked around it, in case you run into similar problems. Good luck... D.J. On Wed, Jun 16, 2010 at 10:35 PM, Christiansen, Brad brad.christian...@thalesgroup.com.au wrote: Hi, Thanks for the suggestions. I have checked that both are built with the same options, including the 3rd part dependencies, and as far as I can tell, they all are. I did end up using the /FORCE:MULTIPLE option but I really don't like just ignoring the issue. For now I have moved back to VS 2008 as I have run out of time to get things working. Hopefully I will get a chance to look at it again soon as this was the final hurdle to having everything building correctly. Cheers, Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cory Riddell Sent: Wednesday, 16 June 2010 11:37 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Visual Studio 2010 and VPB On 6/16/2010 3:10 AM, Christiansen, Brad wrote: Hi, I have managed to build OSG (and 3rd party dependencies) using Visual Studio 2010 but I have hit a snag with VPB. The error has been reported before by Matrin Naylor, but there didn't seem to be any resolution. The error is: 1osgDB.lib(osgDB.dll) : error LNK2005: public: void __thiscall std::basic_ofstreamchar,struct std::char_traitschar ::`vbase destructor'(void) (??_d?$basic_ofstr...@du?$char_traits@d...@std@@@std@@QAEXXZ) already defined in SpatialProperties.obj 1 Creating library D:/adi_vsfz/projects/OSG/osg-trunk-2010/vpb-build/lib/Release/vpb.lib and object D:/adi_vsfz/projects/OSG/osg-trunk-2010/vpb-build/lib/Release/vpb.exp 1D:\adi_vsfz\projects\OSG\osg-trunk-2010\vpb-build\lib\Release\vpb.dll : fatal error LNK1169: one or more multiply defined symbols found You can always tell the linker to ignore the problem with /FORCE:MULTIPLE. I'd only do that as a last resort though because there might actually be a problem here. Are both projects compiled with VS2010 with the same settings? Cory DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg
Re: [osg-users] Visual Studio 2010 and VPB
Hi Brad. We have only been using VPB 0.9.10 with OSG 2.8.3 for a little while, but we found using GDAL 1.6 worked, but 1.7 did not. I'm not sure what the exact problem was, but I think we had a runtime error (I know, you're experiencing linker problems) having to do with mapping the texture to the geometry. Another caveat, we're still using VS2005, but we're hoping to upgrade soon! :) Anyway, I thought you might be interested in the runtime problem, and how we worked around it, in case you run into similar problems. Good luck... D.J. On Wed, Jun 16, 2010 at 10:35 PM, Christiansen, Brad brad.christian...@thalesgroup.com.au wrote: Hi, Thanks for the suggestions. I have checked that both are built with the same options, including the 3rd part dependencies, and as far as I can tell, they all are. I did end up using the /FORCE:MULTIPLE option but I really don’t like just ignoring the issue. For now I have moved back to VS 2008 as I have run out of time to get things working. Hopefully I will get a chance to look at it again soon as this was the final hurdle to having everything building correctly. Cheers, Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cory Riddell Sent: Wednesday, 16 June 2010 11:37 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Visual Studio 2010 and VPB On 6/16/2010 3:10 AM, Christiansen, Brad wrote: Hi, I have managed to build OSG (and 3rd party dependencies) using Visual Studio 2010 but I have hit a snag with VPB. The error has been reported before by Matrin Naylor, but there didn’t seem to be any resolution. The error is: 1osgDB.lib(osgDB.dll) : error LNK2005: public: void __thiscall std::basic_ofstreamchar,struct std::char_traitschar ::`vbase destructor'(void) (??_d?$basic_ofstr...@du?$char_traits@d...@std@@@std@@QAEXXZ) already defined in SpatialProperties.obj 1 Creating library D:/adi_vsfz/projects/OSG/osg-trunk-2010/vpb-build/lib/Release/vpb.lib and object D:/adi_vsfz/projects/OSG/osg-trunk-2010/vpb-build/lib/Release/vpb.exp 1D:\adi_vsfz\projects\OSG\osg-trunk-2010\vpb-build\lib\Release\vpb.dll : fatal error LNK1169: one or more multiply defined symbols found You can always tell the linker to ignore the problem with /FORCE:MULTIPLE. I'd only do that as a last resort though because there might actually be a problem here. Are both projects compiled with VS2010 with the same settings? Cory DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ 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] osgviewQT example does not fully work
Hello, Zachary. I use cow.osg for most of my testing. It may not be the most intensive geometry, but it seems to work for testing simple behaviors. Try searching the OSG archives for paintEngine. You should find a fix that MIGHT help with what you're seeing. Under Microsoft Windows, there appears to be a refresh problem requiring the paintEngine tweak. I don't know what impact it may have for Ubuntu. AdapterWidget versus QOSGWidget: I could be wrong, but I believe using AdapterWidget restricts osgViewer to single threaded mode, whereas QOSGWidget is supposed to allow single OR multithreaded modes. I hope this helps... D.J. On Wed, May 26, 2010 at 3:29 PM, Zachary Hilbun zacha...@vianova.com wrote: Hi, I'm using Eclipse with the Qt plugin in order to develop c++ osg code under Ubuntu. I've compiled and run the osgviewQT example and have the following questions. The example does not fully work. I'm using the OSG cow as a test model. Is this example the preferred way to use osg under Qt? If it is not, I'll abandon it and use whatever better way is available. If it is, I need the following questions answered. Using QOSGWidget and --CompositeViewer, the OSG cow flashes briefly and then there is an empty screen. If I use QOSGWidget as the widget using all 3 modes (--CompositeViewer, --MTCompositeViewer, and single), it does not respond to the keyboard keys for w, t, l, b, s, h. It looks to me like setupManipulatorAndHandler uses addEventHandler to handle keyboard events, but the only key that is responded to is the f key. The f key only moves the window around on the screen but does not make it full screen. I can see functions like keyPressEvent being called so that part is at least working. Only --MTCompositeViewer will respond to mouse input using the TrackballManipulator. This appears to be setup for all modes but does not work for the single view. If I use AdapterWidget as the widget, it responds to the mouse for TrackballManipulator in all modes (--CompositeViewer, --mdi, and single), but the keyboard does not work. The code does not appear to be setup for keyboard input the way QOSGWidget is. Is keyboard input not possible with AdapterWidget? Is there a reason for choosing to use QOSGWidget vs. AdapterWidget? Thank you! Cheers, Zachary -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=28257#28257 ___ 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] osgviewQT example does not fully work
Sorry, Zachary, et al. I hit Send a little to soon. I don't have any ideas for the keyboard event problem you mentioned. I use an in-house manipulater with keyboard/mouse interaction. The paintEngine fix I refer to will probably only work on your blinking/blank/refresh problem (again, if it works at all for Ubuntu). Double check documentation for Qt events and OSG's interaction with them. That's my best advice... Sorry I couldn't be more help with this part... D.J. On Wed, May 26, 2010 at 4:35 PM, D.J. Caldwell dlcaldwel...@gmail.com wrote: Hello, Zachary. I use cow.osg for most of my testing. It may not be the most intensive geometry, but it seems to work for testing simple behaviors. Try searching the OSG archives for paintEngine. You should find a fix that MIGHT help with what you're seeing. Under Microsoft Windows, there appears to be a refresh problem requiring the paintEngine tweak. I don't know what impact it may have for Ubuntu. AdapterWidget versus QOSGWidget: I could be wrong, but I believe using AdapterWidget restricts osgViewer to single threaded mode, whereas QOSGWidget is supposed to allow single OR multithreaded modes. I hope this helps... D.J. On Wed, May 26, 2010 at 3:29 PM, Zachary Hilbun zacha...@vianova.com wrote: Hi, I'm using Eclipse with the Qt plugin in order to develop c++ osg code under Ubuntu. I've compiled and run the osgviewQT example and have the following questions. The example does not fully work. I'm using the OSG cow as a test model. Is this example the preferred way to use osg under Qt? If it is not, I'll abandon it and use whatever better way is available. If it is, I need the following questions answered. Using QOSGWidget and --CompositeViewer, the OSG cow flashes briefly and then there is an empty screen. If I use QOSGWidget as the widget using all 3 modes (--CompositeViewer, --MTCompositeViewer, and single), it does not respond to the keyboard keys for w, t, l, b, s, h. It looks to me like setupManipulatorAndHandler uses addEventHandler to handle keyboard events, but the only key that is responded to is the f key. The f key only moves the window around on the screen but does not make it full screen. I can see functions like keyPressEvent being called so that part is at least working. Only --MTCompositeViewer will respond to mouse input using the TrackballManipulator. This appears to be setup for all modes but does not work for the single view. If I use AdapterWidget as the widget, it responds to the mouse for TrackballManipulator in all modes (--CompositeViewer, --mdi, and single), but the keyboard does not work. The code does not appear to be setup for keyboard input the way QOSGWidget is. Is keyboard input not possible with AdapterWidget? Is there a reason for choosing to use QOSGWidget vs. AdapterWidget? Thank you! Cheers, Zachary -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=28257#28257 ___ 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] Limitation of NodeMask
J-S, If I follow the code and this thread correctly, I don't think this a bug; I think it's a limitation of the current implementation. For example... If I have nodes masked by type (Craft, Planet, Debris, etc), and I only want to pick nodes of certain types (Craft and Planet, but NOT Debris), the system supports this. None of my nodes will have a mask set as both Craft and Planet, but either will qualify as pickable. If I restrict it to only nodes with both masks set, I'm probably not going to be able pick anything. The Pickable and Visible case would require the combined mask, but the current implementation doesn't support that directly. As Simon suggested, deriving new types and overriding the appropriate virtual functions should allow the desired behavior. The problem as I see it is the two situations I list here are mutually exclusive. If we wanted to provide both options, I think we would need to add a flag somewhere to indicate what type of mask matching behavior we're looking for (match any bit in the mask, OR match all bits in the mask). Deciding WHEN to set the flag to which mode is the user's real problem, and I think Simon's derived type suggestion takes care of that problem quite nicely without requiring a change to the current implementation as the default behavior. Then again, I could be totally off base, so feel free to correct me, and I'll be happy to learn from the experience. :) I hope this helps... D.J. On Fri, May 7, 2010 at 9:22 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Simon, Yes, he wants to only pick objects which are pickable AND visible. Which you can't do just using a node mask, you'll get anything which is pickable OR visible. That's a bug IMHO. If I say this: int VISIBLE_MASK = 0x01; int PICKABLE_MASK = 0x02; // Render only what's visible view-getCamera()-setCullMask(VISIBLE_MASK); // Pick what's visible and pickable intersectionVisitor-setTraversalMask(VISIBLE_MASK | PICKABLE_MASK); visibleNode-setNodeMask(VISIBLE_MASK); pickableVisibleNode-setNodeMask(VISIBLE_MASK | PICKABLE_MASK); pickableNode-setNodeMask(PICKABLE_MASK); Then I should only see the nodes that have VISIBLE_MASK set (so visibleNode and pickableVisibleNode above), and I should only be able to pick nodes that have both VISIBLE_MASK and PICKABLE_MASK set (so only pickableVisibleNode above). The rendering works (I only see visibleNode and pickableVisibleNode) but the picking sees all three nodes. Here's a modified osgpick that shows this. In the 5 boxes on the left side of the window, the first is VISIBLE but not PICKABLE, the second is both, the third is PICKABLE but not VISIBLE, and the last two are both. Indeed we don't see the third, so that's fine, but we can still pick all 5. Instead of (traversalMask nodeMask) != 0, perhaps the condition should be (traversalMask nodeMask) == traversalMask... Or perhaps there's a rationale for being able to pick whatever has part of the traversal mask, but not the mask exactly, but I can't see it right now... I can't delve into this at present, but with an example that shows the problem perhaps others can fix it... J-S -- __ Jean-Sebastien Guay jean-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] [VirtualPlanetBuilder][build] Which Versions of GDAL and/or Squish Are Required?
Thanks to Chris and Martin for your replies. My apologies for my late reply. While my question is a build question, it is also a runtime question. I was able to successfully build VPB 0.9.10 with OSG 2.8.2, GDAL 1.7.1, and the latest SVN version of Squish. However, the runtime behavior appeared to be in error. Specifically, image overlays were not applied when specified. I also was able to successfully build VPB 0.9.10 with OSG 2.8.2, GDAL 1.6.0, and the latest SVN version of Squish. The runtime behavior of this combination appears to work correctly, even when specifying image overlays. While a bug fix would be appropriate, my current duties prevent me from looking into the error (user, build, runtime, or otherwise). So, my question and/or request still stands: what combinations are appropriate and appear to work correctly? Can we post the preferred version information for GDAL and Squish (whatever they are) on the VPB website, similar to what is done for the VPB/OSG version combinations? Thanks, again... D.J. On Sat, Apr 3, 2010 at 5:50 AM, Martin Naylor martin.nay...@dsl.pipex.com wrote: Just to confirm, I downloaded the VPB,GDAL and OSG from the latest SVN trunk and all compiled just fine for windows x64. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris 'Xenon' Hanson Sent: 03 April 2010 06:23 To: OpenSceneGraph Users Subject: Re: [osg-users] [VirtualPlanetBuilder][build] Which Versions of GDAL and/or Squish Are Required? On 4/2/2010 3:31 PM, D.J. Caldwell wrote: So, my question is: did I miss where the required versions of GDAL and Squish are specified? If so, where can I find that information? I use GDAL 1.6, but I would think that newer versions should be fine. If they're not, it should be looked into. As far as I know, libsquish is entirely optional, and not required. Thanks... D.J. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ 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] [VirtualPlanetBuilder][build] Which Versions of GDAL and/or Squish Are Required?
Hi, Martin. In my case, it appears that the texture is not shown at all. It does not appear to be flipped or scaled, since I see no texture. Switching from GDAL 1.7.1 to 1.6.0 appeared to fix that problem; the texture appears to show correctly. I have not (yet) run across your crash problem, but that may be due to the limited use cases I have seen in our project. These all may (not) be related. Regardless, for my case, I'm certainly open to the possibility that the error lies in how I am trying to use the software, and not a bug in the software itself. However, switching versions and getting different behavior suggests to me that the fault may not entirely lie with me, unless the error is in my choice of versions. While I am certainly interested in a solution to the problem, my main concern is clearly identifying what versions of which libraries should be combined with what to get the advertised behavior. Even if the only tight coupling of versions is between VPB and OSG, it would be nice to know what versions of GDAL and Squish were used for each VPB release. FYI, it appears that I neglected to mention my build environment in the original posting: Visual Studio 2005 Professional (Service Pack 1) on 32 bit Windows XP Professional (Service Pack 3). Thanks... D.J. On Mon, Apr 12, 2010 at 2:21 PM, Martin Naylor martin.nay...@dsl.pipex.com wrote: I am running GDAL 1.7 and have noticed that the textures become flipped when I follow the Puget example. Not sure if that is GDAL causing the issue or its the same one you are having. I just download some STRM data and applied some Landsat Image as a texture and now have a crash when zooming into deep levels. Its appears if you generate a terrain with levels over 10+ it causes a crash when you zoom deep into the terrain generated with osgdem using the -l switch, I will have a look a bit later and see if I can get a crash dump out of it. Not sure if it similar to your problem or if I am asking too much out of my data and vpb? Martin. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of D.J. Caldwell Sent: 12 April 2010 16:05 To: OpenSceneGraph Users Subject: Re: [osg-users] [VirtualPlanetBuilder][build] Which Versions of GDAL and/or Squish Are Required? Thanks to Chris and Martin for your replies. My apologies for my late reply. While my question is a build question, it is also a runtime question. /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] Build Osg with 64Bit (dependency)
Maybe slightly off topic, but somewhat related: boost is currently experimenting/working on a cmake build alternative for their system. Perhaps this could help (confirm) your setup(s)? Keep us all posted on the 64bit front... Thanks... D.J. On Thu, Feb 25, 2010 at 4:19 AM, Morné Pistorius mpistorius@googlemail.com wrote: Excellent news! Thank you, that will be really helpful! Regards, Morne On Wed, Feb 24, 2010 at 7:49 PM, Anders Backman ande...@cs.umu.se wrote: I managed to build what I need in 64bit. My take on it was to cmakeify them all. Collada, boost (only libsystem, libfilesystem), (jpeg, png and zlib was alredy cmakified.) There are a few which Im not interested in, including jasper, tiff and a few more. I can certainly pack this into a zip including the bin/lib/include content. I'll see if I get it done tomorrow. Took a while though to get everything to build, which everyone (including the Collada team would open their eyes and spot CMake. /A On Wed, Feb 24, 2010 at 6:41 PM, Luigi Calori l.cal...@cineca.it wrote: Hi, I ' m building a somehow cmaked, static version of the (currently basic) osg dependencies. I' m trying also to make it extensible by keeping patch and compiler options in separate folders. I attach a zip of my current repo: try to build the Assemblies/test2 folder with latest 2.8 cmake. It should work also for win64 i tested with msvc9 32 Hope it helps Luigi Morné Pistorius wrote: Hi Anders, How did you get on with this? Were you able to build the third party dependencies for Win64? A third party package, even with just the basic dependencies to build most of OSG, would really be helpful. I was about to start building my own when I found this thread, and hoped you had beat me to it! :) Cheers, Morne On Wed, Feb 10, 2010 at 8:45 AM, Anders Backman ande...@cs.umu.se wrote: Hi all. Looong time no see. Im currently trying to build OSG on 64bit under windows (VS2009). Getting all the dependencies over to 64bit is apain. I did a quick search through forum/mail, and it seems that not many does this. Is there ANYONE with a prebuilt package including Collada (with boost, pcre, libxml), jpeg, png, zlib for 64bit windows? The Cmake:d versions of jpeg, zlib, png was certainly a big help. But before I dig into this, perhaps someone has a prebuilt package? -- /Anders ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build Osg with 64Bit (dependency)
Sorry; what I meant was, boost is experimenting using cmake to build boost, as an alternative to their boost build system. Hope this helps... D.J. On Thu, Feb 25, 2010 at 1:46 PM, D.J. Caldwell dlcaldwel...@gmail.com wrote: Maybe slightly off topic, but somewhat related: boost is currently experimenting/working on a cmake build alternative for their system. Perhaps this could help (confirm) your setup(s)? Keep us all posted on the 64bit front... Thanks... D.J. On Thu, Feb 25, 2010 at 4:19 AM, Morné Pistorius mpistorius@googlemail.com wrote: Excellent news! Thank you, that will be really helpful! Regards, Morne On Wed, Feb 24, 2010 at 7:49 PM, Anders Backman ande...@cs.umu.se wrote: I managed to build what I need in 64bit. My take on it was to cmakeify them all. Collada, boost (only libsystem, libfilesystem), (jpeg, png and zlib was alredy cmakified.) There are a few which Im not interested in, including jasper, tiff and a few more. I can certainly pack this into a zip including the bin/lib/include content. I'll see if I get it done tomorrow. Took a while though to get everything to build, which everyone (including the Collada team would open their eyes and spot CMake. /A On Wed, Feb 24, 2010 at 6:41 PM, Luigi Calori l.cal...@cineca.it wrote: Hi, I ' m building a somehow cmaked, static version of the (currently basic) osg dependencies. I' m trying also to make it extensible by keeping patch and compiler options in separate folders. I attach a zip of my current repo: try to build the Assemblies/test2 folder with latest 2.8 cmake. It should work also for win64 i tested with msvc9 32 Hope it helps Luigi Morné Pistorius wrote: Hi Anders, How did you get on with this? Were you able to build the third party dependencies for Win64? A third party package, even with just the basic dependencies to build most of OSG, would really be helpful. I was about to start building my own when I found this thread, and hoped you had beat me to it! :) Cheers, Morne On Wed, Feb 10, 2010 at 8:45 AM, Anders Backman ande...@cs.umu.se wrote: Hi all. Looong time no see. Im currently trying to build OSG on 64bit under windows (VS2009). Getting all the dependencies over to 64bit is apain. I did a quick search through forum/mail, and it seems that not many does this. Is there ANYONE with a prebuilt package including Collada (with boost, pcre, libxml), jpeg, png, zlib for 64bit windows? The Cmake:d versions of jpeg, zlib, png was certainly a big help. But before I dig into this, perhaps someone has a prebuilt package? -- /Anders ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scale mesh/terrain once before adding to scene
David, After looking into Paul's suggestion, I believe that (for static terrain) if you add your terrain to your scaling node, and then use Paul's suggestion on the scaling node, you may get what you're looking for. The Optimizer is much simpler than my original suggestion, although you may still want to look at those other classes for future work. Again, if your terrain has levels of detail, I would recommend just using the MatrixTransform approach. I hope this helps... D.J. On Thu, Feb 25, 2010 at 5:05 PM, Paul Martz pma...@skew-matrix.com wrote: David Cofer wrote: I am new to OSG, so perhaps this is simple and I do not understand how something is working. I want to scale a terrain once immediately after it is loaded, but before it is added to the scenegraph. I know I can do this by adding it to a matrixtransform node that is scaled, but that seems inefficient. It seems like it would have have to mess with the scaling every time the scenegraph is processed instead of just having to scale things once when it is loaded. Is there a way to apply a transform once in this manner? Am I misunderstanding how the scenegraph is processed and why I believe this would be more efficient? You could run the osgUtil::Optimizer with the FLATTEN_STATIC_TRANSFORMS visitor. -Paul ___ 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] Scale mesh/terrain once before adding to scene
Hello, David. If your terrain is static, I would recommend an osg::NodeVisitor used on your terrain in combination with osgUtil::TransformAttributeFunctor used on the drawables of your terrain. As far as I know, this is a custom solution, so you'll have to look into both of these classes to see how to apply them correctly. If your terrain has levels of detail, I would recommend using the osg::MatrixTransform node, or your levels of detail may not get the right scaling applied. I hope this helps. D.J. On Thu, Feb 25, 2010 at 4:58 PM, David Cofer dco...@mindcreators.com wrote: I am new to OSG, so perhaps this is simple and I do not understand how something is working. I want to scale a terrain once immediately after it is loaded, but before it is added to the scenegraph. I know I can do this by adding it to a matrixtransform node that is scaled, but that seems inefficient. It seems like it would have have to mess with the scaling every time the scenegraph is processed instead of just having to scale things once when it is loaded. Is there a way to apply a transform once in this manner? Am I misunderstanding how the scenegraph is processed and why I believe this would be more efficient? Thanks for you help, David -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24888#24888 ___ 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] why dynamic modification are so difficult?
Hi Fausto and Robert, If the simple modification is due to some specific user event (button press, file dialog, etc.), I might recommend refactoring the code to add/remove nodes instead of drawables. It sounds like you have no trouble initially getting the geometry into the scene; it is the simple modification that is the problem. What I am suggesting here is a work-around, and not a fix (on my system, it appears that there is no bug to fix). Other than this, I believe the issue may be familiarity with the available patterns; that is, using the right tool for the right job. No insult intended, but the only fix for that is research, time, and patience. The project I am part of uses visitors and/or swapping out vertices for time based changes, and adding/removing nodes for user based inputs. Fausto, as Robert said, you are the only one who can know what is appropriate for your project. Just some things to consider; I hope this helps... D.J. On Thu, Jan 21, 2010 at 12:12 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Fausto, Dynamically modifying the scene graph shouldn't be that hard. Removing drawables and adding news ones should perfect safe and shouldn't require and extra steps from you, no need to dirty bounding volumes or display lists, it should all just work. As to why your new drawables aren't appearing I can't say. Try writing the subgraph they are in out to a file then load this file into osgviewer to see if can view them. It could be simply that there is something wrong with the geometry data you've set up. Only you has your app and your data so you're the only one that can investigate. Robert. On Thu, Jan 21, 2010 at 4:41 PM, fausto f4us...@gmail.com wrote: Hi All, I'm struggling to have a simple modification of an osg scene working. I simply need to remove all drawables from a geode and add new drawables to the same geode. In the viewer, the geode just disappears after removing the drawables, but I can see that the scene contains the geode with the new drawables. So, it seems a rendering problem. I see that many people have similar problems with dynamic modifications. I've read plenty of posts about setting display list to false, using callbacks, dirtyBound(), etc But I hope there is a clearer and easier way to achieve this. Please let me know. Thanks for any help. Fausto ___ 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] why dynamic modification are so difficult?
Fausto, My project uses Qt widgets as well, so if this is the problem, I'd be interested in the solution so that I can proof read our code. Fortunately/unfortunately, it appears to work for me. As to the nodes and drawables, all I can say is that there are nodes, and then, there are nodes. In any event, happy hunting... D.J. On Thu, Jan 21, 2010 at 1:14 PM, fausto f4us...@gmail.com wrote: Thank you both for your inputs. To Robert: Try writing the subgraph they are in out to a file then load this file into osgviewer to see if can view them. Yes, as I mentioned the new scene data is OK, I can see it while debugging and after saving-loading it with osgViewer.exe all new drawables appear in the scene, and previous ones are removed. So, the scene is OK, the problem is really with the original viewer. It renders OK, but doesn't update properly when drawables are added. I'm rendering in Qt widgets, could that be the problem? To D.J. I might recommend refactoring the code to add/remove nodes instead of drawables. Unfortunately, I need nodes to be the same. I keep searching and testing. Thanks again for your help. Cheers. Fausto On Thu, Jan 21, 2010 at 6:42 PM, D.J. Caldwell dlcaldwel...@gmail.com wrote: Hi Fausto and Robert, If the simple modification is due to some specific user event (button press, file dialog, etc.), I might recommend refactoring the code to add/remove nodes instead of drawables. It sounds like you have no trouble initially getting the geometry into the scene; it is the simple modification that is the problem. What I am suggesting here is a work-around, and not a fix (on my system, it appears that there is no bug to fix). Other than this, I believe the issue may be familiarity with the available patterns; that is, using the right tool for the right job. No insult intended, but the only fix for that is research, time, and patience. The project I am part of uses visitors and/or swapping out vertices for time based changes, and adding/removing nodes for user based inputs. Fausto, as Robert said, you are the only one who can know what is appropriate for your project. Just some things to consider; I hope this helps... D.J. On Thu, Jan 21, 2010 at 12:12 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Fausto, Dynamically modifying the scene graph shouldn't be that hard. Removing drawables and adding news ones should perfect safe and shouldn't require and extra steps from you, no need to dirty bounding volumes or display lists, it should all just work. As to why your new drawables aren't appearing I can't say. Try writing the subgraph they are in out to a file then load this file into osgviewer to see if can view them. It could be simply that there is something wrong with the geometry data you've set up. Only you has your app and your data so you're the only one that can investigate. Robert. On Thu, Jan 21, 2010 at 4:41 PM, fausto f4us...@gmail.com wrote: Hi All, I'm struggling to have a simple modification of an osg scene working. I simply need to remove all drawables from a geode and add new drawables to the same geode. In the viewer, the geode just disappears after removing the drawables, but I can see that the scene contains the geode with the new drawables. So, it seems a rendering problem. I see that many people have similar problems with dynamic modifications. I've read plenty of posts about setting display list to false, using callbacks, dirtyBound(), etc But I hope there is a clearer and easier way to achieve this. Please let me know. Thanks for any help. Fausto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DrawCallback only once
Hi, Dominic.
I'm not sure this method is the best option for what you want, but I
don't have any ready alternatives myself, so I'll just answer your
question and move on.
I would recommend reading the following FAQ:
http://www.parashift.com/c++-faq-lite/const-correctness.html
In that context, I might recommend changing your declaration:
// begin code
bool first;
// end code
to this:
// begin code
mutable bool first;
// end code
In the event that your compiler doesn't support keyword mutable, you
can fake it with a member pointer that you have to initialize in your
constructor and cleanup in your destructor, but that is a little
clunky, and I would avoid it if I could. You would change this:
// begin code
bool first;
// end code
to this:
// begin code
bool* first;
// end code
and then do the appropriate initialization and cleanup.
I hope this helps...
D.J.
On Fri, Jan 8, 2010 at 3:50 PM, Dominic Stalder
dominic.stal...@bluewin.ch wrote:
Hi there
I would like to read the OpenGL extensions with isGLExtensionSupported(),
but for this I need a draw context. I registred a DrawCallback Class, see
below. I need to call the operator() method only once, but because this
method is const, I cannot write to the member variable bool first. How can I
resolve this problem?
class GameViewOSGDrawCallback : public osg::Camera::DrawCallback
{
private:
GameViewOSG *parent;
bool first;
public:
GameViewOSGDrawCallback(GameViewOSG* parent=0);
virtual void operator()(const osg::Camera) const;
};
Thanks a lot
Dominic
___
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] Utility of using Drawable:: ...
François, I'm glad I could help. Thanks for your reply; I was afraid that my explaination might not have made much sense (which is why I posted the link with my reply). We all have things to learn; we will just have to keep searching for good things to know and share that knowledge when we can. D.J. On Thu, Jan 7, 2010 at 1:41 AM, François Bodic f56...@hotmail.com wrote: Thank you for this clear explanation and the interesting link. I really didn't know this C++ feature. You make me less idiot :D Cheers, François -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22196#22196 ___ 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] Utility of using Drawable:: ...
Hi, François. A using directive can be used for things other than namespaces. In this case, the using directive introduces all instances of supports and accepts from the class Drawable scope (I think they're all in the public scope of that class) into the public scope of class ShapeDrawable; according to the comment, this is a work around to prevent name hiding when using a declared pointer/reference to ShapeDrawable or its derived classes. By NOT declaring and overriding all instances of virtual member functions support and accepts, ShapeDrawable would hide those other instances without the using directive. With the using directive, ShapeDrawable only has to declare and override those instances in which it needs different behavior from the inherited instances. Pick up your favorite C++ reference for a more thorough discussion of the using directive. For related material, try the following FAQ: http://www.parashift.com/c++-faq-lite/strange-inheritance.html Happy coding... D.J. On Wed, Jan 6, 2010 at 4:52 PM, François Bodic f56...@hotmail.com wrote: Hi, I cannot figure out the role of the next two lines in the ShapeDrawable implementation. I thought that the keyword using was only for namespaces... Can someone help me? using Drawable::supports using Drawable::accept Thank you! Cheers, François -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22187#22187 ___ 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] QOSGWidget display problem
Cedric, Martin, et al. I'm glad the null-returning QPaintEngine function seems to work for you. Unfortunately, I don't really have any other suggestions for testing it to determine whether or not you should label the fix acceptable. This is a question each project team must answer for themselves. I might recommend answering at least the following questions to make the determination (among any other questions that your project may need to be answered). 1) Is the behavior acceptable? 2) Does this solution fit well in the context of the documentation and the public interface for each library that is involved? 3) (Project team member responsibility) Is the solution documented so that other developers on the team can understand the purpose of the solution, its prerequisites (if any) and its side effects (if any)? Perhaps the Qt mailing lists could lead you to a better testing scheme, especially since this appears to be a Qt/graphics engine integration issue (i.e. it probably isn't specific to Qt/OSG integration). Good luck... D.J. On Sat, Dec 19, 2009 at 12:13 PM, Cedric Pinson cedric.pin...@plopbyte.net wrote: I tried this fix and it works fine now. Thank you for the fix Cheers, Cedric -- Provide OpenGL services around OpenSceneGraph and more +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net On Sat, 2009-12-19 at 05:58 +, Martin Beckett wrote: I remember Don's point about the background paint attribute being different on windows Qt but i could never get a reliable fix. The dummy QPaintEngine function has fixed the flicker problem for me on Windows (XP, Qt4.6.0, Osg 2.9.6). What further testing do we need for it to be an accepted fix? Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21688#21688 ___ 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] QOSGWidget display problem
Greetings OpenSceneGraph/Qt users,
I, also, noticed bad behavior (blinking and such) with the QOSGWidget
example code. It has been a while since I last worked with it, but I
believe that after digging around in the documentation and deep in the
source code that I (partially) corrected the problem by overriding the
virtual QWidget function, paintEngine:
QPaintEngine* QOSGWidget::paintEngine () const
{
return 0;
}
Check your documentation for QWidget::paintEngine, and then give my
suggestion a try; it seems to work for me.
I am currently using OpenSceneGraph 2.8.2 with Qt 4.5.2 on 32 bit
Windows XP Professional. I am building my project with Visual Studio
2005. I believe my fix may also work for linux users, but I haven't
tested it.
Good luck...
D.J.
On Mon, Dec 14, 2009 at 1:05 PM, Don Leich d...@ilight.com wrote:
I've run across the flickering problem before. There seems to be various
side effects with certain Qt attributes, but I got better results changing
setAttribute(Qt::WA_NoSystemBackground);
to
setAttribute(Qt::WA_OpaquePaintEvent);
in QOSGWidget.cpp.
You can follow the thread below or dig up the QOSGWidget demo with a 4-way
split window I submitted for more help with Qt atttributes.
// Date: Tue, 16 Jun 2009 10:07:16 +
// From: Eric Pouliquen epouliq...@silicon-worlds.fr
// Subject: Re: [osg-submissions] New QOSGWidget demo with a 4-way split
// window and bonus outboard window.
// Suggested replacing the two setAttribute calls with this...
// setAttribute(Qt::WA_OpaquePaintEvent);
// This solverd a flickering problem on Windows
// 8600 GT (185.85) and a Quadro FX1400 (182.65)
// but causes a visible black border to be visible in the rendering
// windows on Linux. This problem gone when WA_PaintOnScreen
// is used in combination.
// Hmmm...
// According to Qt doc, WA_PaintOnScreen is X11 only and disables
// double-buffering. I think this just means it disables a
// buffer swap under Qt control. We want OSG to have full control.
//
// Equivalent to qt_x11_set_global_double_buffer(false)?
//
// Tried turning it off and got severe flashing on Linux.
// Looks like without this we get an extraneous clear and
// buffer swap form Qt.
setAttribute(Qt::WA_PaintOnScreen);
// This flags that something other than Qt is responsible for
// all rendering in the window under the widget's control.
setAttribute(Qt::WA_OpaquePaintEvent);
// This seems superfluous now.
// setAttribute(Qt::WA_NoSystemBackground);
-Don Leich
___
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] QOSGWidget display problem
Sorry, I should have said this fix instead of my fix; someone
else may have seen this, too, or I may have gotten the idea from
someone else (directly, indirectly, or otherwise).
Thanks,
D.J.
On Mon, Dec 14, 2009 at 1:14 PM, D.J. Caldwell dlcaldwel...@gmail.com wrote:
Greetings OpenSceneGraph/Qt users,
I, also, noticed bad behavior (blinking and such) with the QOSGWidget
example code. It has been a while since I last worked with it, but I
believe that after digging around in the documentation and deep in the
source code that I (partially) corrected the problem by overriding the
virtual QWidget function, paintEngine:
QPaintEngine* QOSGWidget::paintEngine () const
{
return 0;
}
Check your documentation for QWidget::paintEngine, and then give my
suggestion a try; it seems to work for me.
I am currently using OpenSceneGraph 2.8.2 with Qt 4.5.2 on 32 bit
Windows XP Professional. I am building my project with Visual Studio
2005. I believe my fix may also work for linux users, but I haven't
tested it.
Good luck...
D.J.
On Mon, Dec 14, 2009 at 1:05 PM, Don Leich d...@ilight.com wrote:
I've run across the flickering problem before. There seems to be various
side effects with certain Qt attributes, but I got better results changing
setAttribute(Qt::WA_NoSystemBackground);
to
setAttribute(Qt::WA_OpaquePaintEvent);
in QOSGWidget.cpp.
You can follow the thread below or dig up the QOSGWidget demo with a 4-way
split window I submitted for more help with Qt atttributes.
// Date: Tue, 16 Jun 2009 10:07:16 +
// From: Eric Pouliquen epouliq...@silicon-worlds.fr
// Subject: Re: [osg-submissions] New QOSGWidget demo with a 4-way split
// window and bonus outboard window.
// Suggested replacing the two setAttribute calls with this...
// setAttribute(Qt::WA_OpaquePaintEvent);
// This solverd a flickering problem on Windows
// 8600 GT (185.85) and a Quadro FX1400 (182.65)
// but causes a visible black border to be visible in the rendering
// windows on Linux. This problem gone when WA_PaintOnScreen
// is used in combination.
// Hmmm...
// According to Qt doc, WA_PaintOnScreen is X11 only and disables
// double-buffering. I think this just means it disables a
// buffer swap under Qt control. We want OSG to have full control.
//
// Equivalent to qt_x11_set_global_double_buffer(false)?
//
// Tried turning it off and got severe flashing on Linux.
// Looks like without this we get an extraneous clear and
// buffer swap form Qt.
setAttribute(Qt::WA_PaintOnScreen);
// This flags that something other than Qt is responsible for
// all rendering in the window under the widget's control.
setAttribute(Qt::WA_OpaquePaintEvent);
// This seems superfluous now.
// setAttribute(Qt::WA_NoSystemBackground);
-Don Leich
___
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] Improvement of QT and OSG compatibility
Hi, Maxim, Qt can be built and used with a no_keywords flag so that Qt does not redefine the names emit, signal, or slot. One uses Q_EMIT, Q_SIGNAL, and Q_SLOT instead. The no_keywords flag exists so that Qt doesn't cause interference with 3rd party signal/slot mechanisms, but I think it applies here in principle (that being, Qt and OSG are conflicting). Check out the Qt documentation and headers for how this works in practice. no_keywords may be more viable than forcing the change on OSG (or other packages). I hope this helps. D.J. On Fri, Aug 28, 2009 at 12:37 PM, Maxim Gammermaxgam...@gmail.com wrote: Hi Tom, this solution won't let us use signal/slot stuff ( 2009/8/28 Jolley, Thomas P thomas.p.jol...@boeing.com Hi Maxim, What was the result of adding -DQT_NO_EMIT to the compilation flags that Antonin Linares suggested? http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg27183.html Tom Jolley From: Maxim Gammer [mailto:maxgam...@gmail.com] Sent: Friday, August 28, 2009 6:02 AM To: OpenSceneGraph Users Subject: [osg-users] Improvement of QT and OSG compatibility Hello, I've got a proposal to make changes in OSG for better compatibility with QT. Method's name emit needs to be replaced in namespace osgParticle. The thing is that emit is a name of the macros in QT. Of course, we can redefine emit like that: #ifdef emit #define MACRO1_SAVE emit #endif #undef emit .#include osg #ifdef MACRO1_SAVE #define emit MACRO1_SAVE #undef MACRO1_SAVE #endif , but this solution won't let us use signal/slot stuff. It seems that QT preprocessor replaces emit in program listing. The simpliest way to solve that - change method name from emit to something else. This will let us using signal/slot things in QT. -- Maxim Gammer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Maxim Gammer ___ 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] Improvement of QT and OSG compatibility
Hi, everyone. I'm sorry, no_keywords may be more than some people bargin for. What I mentioned is true, but there are other side effects. Specifically, Qt may redefine foreach and forever unless no_keywords is used (they provide Q_FOREACH and Q_FOREVER as alternatives). I'm not trying to confuse the issue here (emit and signals/slots), but I didn't want anyone caught off guard by unexpected side effects. As always, I recommend reading the documentation and headers for best results (which is fairly useful in this case). D.J. On Fri, Aug 28, 2009 at 2:42 PM, D.J. Caldwelldlcaldwel...@gmail.com wrote: Hi, Maxim, Qt can be built and used with a no_keywords flag so that Qt does not redefine the names emit, signal, or slot. One uses Q_EMIT, Q_SIGNAL, and Q_SLOT instead. The no_keywords flag exists so that Qt doesn't cause interference with 3rd party signal/slot mechanisms, but I think it applies here in principle (that being, Qt and OSG are conflicting). Check out the Qt documentation and headers for how this works in practice. no_keywords may be more viable than forcing the change on OSG (or other packages). I hope this helps. D.J. On Fri, Aug 28, 2009 at 12:37 PM, Maxim Gammermaxgam...@gmail.com wrote: Hi Tom, this solution won't let us use signal/slot stuff ( 2009/8/28 Jolley, Thomas P thomas.p.jol...@boeing.com Hi Maxim, What was the result of adding -DQT_NO_EMIT to the compilation flags that Antonin Linares suggested? http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg27183.html Tom Jolley From: Maxim Gammer [mailto:maxgam...@gmail.com] Sent: Friday, August 28, 2009 6:02 AM To: OpenSceneGraph Users Subject: [osg-users] Improvement of QT and OSG compatibility Hello, I've got a proposal to make changes in OSG for better compatibility with QT. Method's name emit needs to be replaced in namespace osgParticle. The thing is that emit is a name of the macros in QT. Of course, we can redefine emit like that: #ifdef emit #define MACRO1_SAVE emit #endif #undef emit .#include osg #ifdef MACRO1_SAVE #define emit MACRO1_SAVE #undef MACRO1_SAVE #endif , but this solution won't let us use signal/slot stuff. It seems that QT preprocessor replaces emit in program listing. The simpliest way to solve that - change method name from emit to something else. This will let us using signal/slot things in QT. -- Maxim Gammer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Maxim Gammer ___ 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] osgviewerQtWidget example issues (UNCLASSIFIED)
Strictly speaking, I am not sure these are OSG questions as much as they are Qt questions, but since I am a developer an OSG/Qt app myself, I will share what little I know. I know that reparenting under some windowing systems can invalidate window IDs, so that might be related to your BadWindow errors. You would have to check with your Qt documentation and your windowing system documentation to be sure (that is, if it is documented). You might have tried this already, but if not, then try setting the OSG adapter widget's parent in the constructor, and reparenting the parent widget, instead of the OSG adapter widget. I cannot seem to find where I found this problem documented; you might start your search with winId, and go from there. As to the Exit problem you describe, look into overriding the protected virtual closeEvent function on your main window. Decide whether or not to accept the event; if you accept, have closeEvent inform the app to closeAllWindows at an appropriate time. You should probably wait until the main window actually closes before calling closeAllWindows on the app, since not waiting can cause problems (I do not recall if it is a recursion problem, or a you closed this already problem). I hope this helps... D.J. On Mon, Jul 27, 2009 at 4:52 PM, Butler, Lee Mr CIV USA USAMClee.but...@us.army.mil wrote: Classification: UNCLASSIFIED Caveats: NONE The example code has problems on my machine (RedHat 5, Qt 4.5.2, NVidia 185.18.14, KDE). I've got svn revision 10512 from HEAD. The code compiles just fine (using qmake) but on startup I get: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200051 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200051 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200051 I can resize the outboard window without any problem, but attempting to resize the main window causes X11 to lock up. If I switch to gnome, it runs OK. Under either Gnome or KDE, selecting Main-Exit from the application causes the main window to close, but leaves a frozen Outboard window behind. The application does not quit until the outboard window is closed. Lee Classification: UNCLASSIFIED Caveats: NONE ___ 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] osgShadow and osgdepthpartition
Pasquale, Thanks for the quick reply. We are considering the use of cones as you describe for things like solar/lunar eclipses, but we were hoping to use osgShadow, especially when dealing with terrain and self-shadowing of complex geometry. I should have included the command line arguments I used to produce the images in my email (although I embedded them in the image names): --SingleThreaded --earth-centered --noUpdate --no-base-texture Please, address me as D.J., since I refer to myself as D.J. My given name is Darrell, but I reserve that name for formal situations. Since the list is trying for a more friendly atmosphere, I am giving you the name I use in *ALL* other situations: D.J. (which is an abbreviation of Darrell Junior). Thanks, again! D.J. On Tue, Jul 21, 2009 at 5:57 PM, Pasquale Tricaricotrica...@gmail.com wrote: Hi D.J., (please use your name so we know how to address you) I am in the same business as you, solar system simulations and such. And I too use DPN happily, but not much experience with osgShadow. One advice is to make sure you're running single thread with OSG, I think it is a strong requirement of DPN so far, it might get better with future. As for the eclipses, it's hard to model them correctly with regular shadows, so I opted to just draw transparent cones (one for the penumbra, one for the umbra) see i.e.: http://orsa.sourceforge.net/screenshots/misc/eclipse.png Cheers, Pasquale On Tue, Jul 21, 2009 at 2:30 PM, D.J. Caldwelldlcaldwel...@gmail.com wrote: I am a developer for a program that visualizes large scale (solar system) and small scale (desktop) scenes. We would like to be able to visualize shadows in our scenes for things like solar/lunar eclipses, and ground vehicles with headlights traveling over terrain in and out of sun light. We started using OpenSceneGraph around version 2.2 or 2.4. We are now moving from version 2.6 to version 2.8. We have been using an adaptation of the DepthPartitionNode from the osgdepthpartition example to help with rendering since we often operate in a solar system scene, with orbits, trajectories and lines of sight displayed as lines. We also keep the camera positioned at the origin and move the scene (by way of a transform) to help cut down on jitter in the near view caused by floating point error. The problem is... While trying to make use of osgShadow, I have discovered apparent interference between shadowing and the depth partition node (see two images attached). It would seem that the depth partition node causes the shadow to move with the camera viewing direction, rather than staying with the light direction. In other words, moving the camera causes the shadow to move in an unexpected and undesired manner. My questions are... Is there a way to get osgShadow and a depth partition node to play nice together, or are they at odds by design? Is that, in fact, what I am seeing, or have I set my test case up incorrectly? Perhaps there is some other way to get the benefits of depth partitioning that will not interfere with shadows? I have searched the archives for discussion of using shadows with a depth partition node, but I seem to be missing it (or it just isn't there). I did find one reference http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg11218.html which says to follow the source code. I looked under the hood for ParallelSplitShadowMap, ShadowMap, and LightSpacePerspectiveShadowMap to try to get a feel for how best to proceed, but I'm not seeing a clear path to a solution which allows use of shadowing with a depth partition node. I was hoping to avoid a custom solution, either that combines the two, or maybe goes in a totally different direction, but my gut reaction is that it may be unavoidable. In addition to the images, I have also attached my test environment source code, so that you can interact with the test environment which produced the two attached images. The source code represents a simplified model of our use of OSG in our program. I have it set up so that, if --noUpdate is specified on the command line at run time, the home position of the camera manipulator is set to show the problem I am seeing. It may be easiest to see with --no-base-texture on the command line (which is what I used for the images). My development environment is currently: OpenSceneGraph 2.8.1 Visual Studio 2005 Professional Edition SP1 Microsoft .NET Framework Version 2.0 SP2 Microsoft Windows XP Professional Service Pack 3 (win32) NVIDIA GeForce Go 7950 GTX (nv4_disp.dll version 6.14.10.9422) Thanks in advance! D.J. Caldwell ___ 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
