Re: [osg-users] Issues with RotateCylinderDragger
I tracked down the problem. It seems that the original code tried to come up with a plane parallel to the cylinder axis oriented towards the eye/pick point. This calculation breaks down when the eye and cylinder axis are close to being parallel. I have fixed the problem and will be submitting a patch within the next day. I am trying to go through the code to do more cleanup as the original has a number of code paths that are never reached. Regards, Chuck On Feb 20, 2012, at 4:50 AM, Marius Kintel wrote: On 17 February 2012 17:47, Chuck Seberino seber...@energid.org wrote: The behavior I am seeing is that a small change in mouse drag will cause a large rotation and in certain cases will also cause a rotation in the opposite direction. I'm seeing the same thing and it's annoying, but it hasn't yet annoyed me enough to look into that code in detail. It would be cool if you post your findings here :) Cheers, -Marius ___ 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] Issues with RotateCylinderDragger
Robert et al, I have been looking at an problem I have been having with the osgManipulator::RotateCylinderDragger. I have been trying to follow the code and there are a few things that stand out as questionable. Here are two issues I found with osgManipulator/src/Projector.cpp: 1. line 202,203 - Here it is trying to find a plane perpendicular to the eyeVector by taking the cross product of the cylinder axis. It doesn't correctly handle the case where the local eyeDir is parallel with axisDir. 2. line 601-606 - The computed plane intersection being calculated in 592 is being done at the edge of cylinder and the distance will always be = the radius and therefore this code will never be hit. Likewise there is an additional check against hitCylinder here that will never be taken due to the 'if' clause on line 589. The behavior I am seeing is that a small change in mouse drag will cause a large rotation and in certain cases will also cause a rotation in the opposite direction. I haven't yet been able to determine the exact cause, but there were just some things that stuck out as odd. I am almost at the point where I am going to try replacing all of the line-cylinder intersection code with my own since it is difficult to understand/verify the algorithm. My tests have been performed on trunk using the osgmanipulator example. I have been testing both with just a RotateCylinderDragger as well as a TrackballDragger. In the case of the TrackballDragger I removed the RotateSphereDragger (_xyzDragger) to isolate the picking to just the RotateCylinderDragger(s). The specific case is trying to pick when the eyeVector is close to parallel with the major axis of the cylinder (cylinder looks like a circle). I think issue #1 is somewhat of a red herring, in that it *should* properly calculate the plane when not exactly parallel, but even in this case there is still the abnormal behavior. My findings for #2 make me question the roots of this intersection code and I wanted to get some feedback on it. Thanks in advance. Chuck Seberino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowCocoa::WindowData dynamic_cast returns 0
Sean,
Don't know conclusively, but I have had problems like this in the past when
using dynamic_cast on a polymorphic object and it failed to give a non-NULL
value even when I knew it should. As you said, using a static_cast or C-style
cast works. In my case it had to do with how objects were defined in different
compilation units. What worked for me was specifying the following linker flag
to ensure that everybody had the same RTTI data.
set(CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS}
-Wl,-flat_namespace)
This link gives a more detailed description of the problem.
http://lists.apple.com/archives/xcode-users/2006/Feb/msg00234.html
The link only talks about passing the RTLD_GLOBAL flag to dlopen, but in my
case I needed to use the -flat_namespace flag. My particular case happened
from linking certain libraries statically causing multiple (different) copies
of the same object to be generated. Putting them all in a flat namespace made
them resolve the same, fixing my dynamic_cast problem.
So, not a conclusive answer, but at least it gives you something to investigate.
Hope that helps,
Chuck
On Jan 27, 2012, at 10:11 AM, Sean Sullivan wrote:
Hey guys,
I'm trying to pass an osgViewer::GraphicsWindowCocoa::WindowData to my traits
object with CreateOnlyView specified. For some reason whenever my WindowData
is dynamic_cast in GraphicsWindowCocoa.mm it just returns 0. If I switch them
to static_cast they work.
Here's my code:
Code:
// OSGWindow.h
osgViewer::GraphicsWindowCocoa::WindowData* windowData;
// OSGWindow.cpp
windowData = new osgViewer::GraphicsWindowCocoa::WindowData
(osgViewer::GraphicsWindowCocoa::WindowData::CreateOnlyView);
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits();
traits-x = 100;
traits-y = 100;
traits-width = 1280;
traits-height = 720;
traits-red = 8;
traits-blue = 8;
traits-green = 8;
traits-alpha = 8;
traits-depth = 24;
traits-windowDecoration = false;
traits-doubleBuffer = true;
traits-vsync = false;
traits-stencil = 1;
traits-samples = 8;
traits-sampleBuffers = 1;
traits-inheritedWindowData = windowData;
osg::ref_ptrosg::GraphicsContext context =
osg::GraphicsContext::createGraphicsContext (traits.get());
This is what's in GraphicsWindowCocoa.mm that returns 0:
Code:
GraphicsWindowCocoa::WindowData* windowData = traits-inheritedWindowData ?
dynamic_castGraphicsWindowCocoa::WindowData*(traits-inheritedWindowData.get())
: NULL;
I tried expanding it into if statements and the traits-inheritedWindowData
returns true. I also tried copying and pasting this line into my file where I
create my traits object and it returns properly.
Any ideas?
Cheers,
Sean
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=45082#45082
___
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] Absolute beginner questions
Check out osg/LineWidth osg::StateSet* stateSet = node-getOrCreateStateSet(); // 3 pixel wide line stateSet-setAttributesAndModes(new osg::LineWidth(3), osg::StateAttribute::ON); HTH Chuck On Jun 15, 2011, at 9:39 AM, basil huffman wrote: Is there a way to give thickness to line segments? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40539#40539 ___ 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] [osgPlugins] Difficulties to load images from memory
Daniel, Use the ios::binary open mode for istringstream. HTH Chuck On Jun 14, 2011, at 7:35 AM, Daniel Cámpora wrote: Hello community, Apparently, the problem is related to the formation of the strings I'm trying to pass to the istringstream. Since they contain the \0 character, they finish earlier than expected. Has anybody found any workaround for this? Thank you! Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40466#40466 ___ 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)
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
Re: [osg-users] Draw Order/Culling with OpenFlight and Transparency
Murray, Your rotor is being placed in the Opaque render bin, which is causing all of the geometry behind it to be culled out. You need to make sure it is in the transparent bin. You should add these to the stateSet of the rotors: stateSet-setRenderingHint(osg::StateSet::TRANSPARENT_BIN); stateSet-setMode(GL_BLEND, osg::StateAttribute::ON); HTH, Chuck On Feb 23, 2011, at 10:53 AM, Murray G. Gamble wrote: Hi All, We have an OpenFlight model of a helicopter that exhibits some undesirable rendering behaviour in OSG. Specifically, various parts of the helicopter geometry are being culled and/or rendered in the wrong order. We do not observe this behaviour when rendering the same model using Vega Prime. I've attached a couple of screen captures that exemplify the issues. Can users with similar experiences provide any suggestions as to how to avoid these rendering artifacts? Does the model component/geometry hierarchy need to be modified and/or are there programmatic things that can be done within our OSG application to remedy the situation? I'm using OSG 2.8.0. Many thanks, Murray CH149-OSG.jpgCH149-VP.jpg ___ 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] Fwd: Controlling animations in FBX models
Cedric, Check out: src/osgWrappers/serializers/osgAnimation Chuck On Feb 23, 2011, at 2:22 PM, Cedric Pinson wrote: Hi, I have not check the new code about serializer... I will put it in my tasklist. Anyone knows where I should look to update osgAnimation code about serializer ? Cedric On Thu, 2011-02-17 at 09:30 +, Michael Platings wrote: I've not used any of the osg file formats so I can't help you there specifically, but I suspect the osganimation serializer is in need of updating. Cedric Pinson wrote osgAnimation so he's the best person to consult on this matter. On 16 February 2011 16:23, Thomas Hogarth thomas.hoga...@gmail.com wrote: Hi Michael Thanks for the info, do you know why I might be having trouble saving these to .ive, .osg, .osgt and .osgx. It's not a show stopper but for some reason I can only re save the imported fbx as .osgb. The rest fail to load except .osg which loads but won't play my animations anymore :( Any info would be much appreciated Tom On 16 February 2011 16:08, Michael Platings mplati...@gmail.com wrote: I dare say the fbx plugin creates some kind of custom callbacks that normal osg is unaware of. Not exactly, the callbacks in question are all part of osgAnimation which is increasingly part of normal osg. They are: osgAnimation::RigComputeBoundingBoxCallback, osgAnimation::MorphGeometry::UpdateVertex osgAnimation::RigGeometry::UpdateVertex ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Provide OpenGL, WebGL and OpenSceneGraph services +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image brightness using osg::DrawPixels and polygon texture rendering
Eric, You should look at your TexEnv parameters. Use something like DECAL or REPLACE. Looks like you are using the default, which is MODULATE, which takes into account the color of the polygon with the texture. Of course these modes (DECAL,REPLACE) will disable any lighting that is going on, but you seem to want that anyway. HTH -- Chuck On Feb 16, 2011, at 12:42 PM, Eric Sokolowsky wrote: Jason, Thanks for the suggestion. I did re-render the image at twice the size but I'm still seeing that the textured polygon version is noticeably dimmer than the DrawPixels version. See the attached image. I have three images here, each rendered twice, the top drawn with the textured polygon and the bottom rendered with DrawPixels. I'm not doing any enlargement now. Any ideas on why the DrawPixels version so much brighter than the textured polygon? -Eric On Wed, Feb 16, 2011 at 11:35 AM, Jason Daly jd...@ist.ucf.edu wrote: On 02/16/2011 10:44 AM, Eric Sokolowsky wrote: Hello, Does anyone have suggestions on getting the textured version brighter, hopefully as bright as the DrawPixels version? The textured version is probably getting dimmer because of the linear magnification filter. Since your background is black, any pixels in the image that are partially covering a pixel on the screen are getting mixed with the black background and the overall luminance is lessened because of that. The DrawPixels version is obviously blocky because you're drawing without any kind of magnification filter. If you switched the mag filter settings on the texture version to GL_NEAREST instead of GL_LINEAR, I imagine your results will look very much like the DrawPixels version. Of course, the real problems is that you're rendering the given image to a resolution that is significantly larger than its actual size. Ideally, you'd want to enlarge the original image to as close to the target resolution as you can before using the texturing operations to draw it to the screen. I don't know the source of the image, so I don't know if it's possible or practical to do this, but that would be the best solution. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org out-2.png___ 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] Calling OSX Dev's, Cocoa/Carbon support required for new osgGA feature
Robert, I also gave osgkeyboard a whirl on my OSX-10.6.5 system built from r12127. Here is what I see on my system: KeyPress / Output - c / c Shift-c / C Ctrl-c / c Alt-c / c Command(Super)-c / c So pretty much in every case it prints the lowercase version except when you use Shift-c. Is this the desired behavior? Allessandro - my build puts things in the correct location. I am using the Makefile generator and not doing anything framework/bundle specific. My screen keys do not get highlighted either. Also there is no distinction between left and right (they are all left) for shift, alt and super. Adding one more item to the strange behavior queue - The capslock modifier also seems to not be fully baked. I seem to need to press it 4 times in order to sync the MODKEY_CAPS_LOCK bit with the physical keyboard. If I press it once, it registers in osg: (8192) and the light shows up on my keyboard. Pressing it again still sets the bit (8192), while the keyboard light turns off. A third time turns off the bit (0), but enables the keyboard light. The 4th time syncs everything once again with both the MODKEY_CAPS_LOCK bit set to 0 and the keyboard light being off. Regards, Chuck Seberino On Jan 27, 2011, at 10:21 AM, Alessandro Terenzi wrote: Hi Robert, I've just tried osgkeyboard on Mac OS X 10.6.5: whatever key I press I see that it is correctly written in yellow in the row just below the keyboard, but it is NOT highlighted on the keyboard itself. I'm talking about not only the modifiable-keys but also about keys (such as backspace, space, ...) that cannot have a modified status (at least I guess). One note not related to this topic: I noticed that plugins are not built into the osgPlugins-2.9.11 folder but just at the same level of the dylibs. Hope this helps. Cheers. Alessandro On Thu, Jan 27, 2011 at 5:40 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi OSX dev's, This afternoon I merged a submission from Alexander Sinditskiy, that addressed a limitation in osgGA::GUIEventAdapter where the getKey() method would return only the modified variation of the keycode that was pressed - so this would be Ctrl-C, 'C' or 'c', and if your you didn't want to worry about the modified key status you'd have to handle each of these cases in your event code. The way that Alexander addressed this was to add a new UnmodifiedKey property to GUIEventAdapter, with support added to the osgGA::EventQueue as well as the X11 and Win32 implementations found in GraphicsWindowX11.cpp and GraphicsWindowWin32.cpp. Alexander and his colleagues don't have access to OSX so couldn't add the required support into GraphicsWindowCocoa/Carbon so for now you'll just get a 0 for the UnmofidiedKey. Now this won't affect most apps as they won't yet be using the UnmodifiedKey property, but osgkeyboard has now been modified to use the UnmodifiedKey property as this illustrates it's usage and also simplifies the example as it no longer needs to doing multiple mappings to handle upper and lower case letters. However, osgkeyboard will now just get a 0 for UnmodifiedKey so the keys on screen won't toggle on/off correctly. At least this is what I'm expecting - I don't have on OSX box in front of me so I can't test this. Could OSX users try out OSG in svn/trunk and run osgkeyboard and see how things behave and then have a look into the possibility of providing the UmodifiedKey property as GraphicsWindowWin32.cpp and GraphicsWindowX11.cpp now do. The unmodified keys now map the 'A' and 'a' to be 'a', X11 is already uses this convention while Win32 have 'A' as the unmodified state, but Alexander's revision addresses this so both produce an GUIEventAdapter::KEY_A which is mapped to 'a'. OSX will need to use the same convention. Thanks in advance with any help you can provide in adding this functionality to OSX. Cheers, 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] Jitter problem - OSG Nvidia Physx
Arif,
You haven't really said _what_ was jittering - is it your scene entities, or
your camera? If it is your entities, then what I am about to say won't really
apply to you. If it is your camera, then maybe it will give at least help to
give you a clue. You might want to check the order in which you perform your
updates. Here is a scenario I ran into a while back:
1. Had an osg::OperationThread that pulled in data from network to update
positions of objects
2. Had an osgGA::GUIEventHandler that performed node tracking and updated the
camera matrixTransform
If you look at osgViewer::ViewerBase::frame, you will see
void ViewerBase::frame(double simulationTime)
{
...
eventTraversal();
// *** OperationThreads get called in updateTraversal before the update
visitor.
updateTraversal();
renderingTraversals();
}
In my case I was repositioning my camera in the eventHandler, but new object
position information was coming in during the updateTraversal. This caused my
camera to always calculate based on the old position and therefore be one frame
behind. I changed the logic so that the calculation of the camera position
happened during the call to my camera manipulator's getInverseMatrix() and that
fixed my problem.
So as long as everything coming in is updated and sync'ed in the same way,
you shouldn't see jitter.
Hope that helps
--
Chuck Seberino
On Jan 24, 2011, at 1:45 AM, Arif Yetkin Sarı wrote:
Hello everyone.
We have been using OSG with nvidia physx for a driving simulation and we have
jitter problem, where the cars and other objects in the scene (controlled by
the physics) jitter annoyingly :). We believe that we update the scenegraph
in a wrong way.
In our code :
There is a physx thread.
There is an OSG library thread where we can add new entities, remove them,
start rain effects, call an animation of a skeleton character etc.
There is an OSG render loop thread, where osgviewer::...frame() is called.
Our Nvidia physx thread produces new x y z pitch head roll values for the
scene entities at 60Hz (or any other frequency we want).
Physx thread calls the updateEntity() function of our OSG library thread.
This function simply updates scene entities with matrixtransform::void
setMatrix(const Matrix mat).
In other words, we move an object with this chunk of code:
Code:
osg::Matrixd mxT = createTransformMatrix(x,y,z,h,p,r);
mt-setMatrix(mx);
Here what we tried:
1-we fed OSG lib directly whenever a physx output is produced (every 16.6 ms
or so - 60Hz): there is jitter.
2-we maintained a queue of frames on OSG lib, fed OSG at the end of each
frame() : there is jitter.
3-we implemented a sampling mechanism on this queue, where OSG requests the
interpolated frame from the queue for the current timestamp : there is jitter.
4-we saved a few minutes long log of the physx to a file (many frames).
Started a dummy thread, and fed OSG from this log. : there is jitter.
When OSG works with 60FPS, and physx thread is running at 60Hz, there seems
to be quite low jitter (sometimes unnoticeable) .
Thanks in advance for any hints or advices.
Arif Yetkin
http://www.youtube.com/watch?v=naX3hOkDx8w
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35912#35912
___
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] MacOS X 32 and 64 bit universal binaries?
Jean, I build universal binaries on OSX just fine. I run Snow Leopard (10.6.x), but I generate code compatible with 10.5. I build all of my 3rd party libraries manually, which is sometimes a pain as some packages are not friendly to universal builds. In those cases, the configure script bombs when trying to run the preprocessor to figure out 32/64 bit building. For those I build separately for 32 bit, then for 64 bit and then use lipo to merge. Here is my typical environment strings for building 3rd-party libraries, which seems to get around most issues: CC=gcc -arch i386 -arch x86_64 CXX=g++ -arch i386 -arch x86_64 CPP=gcc -E CXXCPP=g++ -E SDKROOT=/Developer/SDKs/MacOSX10.5.sdk MACOSX_DEPLOYMENT_TARGET=10.5; I go the Cocoa route for the windowing system as it supports both 32 and 64 bit. Same thing with imageIO. That means you need to build your own png, gif, jpeg and tiff libraries since it won't use QuickTime (32-bit only). Once your dependencies are ready, it is pretty straightforward to build OSX. Simply set your CMAKE_OSX_ARCHITECTURES to i386;x86_64 and build. Works in a single pass. I typically build with Makefile support, but the XCode generator works as well. Hope that helps Chuck Seberino On Dec 8, 2010, at 7:14 AM, Jean-Sébastien Guay wrote: Hello all, I have a few questions about the MacOS X build. I believe now the build all happens through CMake right? Can I build binaries of OSG that would support both 32 and 64 bit intel? I guess for this to work, I need all third-party libraries OSG links with to be also 32+64 bit? Is there a repository for 3rdparty libraries that would support this? (i.e Does fink or some other place give you both?) For example I guess I need freetype at least... The windowing should be done in the right way for each build, i.e. Cocoa or Carbon depending on 32 or 64 bit? And reading images is done through ImageIO, does this support both 32 and 64 bit? In general, say I want to build a library I coded as 32+64 bit, what is the process? Do I need to build twice with different gcc flags and then package them into one library, or is it done in a single pass? Can I do it with straight gcc or do I absolutely need to use XCode? Sorry for the long list of questions, but we're starting to support Mac OS X for a client and this is kind of new territory for us. Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Wrong CMake output directory using Visual - half submission
Sukender,
It is indeed related to CMake = 2.8.1. I have had success setting all
configuration types including the generic one, which seems to work on Linux,
OSX and Windows. So:
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE ${OUTPUT_LIBDIR})
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG ${OUTPUT_LIBDIR})
That way it works with older and newer versions of CMake. Older versions don't
know/use/ignore the specific configuration types and newer CMake uses the most
specific setting.
The conditional below I use for other situations. It works for me since I am
simply checking against previous versions:
# CMake = 2.8.1 changed the output directory algorithm...
if (CMAKE_CONFIGURATION_TYPES AND NOT APPLE)
if (${CMAKE_MAJOR_VERSION} EQUAL 2 AND
(${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION} LESS 8.1))
#Perform 'old' CMake method.
# ...
endif ()
endif ()
HTH
Chuck Seberino
On Oct 22, 2010, at 11:13 AM, Sukender wrote:
Hi Robert, hi all,
I spotted the binaries are not in /bin as usual with my new config (CMake
2.8.2, VS2010 x64), but in /bin/Debug and /bin/Release.
I think CMake 2.8.2 is the cause because the usual way to work around these
subdirs should not work anymore (SET_TARGET_PROPERTIES(Target PROPERTIES
PREFIX ../)). I found a way to make it work properly. However I don't post
it as a submussion because I didn't test it as it should (not tested under
Linux), and I guess we must write some versionning code (if cmake version is
below x.y.z...). Here is my code, to be put in the root CMakeLists.txt:
Instead of using
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${OUTPUT_LIBDIR})
and such, use:
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_CONFIG ${OUTPUT_LIBDIR})
So the code should look like:
FOREACH(CONF ${CMAKE_CONFIGURATION_TYPES})
STRING(TOUPPER ${CONF} CONF)
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_LIBDIR})
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_BINDIR})
IF(WIN32)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_BINDIR})
ELSE()
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF} ${OUTPUT_LIBDIR})
ENDIF()
ENDFOREACH()
Hope someone will take a few minutes to write a nice CMake script (and figure
out the version number from which this can bu used, if this is really 100%
CMake related)
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thinking of adding to the ReaderWriter interface
Wang, I was wondering how you would keep this information resident in the Registry. From your first example it seems like you are setting an option that would attempt to be applied to ALL ReaderWriter transactions, regardless of extension. In this case, some general types of options could be agreed upon and used by many different plugins. In your second example it looks like you want to create a specific option map for a single ReaderWriter. In this case the option would ONLY be applied to the dds plugin. So are you thinking about having both cases handled with your implementation - both multi-plugin as well as single-plugin options? Chuck Seberino On Oct 17, 2010, at 2:04 AM, Wang Rui wrote: Hi all, I just encountered an annoying problem that DDS images should be flipped for correct rendering if generated by DirectDraw-based tools. The images are already included in scene files (like osg, ive, obj, etc.) so osgdb_dds's flip_dds option cannot be used directly. Of course making own plugins, altering texture coordinates and using node visitors are all possible solutions. But I'm wondering if there is some other way to handle such problems, for example, set a plugin's global state and then change its behaviors on the fly. My plan is to modify the osgDB::ReaderWriter interface and add a new virtual method setGlobalOption(), which does nothing by default. Specific plugins can override this method to realize certain functionalities accordingly; and other plugins' code will not be broken any more. For example, assuming we have got the dds reader writer: rwDDS-setGlobalOption(flip_dds=true); // Ready to read flipped DDS images rwDDS-readImage(directdraw_image1.dds); rwDDS-readImage(directdraw_image2.dds); ... rwDDS-readImage(directdraw_imagen.dds); rwDDS-setGlobalOption(flip_dds=false); // OK, reset the behavior rwDDS-readImage(opengl_image.dds); It can also work for other types of plugins (if corresponding method is implemented), for instance, to force compressing data when saving next few files: rwIVE-setGlobalOption(compressed=true) rwIVE-writeNodeFile(...); We can even have a convenient method like Registry::setGlobalOptionForExtension(). Then, when reading scene files with flipped dds files, we will have: osgDB::instance()-setGlobalOptionForExtension(dds, flip_dds=true); osgDB::readNodeFile(directdraw_image.dds); So is this necessary to be added to current osgDB functionalities? (I'd like to code if necessary) Any opinions or better ideas about this? Or have we already had too much discussions about this? :-) Cheers, Wang Rui ___ 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] OSG-VRML
Alexander, I build and use OpenVRML 0.18.5 in my codebase. I am presently compiling for Win32, Linux 32/64, and OSX 32/64. I will go into what I did on the OSG side to get things to work, so I assume that you are able to successfully build OpenVRML libraries on your platform. Non-Win32 platforms worked fine for the most part. For all platforms, the one thing that I needed to add was an entry in src/osgPlugins/vrml/CMakeLists.txt for include support for boost. OSG doesn't have a universal boost configuration option (there is a Collada boost config), which is why I haven't submitted a formal fix for this. Just add in a: INCLUDE_DIRECTORIES(path_to_your_boost_include) and the rest should be taken care of (rpath and boost linking taken care of on the OpenVRML lib side). If you build under windows, then there is more that needs to happen. A few fixes if you are using Visual Studio 2010 since the TR1 naming conflicts with boost (lines 113,117,122 of ReaderWriterVRML2.cpp are the source of the prob). I will pass along a fix to Robert for that file. This is the same problem you would have when building the VRML lib anyway so it should be familiar...). VS2008 builds fine though. NOTE - I build boost and OpenVRML as DLLs, so the following instructions are for that configuration. WIN32 CMakeLists.txt changes I made amounted to replacing the IF(WIN32) clause with this: IF (WIN32) SET(TARGET_EXTERNAL_LIBRARIES Ws2_32.lib) add_definitions(-DBOOST_ALL_NO_LIB -DOPENVRML_USE_DLL) ENDIF(WIN32) SET(TARGET_LIBRARIES_VARS OPENVRML_LIBRARY) Hope that helps. Chuck Seberino On Oct 11, 2010, at 6:20 PM, Jean-Sébastien Guay wrote: Hello Alexander, First of all, don't worry about your English so much it is very good and much better than my German! :-) Second, I would like to request that in the future, you ask any OSG-related questions directly on the osg-users mailing list or on the forum at forum.openscenegraph.org. That way, others can also reply and other people who have the same problems/questions as you will benefit from the replies. So, on to your questions. You've got the first steps right, though for the basic dependencies of OSG (libpng, zlib, libjpeg, freetype etc.) you could have downloaded the appropriate 3rdparty package from openscenegraph.org and saved a bit of time (I assume you downloaded these libraries yourself individually, though you don't mention that specifically). Now i use this code to load a wrl-File: osg::ref_ptrosg::Node node = osgDB::readNodeFile(sample.wrl); This file from the tutorial is properly loaded, but if i replace the filename i.e. with Anchor.wrl (a file from the openVRML examples) no scene is displayed. I don't know these files specifically, but I think if you increase the OSG verbosity level it should tell you if there was any error while loading the file you asked it to load. To increase the verbosity, you can do on the command prompt: set OSG_NOTIFY_LEVEL=DEBUG or in your program's code, at the beginning of the main(), you could do: osg::setNotifyLevel(osg::DEBUG_FP); This will print lots of information about where OSG finds plugins, which OpenGL extensions are available, etc. and in all that information there should hopefully be a few messages from the OpenVRML loader telling you why the file couldn't load properly. It's possible the file contains some VRML that is not read/interpreted by the OSG VRML loader. I think the VRML loader only uses a subset of VRML and ignores the rest. Others will know more about this, I haven't done much with the VRML loader except compile it... And should i use a newer version of openVRML? Then how should i set up my system properly. (i already tried to compile the newest Version of OpenVRML without success). I think the OSG VRML loader cannot work with newer versions of OpenVRML at all, though again others will be able to give you more details. If this is a problem for you then you may want to get familiar with the OSG VRML loader's code and try to improve it yourself, contributing your changes back to OSG afterwards! My final task is to load wrl-Files and check if the wrl-file-standard is correct. After that the Scene is used in OSG by other people. You may have to work a bit on the VRML loader if that's your goal, since as I said I think it only loads a subset of VRML at present. Hope this helps, J-S On 10/11/2010 6:11 AM, Alexander Moeller wrote: Hi! My Name ist Alexander Moeller and i am from Germany (so please forgive my bad english). And i'm new to OSG. I programmed with C++ before, but not with such big librarys i have to compile by myself. I have same questions about OpenSceneGraph espacially reading .wrl Files. It will be nice if you can help me to solve these problems. I'm using Windows XP with Visual Studio Express 2008 Here are the steps i've done so far: -Downloading
Re: [osg-users] How Camera Manipulators Work
Guys, I just want to chime in here by saying that I have implemented something like this for some proprietary code I wrote. In my case, I am using Qt's signal/slot mechanism to perform the mapping between an input device (mouse, joystick[s], spacenavigator, etc) and an effect (camera manipulation, enable/disable featureX, ...). I created what I called a slotManager that is persistent and its sole purpose is to direct input devices to some desired action. Since it uses Qt's signal/slot mechanism, it doesn't require knowledge of the implementation particulars, just needs to be smart enough to fire off execution of the event. It works similar to an ORB, where you can publish and subscribe to events of your choosing. I have a front-end GUI that allows for device mapping and configuration for axes and buttons on a per-device basis. It works for me, but it can be seen as overkill for the majority of users. I suspect for the general user, the default classes would be close enough that only minor tweaking would be necessary to achieve the desired result. Coming up with something that does the same thing, but doesn't require Qt is also a good amount of work to make general purpose. I am just about to look into the latest (2.9.7) changes to camera manipulators to see if a thin Qt layer on top of the new classes would still satisfy my purposes. If so, then I might push some code out to the OSG community to utilize. So no direct help for you right away, but maybe something in the not-so-distant future. Regards, Chuck Seberino On Oct 8, 2010, at 12:58 PM, Jean-Sébastien Guay wrote: Hi Matt, Your view of how the system would work is probably very similar to what I had in mind. Thanks for the explanation, and yes it's very similar to what I was thinking too. How would you map the input (gotten by the GUIEventHandler) to calls to the manipulator's functions in a general way? Because you wouldn't want one handler per manipulator (that would be almost the same as what we have now, just more code and more spread out), or even to have if (flightmanip) flightmanip-pitch(val) else if (trackballmanip) trackballmanip-rotateY(val) else ... in the event handler (even worse than what we have now). I was talking about connections before, that kind of thing is a bit hard to design so that it's minimally intrusive and as general as possible at the same time... The interfaces I've seen that attempted to implement connections in a very general way had an extremely verbose API, and then you would get google-eyed when you'd look at the setup code and might miss typos and small bugs... I'm just asking by curiosity... You could just code up your solution and send it, and stop wasting time replying to my questions :-) . I have no authority over what gets committed in OSG. I just wanted to know what you have in mind. Also, J-S, I didn't really understand the point you were trying to make in your final paragraph: I would suggest that axes be mappable to either an analog axis (say mouse up/down or joystick y axis) or a pair of buttons (one for incrementing and one for decrementing the value). Well, sometimes you run out of axes but have buttons to spare, and you could map two buttons to do (digitally) what an analog axis would normally do. I know I could just subclass and do what I want, but I think it would be a cool feature. For example, you said pitch(force) would accept magnitudes [-1,1]. Then you'd map an axis on an analog stick on your joystick to send, say, pitch(X) where X would map [-1,1] to the [down,up] range. But say you had two buttons and wanted to do the same thing, you could have button A send pitch(0.5) and button B send pitch(-0.5) for example. I'm just saying that if you can connect some value to an analog input that takes a range, you should also be able to connect that value to two digital inputs that go up and down as well. That's classic in games, where say the left/right steering of a car can either map to a joystick axis, or to the left/right arrow keys on your keyboard. Geez, a long explanation for what's basically a detail that could have been added later... That's me. Sorry about that. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
Anders, It is somewhat relevant to OSG too, in that linking against osgDB and other code that uses fstream will cause similar 'multiple-defined' linker errors. This problem seems to be only with MSVC2010, the OS doesn't seem to matter (I use XP). osgDB is affected because of osgDB::fstream, which subclasses from std::fstream. The current workaround is to allow multiple symbols when linking. I would be interested in finding a better solution to this problem... Chuck On Aug 26, 2010, at 9:35 AM, Anders Backman wrote: Hi all. This is not related to OSG in any way, but as there so many experts on the list, I thought I should take the opportunity to ask this... I have a problem related to linking in VS2010. Im using VS2010 under Windows 7 (64). Im building a large source package which is divided into two separate libraries (dynamic linking: .lib, .dll). in the first library, a.lib we are using both std::stringstream and std::ostringstream. a.lib depends on other libraries, all built by myself using CMake and VS2010. CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). When I build the next library, b.lib, which depends on a.lib, I get the following linking errors: Linking of b.lib: 1a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_ostringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of std::ostringstream. And everything builds. Next, I try to use std::ostringstream in some other cpp file of the b.lib, so I just copy the code from ImageCapture.cpp into another .cpp file in b.lib, including the #include directives... It links just fine. One important thing to mention, all of this works just fine in VS2008. Next, I tried to change from std::ostringstream to std::stringstream in both a.lib AND b.lib. Now I get the same error, but instead its std::stringstream mentioned in the error message: 2a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_stringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj So, the situation is exactly the same, its just changed from std::ostringstream to std::stringstream. If I have just the right balance between stringstream and ostringstream, it builds. Then the problem occurs when I want to build a third library, depending on both a.lib AND b.lib... Then it starts all over. The next thing I did was to generate project files for vs2008, build with vs2008 (using dependencies built with vs2010), compiles/links just fine. Except it does not run (incompatible STL, crash in deque). Ok, so it builds in VS2008. Next was to build everything in vs2010 using the same project files. Then I get the above linking error. Im more and more leaning towards a bug in VS2010, but its really hard to verify... Anyone experienced this in VS2010? - ___ osg-users
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
In the application properties: Configuration Properties - Linker - General - Force File Output - Multiply Defined Symbol Only (/FORCE:MULTIPLE) Chuck On Aug 26, 2010, at 10:11 AM, Anders Backman wrote: How do you allow multiple symbols in VisualStudio? /A On Thu, Aug 26, 2010 at 6:51 PM, Chuck Seberino seber...@energid.org wrote: Anders, It is somewhat relevant to OSG too, in that linking against osgDB and other code that uses fstream will cause similar 'multiple-defined' linker errors. This problem seems to be only with MSVC2010, the OS doesn't seem to matter (I use XP). osgDB is affected because of osgDB::fstream, which subclasses from std::fstream. The current workaround is to allow multiple symbols when linking. I would be interested in finding a better solution to this problem... Chuck On Aug 26, 2010, at 9:35 AM, Anders Backman wrote: Hi all. This is not related to OSG in any way, but as there so many experts on the list, I thought I should take the opportunity to ask this... I have a problem related to linking in VS2010. Im using VS2010 under Windows 7 (64). Im building a large source package which is divided into two separate libraries (dynamic linking: .lib, .dll). in the first library, a.lib we are using both std::stringstream and std::ostringstream. a.lib depends on other libraries, all built by myself using CMake and VS2010. CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). When I build the next library, b.lib, which depends on a.lib, I get the following linking errors: Linking of b.lib: 1a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_ostringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of std::ostringstream. And everything builds. Next, I try to use std::ostringstream in some other cpp file of the b.lib, so I just copy the code from ImageCapture.cpp into another .cpp file in b.lib, including the #include directives... It links just fine. One important thing to mention, all of this works just fine in VS2008. Next, I tried to change from std::ostringstream to std::stringstream in both a.lib AND b.lib. Now I get the same error, but instead its std::stringstream mentioned in the error message: 2a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_stringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj So, the situation is exactly the same, its just changed from std::ostringstream to std::stringstream. If I have just the right balance between stringstream and ostringstream, it builds. Then the problem occurs when I want to build a third library, depending on both a.lib AND b.lib... Then it starts all over. The next thing I did was to generate project files for vs2008, build with vs2008 (using dependencies built with vs2010), compiles/links just fine. Except it does not run (incompatible STL
Re: [osg-users] Texture unit ID's conflicting
Paul, I think what Steve is trying to figure out is a way to run his shader without stepping on any existing textures loaded for a particular model. Steven - I don't know, but there might be a more generalized way to get the number of in-use textures for a scenegraph / node. My thought was that you can run a visitor after loading in your models to determine how many textures are used. Then you can set your shaders to 2 available ones. Or pick high numbers (6,7) that have a high probability of not being used. Chuck On Aug 23, 2010, at 12:09 PM, Paul Martz wrote: Steven Powers wrote: In practice, I'm creating 2 textures and storing shader relevant data in them. I'm assigning them to the state set using setTextureAttributeAndModes(1,...) and setTextureAttributeAndModes(2,...) but some objects in the scene must also have textures defined for these texture units. Are you also setting up corresponding sampler uniforms? This causes an override of the data I've assigned to texture unit 1 and 2. Is there a way to keep this from happening? If some higher-level parent node assigns a texture to unit 1, and somewhere in a subgraph, another node assigns a different texture to unit 1, then by default the child subgraph's texture gets used. You can change this behavior, to some extent, by specifying the OVERRIDE mode when you set the higher-level parent node's texture StateAttribute. Aspects of state inheritance are well-documented in the Quick Start Guide. -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] cmake errors with 2.9.8
John, There have been a lot of OSX-specific updates to cmake between your version and the latest. 2.4.7 is so old that it doesn't even recognize the FRAMEWORK argument, let alone do the right thing with it (ignore in your case). Upgrading cmake will solve your problems. Chuck On Jul 15, 2010, at 1:18 PM, John Kelso wrote: Hi all, I just tried build OSG 2.9.8 on our CentOS system, using cmake 2.4.7. My cmake command gave me errors. The main thing I see are lines like this: CMake Error: Error in cmake code at .../OpenSceneGraph-2.9.8/CMakeModules/ModuleInstall.cmake:28: INSTALL TARGETS given unknown argument FRAMEWORK. Line 28 of the file has: FRAMEWORK DESTINATION /Library/Frameworks We're not using OS X. Any idea what's going wrong? I suspect it's something simple. More gory details on request. Thanks, John ___ 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] osg latest developer release, memory leak under linux
Pawel, You can always do something like this: make VERBOSE=1 from the command-line when building to see the details of what CMake is doing. You can then see what flags are being passed to the compiler. Chuck On May 12, 2010, at 1:56 PM, Paweł Góralski wrote: Mathias Fröhlich wrote: Hi, I can see three possibilities: * Your compile flags containe -march=i386 or (may be this is also sufficient to trigger this, -march=i486). * The compiler you used is may be hand compiled and has a default architecture of -march=i386. * The gcc in fedora 10 has still a default instruction set architecture of -march=i386. Where I can check those flags? Cmake isn't displaying any information about flags is using during build process. I've looked through the Makefiles generated by CMake and I haven't seen any additional CFLAGS settings. So if -march=i386 is set by gcc 4.3.3 by default under FC10 then this is very good explanation why this GCC BUILTINS test fails. Anyway I've rebuild the osg with Matthias Frohlig patches and it seems that leaking doesn't occur and everything looks stable now, Thanks. But as Robert stated before CMake isn't setting correct architecture under FC10. I will look into it tomorrow. Anyway thanks everyone for help. :) Regards, Pawel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27828#27828 ___ 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] osgDB Serialization optimization for double getter
Wang et al,
I was looking through the output of one of my serializers and noticed that when
writing out in ascii, it performs two instances of the get method. Here is a
snippet from the string serializer in osgDB/Serializer:
448 virtual bool write( OutputStream os, const osg::Object obj )
449 {
450 const C object = OBJECT_CASTconst C(obj);
451 if ( os.isBinary() )
452 {
453 os (object.*_getter)();
454 }
455 else if ( ParentType::_defaultValue!=(object.*_getter)() )
456 {
457 os PROPERTY((ParentType::_name).c_str());
458 os.writeWrappedString( (object.*_getter)() );
459 os std::endl;
460 }
461 return true;
462 }
The (object.*getter)() method call, at least in my case, is a non-trivial
accessor. It gets called on line 455 as well as 458. What do you think about
adding a temporary between line 450-451 like so:
448 virtual bool write( OutputStream os, const osg::Object obj )
449 {
450 const C object = OBJECT_CASTconst C(obj);
const std::string value = (object.*_getter)();
451 if ( os.isBinary() )
452 {
453 os value;
454 }
455 else if ( ParentType::_defaultValue!=value )
456 {
457 os PROPERTY((ParentType::_name).c_str());
458 os.writeWrappedString( value );
459 os std::endl;
460 }
461 return true;
462 }
I suppose line 450 and my additional line could be squashed to a single
expression, but you get the idea. This will reduce it to a single accessor in
the ascii case. This same conversion can be used throughout the rest of the
serializers as well.
I know you are making changes to some of the serialization code to support
other classes. Let me know if you want me to submit a patch, or if you want to
do this and roll it up with other changes you are making.
Thanks
Chuck___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDB Serialization findings
Wang and others,
One other item I forgot to mention that also tripped me up. Be careful with
the use of osgUtil::Optimizer with custom serialization classes. Certain nodes
(Group, MatrixTransform, etc) can be removed, replaced and/or reordered through
optimization. If you subclass any of them, they could be swapped out with a
non-subclassed instance. Again one of those things that could cause you to
spend (way too much) time scratching your head on why things aren't working.
Thank you Wang for this serialization support. It is just what I needed to
embed my special sauce into files for use later.
Chuck
On Apr 15, 2010, at 5:28 PM, Wang Rui wrote:
Hi Chuck,
Thanks for the useful information. Hope it could be added to the wiki
page, as a good supplement of my origin serializer tutorial which is
written unpolished and in a hurry. :)
I'm still waiting for decision of the submitted osgAnimation
serializers. After that I'll continue completing other core library
wrappers and have a taste to support the introspection mechanism,
which would be a lightweight replacement of osgIntrospection.
Cheers,
Wang Rui
2010/4/16 Chuck Seberino seber...@energid.org:
I have been playing around with the new serialization support with 2.9.7 and
wanted to share some of my findings. I think some of these might be useful
for others looking to do the same.
1. Serialization support *requires* that you override the virtual methods
for className() and libraryName(). If you don't, then things won't
serialize properly and you might spend *LOTS* of time trying to figure out
why...
2. You can provide serialization for a class that doesn't live in a
namespace. Just specify global namespace.
REGISTER_OBJECT_WRAPPER(NoNamespaceClass,
new NoNamespaceClass,
::NoNamespaceClass,
osg::Object osg::Node ::NoNamespaceClass) { ... }
3. As long as you have item 1. you can still serialize a class without
adding in additional accessors and mutators. This is useful if you have a
class that you can't or don't want to change to add in the necessary set/get
methods to satisfy serialization. A wrapper class can be created to do this
for you.
// Class that we don't want to expose get/set
class NoGetSetClass : public osg::Node
{
public:
...
virtual const char* className() const { return NoGetSetClass; } // name
to match
virtual const char* libraryName() const { return ; }// no
namespace
protected:
std::string _internalVariable;
};
// Helper class that is used just for serialization purposes
class SerializerForNoGetSetClass : public NoGetSetClass
{
public:
...
const std::string getVariable() const { return _internalVariable; }
void setVariable(const std::string str) { _internalVariable = str; }
};
REGISTER_OBJECT_WRAPPER(NoGetSetClass, // Old name because
this is what we match against
new SerializerForNoGetSetClass, // Use helper class
for get/set
::NoGetSetClass,
osg::Object osg::Node ::NoGetSetClass)
{
// Manually recreate macro to specify our serializer subclass
wrapper-addSerializer(new
osgDB::StringSerializerSerializerForNoGetSetClass(Variable, default,
SerializerForNoGetSetClass::getVariable,
SerializerForNoGetSetClass::setVariable));
}
The macros for ADD_*_SERIALIZER can't be used because we want to use our
subclass instead of the original class we want serialized. When the
serialization code is invoked, it matches the class type and classname
properly with the old class, but constructs an instance of
SerializerForNoGetSetClass to push and pull values.
4. You can specify more than one REGISTER_OBJECT_WRAPPER statement in a
single compilation unit. The macro creates a typedef (typedef CLASS
MyClass) that is used for the subsequent serialization commands. Calling
the macro more than once will cause it to complain about the redefinition of
MyClass. Since the purpose of the macro is to statically register a
wrapper, it can be guarded by a namespace and still function just fine.
// This macro creates a typedef
REGISTER_OBJECT_WRAPPER(Class1,
new Class1,
::Class1,
osg::Object ::Class1)
{
// We only require the typedef to be valid in here
...
}
// The typedef is still available here
namespace { // Now this macro doesn't conflict with previous macro typedef
REGISTER_OBJECT_WRAPPER(Class2,
new Class2,
::Class2,
osg::Object ::Class2)
{
...
// The new typedef takes precedence because of namespace scope
}
} // namespace
Hopefully these nuggets of information will help
[osg-users] osgDB Serialization findings
I have been playing around with the new serialization support with 2.9.7 and
wanted to share some of my findings. I think some of these might be useful for
others looking to do the same.
1. Serialization support *requires* that you override the virtual methods for
className() and libraryName(). If you don't, then things won't serialize
properly and you might spend *LOTS* of time trying to figure out why...
2. You can provide serialization for a class that doesn't live in a namespace.
Just specify global namespace.
REGISTER_OBJECT_WRAPPER(NoNamespaceClass,
new NoNamespaceClass,
::NoNamespaceClass,
osg::Object osg::Node ::NoNamespaceClass) { ... }
3. As long as you have item 1. you can still serialize a class without adding
in additional accessors and mutators. This is useful if you have a class that
you can't or don't want to change to add in the necessary set/get methods to
satisfy serialization. A wrapper class can be created to do this for you.
// Class that we don't want to expose get/set
class NoGetSetClass : public osg::Node
{
public:
...
virtual const char* className() const { return NoGetSetClass; } // name to
match
virtual const char* libraryName() const { return ; }// no
namespace
protected:
std::string _internalVariable;
};
// Helper class that is used just for serialization purposes
class SerializerForNoGetSetClass : public NoGetSetClass
{
public:
...
const std::string getVariable() const { return _internalVariable; }
void setVariable(const std::string str) { _internalVariable = str; }
};
REGISTER_OBJECT_WRAPPER(NoGetSetClass, // Old name because
this is what we match against
new SerializerForNoGetSetClass, // Use helper class for
get/set
::NoGetSetClass,
osg::Object osg::Node ::NoGetSetClass)
{
// Manually recreate macro to specify our serializer subclass
wrapper-addSerializer(new
osgDB::StringSerializerSerializerForNoGetSetClass(Variable, default,
SerializerForNoGetSetClass::getVariable,
SerializerForNoGetSetClass::setVariable));
}
The macros for ADD_*_SERIALIZER can't be used because we want to use
our subclass instead of the original class we want serialized. When the
serialization code is invoked, it matches the class type and classname properly
with the old class, but constructs an instance of SerializerForNoGetSetClass to
push and pull values.
4. You can specify more than one REGISTER_OBJECT_WRAPPER statement in a single
compilation unit. The macro creates a typedef (typedef CLASS MyClass) that is
used for the subsequent serialization commands. Calling the macro more than
once will cause it to complain about the redefinition of MyClass. Since the
purpose of the macro is to statically register a wrapper, it can be guarded by
a namespace and still function just fine.
// This macro creates a typedef
REGISTER_OBJECT_WRAPPER(Class1,
new Class1,
::Class1,
osg::Object ::Class1)
{
// We only require the typedef to be valid in here
...
}
// The typedef is still available here
namespace { // Now this macro doesn't conflict with previous macro typedef
REGISTER_OBJECT_WRAPPER(Class2,
new Class2,
::Class2,
osg::Object ::Class2)
{
...
// The new typedef takes precedence because of namespace scope
}
} // namespace
Hopefully these nuggets of information will help anyone else trying to get
their own custom classes to serialize properly without pulling out too much
hair. For those that don't know it, this wiki link is a good starting point
http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/SerializationSupport
Regards,
Chuck Seberino
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSX image library support for 64-bit
In the toplevel CMakeLists.txt there is this clause(line 497-512) to remove the check for certain image libraries on OSX. # Image readers/writers depend on 3rd party libraries except for OS X which # can use Quicktime. IF(NOT APPLE) FIND_PACKAGE(GIFLIB) FIND_PACKAGE(JPEG) FIND_PACKAGE(PNG) FIND_PACKAGE(TIFF) # QuickTime is required for OS X, but optional for Windows. IF(WIN32) FIND_PACKAGE(QuickTime) ENDIF() ELSE() FIND_PACKAGE(QuickTime) ENDIF() The problem is that when compiling with 64-bit support, we need to use imageio instead of quicktime. There is a comment in there that talks about 2 approaches. # Platform specific: # (We can approach this one of two ways. We can try to FIND everything # and simply check if we found the packages before actually building # or we can hardcode the cases. The advantage of the former is that # packages that are installed on platforms that don't require them # will still get built (presuming no compatibility issues). But this # also means modules that are redundant may get built. For example, # OS X doesn't need GIF, JPEG, PNG, TIFF, etc because it uses QuickTime. # Also, it will clutter the CMake menu with NOT_FOUND. # The downside to the latter is that it is harder to build those # potentially redundant modules.) I would like to propose we switch to the former approach. I can see 64-bit compilation being more prevalent going forward. Thoughts? Chuck___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] openGL flavors and vendors...
Chris, I just did a quick search on this website: http://www.gpureview.com/database.php Looking at a few cards from ATI and NVIDIA, it looks like they put out OpenGL 2.0 compliant cards around late 2002/ early 2003. Intel chips are a different story. You would need a G35 or better chipset in order to get 2.0 support. That is only about a 3 year old chip. So you are pretty safe on 2.0 if the target hardware is ATI or NVIDIA, but less so if you venture into integrated chipsets from Intel. Of course that assumes that the OS and drivers loaded onto said system are not ancient beasts. HTH Chuck On Mar 26, 2010, at 11:27 AM, Chris Chan wrote: Hi, I'm coding an OSG / OpenGL-based renderer, and trying to figure out what percentage of machines out there support OpenGL 2.0, (as well as ES 2.0 on mobiles). I thought there must be resources or databases out there for that kind of info, but couldn't find any. My target is to release it by the end of 2010. Anecdotally, I recently bought a Fujitsu Tablet PC a few months ago, albeit a 2008/9 model, but the driver was still at GL 1.2. I had to search Intel's site to get a non-Fujitsu-sanctioned driver that bumped GL up to 2.0. My target audience is not necessarily the video game crowd, so I don't know if having general users search around for driver updates is feasible. Thanks, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26206#26206 ___ 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] OSX image library support for 64-bit
the libpath message has been reported before)
ENDIF()
# This needs to be run very last so other parts of the scripts can take
# advantage of this.
IF(NOT OSG_CONFIG_HAS_BEEN_RUN_BEFORE)
SET(OSG_CONFIG_HAS_BEEN_RUN_BEFORE 1 CACHE INTERNAL Flag to track whether
this is the first time running CMake or if CMake has been configured before)
ENDIF()
#-
### uninstall target
#-
CONFIGURE_FILE(
${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/cmake_uninstall.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake
IMMEDIATE @ONLY)
ADD_CUSTOM_TARGET(uninstall
${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
ThanksChuckOn Mar 26, 2010, at 11:25 AM, Chuck Seberino wrote:In the toplevel CMakeLists.txt there is this clause(line 497-512) to remove the check for certain image libraries on OSX.# Image readers/writers depend on 3rd party libraries except for OS X which# can use Quicktime.IF(NOT APPLE) FIND_PACKAGE(GIFLIB) FIND_PACKAGE(JPEG) FIND_PACKAGE(PNG) FIND_PACKAGE(TIFF) # QuickTime is required for OS X, but optional for Windows. IF(WIN32) FIND_PACKAGE(QuickTime) ENDIF()ELSE() FIND_PACKAGE(QuickTime)ENDIF()The problem is that when compiling with 64-bit support, we need to use imageio instead of quicktime. There is a comment in there that talks about 2 approaches.# Platform specific:# (We can approach this one of two ways. We can try to FIND everything# and simply check if we found the packages before actually building# or we can hardcode the cases. The advantage of the former is that# packages that are installed on platforms that don't require them# will still get built (presuming no compatibility issues). But this# also means modules that are redundant may get built. For example,# OS X doesn't need GIF, JPEG, PNG, TIFF, etc because it uses QuickTime.# Also, it will clutter the CMake menu with "NOT_FOUND".# The downside to the latter is that it is harder to build those# potentially redundant modules.)I would like to propose we switch to the former approach. I can see 64-bit compilation being more prevalent going forward.Thoughts?Chuck___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 testing
Andy and Paul - I submitted a fix for this (r10927) which reorders some of the ifdef checking so that it works properly under OSX. Chuck On Mar 22, 2010, at 9:47 AM, Andy Skinner wrote: I just got OpenSceneGraph-2.8, and tried to build on OS X. I'm getting an error in OpenThreads/Atomic, complaining that int32_t does not name a type. I'm following the unix instructions, doing configure and then make. I had just build the trunk (at least the first part) and got past this. Have I got it set up incorrectly, or is there a problem on 2.8? thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Monday, March 22, 2010 12:31 PM To: OpenSceneGraph Users Subject: [osg-users] 2.8.3 testing Hi all -- Here's an update on the 2.8.3 release, and a plea for testing. The 2.8.3 release is slightly behind my original schedule, but nonetheless getting close to a release candidate. ISSUES: There are two open issues at this point: 1. XCode project files need to be updated. (Stephan, will you have any time to contribute this in the near future, or do we need another volunteer?) 2. Updates to the DAE plugin and osgManipulators nodekit. These are late feature requests. I'm concerned about updating these two modules. The changes for both these modules are not limited to the modules themselves, and require changes to core OSG and elsewhere. Many changes on trunk often depend on previous changes, and chasing all of them down with a high level of confidence is difficult. It would certainly introduce issues if I missed any required changes. Let me make this suggestion: Let's leave DAE and osgManipulators out of the 2.8.3 release. If someone really wants them, and can't wait for v2.10 (or v3.0), then we could do a 2.8.4 release. The benefit of this approach is that it doesn't prevent 2.8.3 from getting out the door in a timely fashion, should merging these changes produce instability that would otherwise delay the release. Does this make sense? TESTING: Please test the 2.8 branch if you have time. For convenience, here's the 2.8 branch URL: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenScene Graph-2.8 I'd appreciate build/run testing for the following platforms and features: Platforms: Mac 10.5/10.6 32/64bit Windows XP/Vista/7, 32/64bit *nix, 32/64bit Features (latest stuff from trunk): osgAnimation nodekit FBX plugin 3ds plugin (esp writer capability) ImageIO plugin QuickTime plugin Inventor plugin ply plugin ffmpeg plugin There were also minor bug fixes to the 3dc, ac, dds, and flt plugins. When you send a test report, please mention which plugins you are building, as not all plugins build by default of course. Once we get the XCode project files updated, I'll tag a release candidate, and further candidates will follow as needed. I'm still hoping for a 31 March release date. If we start testing now, this should give us plenty of time for testing and resolving issues. Thanks! -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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 testing
Andy, The fix is in trunk, but hasn't been merged into the 2.8 branch yet. Chuck On Mar 22, 2010, at 10:44 AM, Andy Skinner wrote: Does that mean I need to wait for it to get onto 2.8? Or that it is there? thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Chuck Seberino Sent: Monday, March 22, 2010 1:00 PM To: OpenSceneGraph Users Subject: Re: [osg-users] 2.8.3 testing Andy and Paul - I submitted a fix for this (r10927) which reorders some of the ifdef checking so that it works properly under OSX. Chuck On Mar 22, 2010, at 9:47 AM, Andy Skinner wrote: I just got OpenSceneGraph-2.8, and tried to build on OS X. I'm getting an error in OpenThreads/Atomic, complaining that int32_t does not name a type. I'm following the unix instructions, doing configure and then make. I had just build the trunk (at least the first part) and got past this. Have I got it set up incorrectly, or is there a problem on 2.8? thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Monday, March 22, 2010 12:31 PM To: OpenSceneGraph Users Subject: [osg-users] 2.8.3 testing Hi all -- Here's an update on the 2.8.3 release, and a plea for testing. The 2.8.3 release is slightly behind my original schedule, but nonetheless getting close to a release candidate. ISSUES: There are two open issues at this point: 1. XCode project files need to be updated. (Stephan, will you have any time to contribute this in the near future, or do we need another volunteer?) 2. Updates to the DAE plugin and osgManipulators nodekit. These are late feature requests. I'm concerned about updating these two modules. The changes for both these modules are not limited to the modules themselves, and require changes to core OSG and elsewhere. Many changes on trunk often depend on previous changes, and chasing all of them down with a high level of confidence is difficult. It would certainly introduce issues if I missed any required changes. Let me make this suggestion: Let's leave DAE and osgManipulators out of the 2.8.3 release. If someone really wants them, and can't wait for v2.10 (or v3.0), then we could do a 2.8.4 release. The benefit of this approach is that it doesn't prevent 2.8.3 from getting out the door in a timely fashion, should merging these changes produce instability that would otherwise delay the release. Does this make sense? TESTING: Please test the 2.8 branch if you have time. For convenience, here's the 2.8 branch URL: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenScene Graph-2.8 I'd appreciate build/run testing for the following platforms and features: Platforms: Mac 10.5/10.6 32/64bit Windows XP/Vista/7, 32/64bit *nix, 32/64bit Features (latest stuff from trunk): osgAnimation nodekit FBX plugin 3ds plugin (esp writer capability) ImageIO plugin QuickTime plugin Inventor plugin ply plugin ffmpeg plugin There were also minor bug fixes to the 3dc, ac, dds, and flt plugins. When you send a test report, please mention which plugins you are building, as not all plugins build by default of course. Once we get the XCode project files updated, I'll tag a release candidate, and further candidates will follow as needed. I'm still hoping for a 31 March release date. If we start testing now, this should give us plenty of time for testing and resolving issues. Thanks! -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 ___ 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] Playing smoothly a big video
Serge, One other item that hasn't been explicitly mentioned yet is pixel packing. You want to make sure that the graphics card does as little with the source image as possible to get it into the OpenGL pipeline. Make sure that your on-disk pixel format is something that is on the fast path. Storing data as 24-bit RGB is not a good choice as it is not aligned. BGRA is your best bet as it is about the fastest pixel format on nvidia hardware. Chuck On Mar 10, 2010, at 8:43 AM, Robert Osfield wrote: Hi Serge, On Wed, Mar 10, 2010 at 4:29 PM, Serge Lages serge.la...@gmail.com wrote: We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Do you need 4 contexts? If you have one card I would typically try to run it with a single context across all outputs. With two graphics cards you wouldn't be able to do this, but still I'd opt for two graphics contexts, one per card. This does assume that your OS of choice actually supports driving the graphics cards efficiently... Perhaps one solution you could go for is to have four textures that each have their own osg::Image, but each osg::Image points to a different point in the larger osg::Image. If you place render the video as four images down, one wide, rather than four wide and one down then you'd be able to use a simple pointer offset into the osg::Image that ffmpeg is writing to. Using this approach you could avoid major cache misses, and avoid the need for sharing a single big texture. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] automatic pixel transparency adjustment
Guy, One option that I have used in the past is to use super-sampling. You would render your scene at a higher resolution, and then perform any variation of averaging or weighting you want as you scale it down to the final size. This will help to make sure sub-pixel objects contribute to the final rendered image. One of my previous implementations just rendered a specific node geometry by itself at a high resolution and then scaled/blended it in with the rest of the scene. HTH Chuck On 9 March 2010 14:32, Guy g...@dvp.co.il wrote: Hi, thanks, I've just read that SMOOTH isn't supported since several years ago. It is important since this is physically correct that even objects which are very small, does contribute to the pixel color. Is it possible to calculate the pixel coverage or get it in a shader? That would be a good solution. Does anyone know how Multi-sampling is implemented algorithmically? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenThreads/Atomic patch for OSX
I have a patch to submit that fixes the following error when building against OSX 10.6.2. I am building the 2.9.6 dev tag, but I also checked it against trunk. I am building fat binaries (i386 and x86_64): /OpenSceneGraph-2.9.6/include/OpenThreads/Atomic:70: error: 'int32_t' does not name a type /OpenSceneGraph-2.9.6/include/OpenThreads/Atomic: In constructor 'OpenThreads::Atomic::Atomic(unsigned int)': /OpenSceneGraph-2.9.6/include/OpenThreads/Atomic:50: error: class 'OpenThreads::Atomic' does not have any field named '_value' --- Atomic.orig 2009-12-15 09:53:51.0 -0800 +++ Atomic 2009-12-15 09:55:02.0 -0800 @@ -17,17 +17,17 @@ #include OpenThreads/Config #include OpenThreads/Exports -#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS) defined(__i386__) -#define _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES +#if defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC) +# include libkern/OSAtomic.h +# define _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES +#elif defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS) defined(__i386__) +# define _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES #elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED) -#define _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES +# define _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES #elif defined(_OPENTHREADS_ATOMIC_USE_SUN) # include atomic.h # include Mutex # include ScopedLock -#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC) -# include libkern/OSAtomic.h -# define _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES #elif defined(_OPENTHREADS_ATOMIC_USE_MUTEX) # include Mutex # include ScopedLock The problem is that there were two clauses in these conditionals that applied to my configuration. I moved the more-specific case, _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC, ahead of the more general _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS __i386__. This allowed it to correctly pull in libkern/OSAtomic.h which subsequently pulled in stdint.h to define int32_t. I don't know for sure, but I guess there might be a case where a similar situation could happen with the *_USE_SUN clause where a Sun system might also take the GCC/i386 path instead. Thanks Chuck Seberino___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
