Re: [osg-users] OSG 3.2.1 QuickTime plug-in doesn't compile on Windows
Hi Émeric, Apple likes moving the goal posts on all it's API which makes it difficult to compile on all variants of their API's all the time. Under Windows you can use the native directshow plugin or the ffmpeg plugin. Robert. On 23 September 2014 23:10, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi, Just to be sure: is it expected that the OSG 3.2.1 QuickTime plug-in doesn't compile on Windows (lots of errors in MacTypes.h for example) with the latest QuickTime 7.3 SDK for Windows? Am I right to suppose that the codebase has been updated to build on OS X with today's QuickTime/QTKit, but since Apple killed the plug on Windows [1], the QuickTime plug-in doesn't compile anymore there? Is thus FFmpeg the way to go on Windows (and Linux) for .mov samples for example? Thanks, Émeric [1] https://karaoke.kjams.com/wiki/Blog/Apple_Abandons_QT_Win ___ 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] [osgPlugins] Bad Freetype font displaying
Hello!
I've updated from version 3.0.1 to version 3.2.1. I'm testing it but everything
seems fine except for the Freetype plugin.
I want to display text using the Arial font. OSG seems to find the font and
load the freetype plugin, but the text displaying is cubic.
With version 3.0.1 the text looks fine.
I've uploaded two pics to show the problem.
Any help will be appreciated.
-- CODE
Code:
const char* font_name = arial.ttf;
const std::string found = osgText::findFontFile( font_name );
osg::ref_ptrosgText::Font font = osgText::readFontFile( found );
qDebug() FOUND: found.c_str();
if( !font.valid() ) {
qDebug() WARNING! COULDN'T FIND FONT: font_name;
font = osgText::Font::getDefaultFont();
}
PS: I've checked and this time I'm not mixing debug and release libraries.
Target platform: Windows 8.1 64 bit
Compiler: MinGW 4.5 64 bit
---
Thanks and cheers,
Andrés.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61137#61137
Attachments:
http://forum.openscenegraph.org//files/osg32_430.png
http://forum.openscenegraph.org//files/osg301_220.png
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgUtil::PositionalStateContainer::AttrMatrixList from the currentRenderStage
Hi Robert, Community,
this will be hard to be described I guess, but I will try. Will make a
video as well later.
I am doing something with lights and in a CullCallback I do computation of
some light attribs for a shader. This something is splitting the
computation between the CPU and the GPU for lighting purposes.. And I am
doing sort of my LOD within this CullCallback. so the lights are not active
after a distance. And it works great but my cull time is really high so I
am about to optimize it with an LOD (just a try). My scenegraph is like:
root-MatrixTransform-LightSource
and again it works ok as long as I add LOD between the transform and the
lightsource.
Honestly, I have no clue what is going on. The final result is as I am
getting close to the LOD switch out distance the lights are changing
position, intensity and they fade away.instead of just switch out on that
distance.
Since I am using the osgUtil::PositionalStateContainer::AttrMatrixList from
the currentRenderStage (snippet bellow) and I am using the matrices from
there for the osg::Light attributes something is telling me that these
matrices are somewhat wrong when LOD is in the scene path. But again this
is only guessing
I am aware that based on written above it is hard to give a hint and I had
big doubts to post this really, but just in case maybe someone will have an
idea.
Thanks a bunch as always
Nick
snippet from the cullcallback:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor * cv = dynamic_castosgUtil::CullVisitor*(nv);
osgUtil::PositionalStateContainer::AttrMatrixList aml =
originalRenderStage-getPositionalStateContainer()-getAttrMatrixList();
// here I iterate over the list and after I use the osg::Light attrib
with its associated matrix to compute stuff for the shader
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil::PositionalStateContainer::AttrMatrixList from the currentRenderStage
Hi again,
here I managed to make some videos. The first one is without LOD in the
scene the second one is with LOD in the scene
Thanks a lot for any hint!
Nick
https://dl.dropboxusercontent.com/u/91101321/ll-1.mov
https://dl.dropboxusercontent.com/u/91101321/ll-2.mov
On Wed, Sep 24, 2014 at 2:28 PM, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi Robert, Community,
this will be hard to be described I guess, but I will try. Will make a
video as well later.
I am doing something with lights and in a CullCallback I do computation of
some light attribs for a shader. This something is splitting the
computation between the CPU and the GPU for lighting purposes.. And I am
doing sort of my LOD within this CullCallback. so the lights are not active
after a distance. And it works great but my cull time is really high so I
am about to optimize it with an LOD (just a try). My scenegraph is like:
root-MatrixTransform-LightSource
and again it works ok as long as I add LOD between the transform and the
lightsource.
Honestly, I have no clue what is going on. The final result is as I am
getting close to the LOD switch out distance the lights are changing
position, intensity and they fade away.instead of just switch out on that
distance.
Since I am using the osgUtil::PositionalStateContainer::AttrMatrixList
from the currentRenderStage (snippet bellow) and I am using the matrices
from there for the osg::Light attributes something is telling me that these
matrices are somewhat wrong when LOD is in the scene path. But again this
is only guessing
I am aware that based on written above it is hard to give a hint and I had
big doubts to post this really, but just in case maybe someone will have an
idea.
Thanks a bunch as always
Nick
snippet from the cullcallback:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor * cv = dynamic_castosgUtil::CullVisitor*(nv);
osgUtil::PositionalStateContainer::AttrMatrixList aml =
originalRenderStage-getPositionalStateContainer()-getAttrMatrixList();
// here I iterate over the list and after I use the osg::Light attrib
with its associated matrix to compute stuff for the shader
--
trajce nikolov nick
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.2.1 QuickTime plug-in doesn't compile on Windows
Hi Robert, Apple likes moving the goal posts on all it's API which makes it difficult to compile on all variants of their API's all the time. I've no problem with this. I only wanted to be sure that the breakage with the QuickTime plug-in on Windows is under control and expected. As for the OpenVRML plug-in. While the Visual Studio plug-ins webpage contains outdated information (hence my other post with a step-by-step OpenVRML plug-in HOWTO), a quick look at OSG SVN logs clearly states that the codebase was updated to work with OpenVRML 0.18.x and no more 0.14.x. I can't find the same explicit log for the QuickTime plug-in. Something saying QuickTime SDK deprecated by Under Windows you can use the native directshow plugin or the ffmpeg plugin. Does it mean that both the QuickTime and Xine plug-ins are deprecated on Windows? It seems to me that the FFmpeg plug-in provides the missing bits. Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Bad Freetype font displaying
HI Andres,
Does the osgtext example work fine?
Does the error only occur in your own application?
Robert.
On 24 September 2014 13:02, Andrés Barrionuevo abarrionu...@gmx.com wrote:
Hello!
I've updated from version 3.0.1 to version 3.2.1. I'm testing it but
everything seems fine except for the Freetype plugin.
I want to display text using the Arial font. OSG seems to find the font
and load the freetype plugin, but the text displaying is cubic.
With version 3.0.1 the text looks fine.
I've uploaded two pics to show the problem.
Any help will be appreciated.
-- CODE
Code:
const char* font_name = arial.ttf;
const std::string found = osgText::findFontFile( font_name );
osg::ref_ptrosgText::Font font = osgText::readFontFile( found );
qDebug() FOUND: found.c_str();
if( !font.valid() ) {
qDebug() WARNING! COULDN'T FIND FONT: font_name;
font = osgText::Font::getDefaultFont();
}
PS: I've checked and this time I'm not mixing debug and release libraries.
Target platform: Windows 8.1 64 bit
Compiler: MinGW 4.5 64 bit
---
Thanks and cheers,
Andrés.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61137#61137
Attachments:
http://forum.openscenegraph.org//files/osg32_430.png
http://forum.openscenegraph.org//files/osg301_220.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
[osg-users] why the eye separation changed?
Dear all, I used the stereo mode in my osg program, and the trackball camera manipulator. But when I try to zoom nearer to the object, the mouse wheel and the right-key operation get different results. Using the right key (mouse) to zoom, it seemed that the eye separation changed bigger, and this make Physical discomfort. Using the mouse wheel to zoom, the result is right. I just want to find the reason, because the eye separation problem lead to some other trouble. Can someone give me some suggestions. Thanks. whu___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] why the eye separation changed?
Hi Whu, The TrackballManipulator operates in a mode where the virtual eye separation is scaled relative to the distance between the eye point and center of rotation. This approach allows one to move around objects of completely different scales i.e. whole earth or a single molecule and they will sit centered on screen and with a comfortable eye separation. While this approach can be convenient and feel natural it's artificial, in the real world our eyes don't actually work this this. However, even with it being an artificial way to manage eye separation it works really nicely for a wide range of tasks. However, it isn't a solution that can work in all situations all the time. In the case when you zoom in right in close to the center of rotation the TrackballManipulator has to contend with another problem that is specific to manipulators that more around a central point. If you keep zooming in so the look distance is close to zero and if you do nothing about this basically for all intents and purposes the eye point stops and the manipulator then becomes very unnatural to use as the end user isn't aware that the look distance is now near zero. A work around to this problem is to change the zoom in behaviour when you get really close to the central point, so rather then keeping on reducing the look distance you maintain the look distance and push the central point away from the eye. This workaround is a bit crude but it prevents the worst of artefacts associated with the look distance tending to zero. When this work around is applied the virtual eye separation will stop reducing further so this will be a small discontinuity in behaviour. From your description it sounds like the mouse wheel modification of the look distances doesn't have this workaround in place, which itself could lead to problems if one then tries to pan, or rotate around the very close central point, the stereo offsets would also differ to how the mouse button drive zoom in behaves. Is there a solution to this problem? Well basically you shouldn't keep zooming in as you simply can't keep a trackball working seamlessly with very small look distances, it's not a case of bugs, it's a case of a fundamental limitation with using trackballs when you zoom in too far towards the central point things start going wrong and you have to come up with workarounds not matter what you do. In your own application you might be want it behave in a way that makes sense for you application, what this might be I cannot say as I have absolutely no clue about your usage model. You are completely free to implement your own camera manipulation and management of eye separation and if the off the shelf functionality doesn't do exactly what you want then go ahead a roll your own. Robert. On 24 September 2014 15:12, whu wyg030...@163.com wrote: Dear all, I used the stereo mode in my osg program, and the trackball camera manipulator. But when I try to zoom nearer to the object, the mouse wheel and the right-key operation get different results. Using the right key (mouse) to zoom, it seemed that the eye separation changed bigger, and this make Physical discomfort. Using the mouse wheel to zoom, the result is right. I just want to find the reason, because the eye separation problem lead to some other trouble. Can someone give me some suggestions. Thanks. whu ___ 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] Override DICOM plug-in CMAKE_SHARED_LINKER_FLAGS
Hi,
Building OSG 3.2.1 DICOM plug-in on a Windows XP x64 PC with Visual
Studio 2010 fails at link with the following error:
67osgDB.lib(osg100-osgDB.dll) : error LNK2005: public: void __cdecl
std::basic_ifstreamchar,struct std::char_traitschar ::`vbase
destructor'(void)
(??_D?$basic_ifstream@DU?$char_traits@D@std@@@std@@QEAAXXZ) already
defined in dcmimgle.lib(didispfn.obj)
67osgDB.lib(osg100-osgDB.dll) : error LNK2005: public: __cdecl
std::basic_ifstreamchar,struct std::char_traitschar
::basic_ifstreamchar,struct std::char_traitschar (char const
*,int,int) (??0?$basic_ifstream@DU?$char_traits@D@std@@@std@@QEAA@PEBDHH@Z)
already defined in dcmimgle.lib(didispfn.obj)
67 Creating library
C:/OpenSceneGraph/OpenSceneGraph-3.2.1/build/lib/osgPlugins-3.2.1/osgdb_dicom.lib
and object
C:/OpenSceneGraph/OpenSceneGraph-3.2.1/build/lib/osgPlugins-3.2.1/osgdb_dicom.exp
67C:\OpenSceneGraph\OpenSceneGraph-3.2.1\build\bin\osgPlugins-3.2.1\osgdb_dicom.dll
: fatal error LNK1169: one or more multiply defined symbols found
This error was reported 3 years ago, without much interest [1].
Contrarily to what's regularly erroneously stated here and there, this
error has _nothing_ to deal with CRT configuration mismatch (the
dreaded /MT[d] vs. /MD[d] compiler settings). In such situation, you
generally get a warning about trying to add /NODEFAULTLIB:MSVCRT flag.
This _isn't_ the case here and I've double-checked that both my OSG
and DCMTK builds are using the same settings. And indeed, it's
identical: /MD[d].
This error has to deal with mixing both osgDB {i|o}fstream with STL
ones, as correctly explained in [2] and [3].
There seems to be a consensus as considering this issue a Visual
Studio 2010/2012 (what about 2013?) bug [4] and a well known
work-around is to pass /FORCE:MULTIPLY to the linker. Simply doing so
in the osgdb_dicom.vcxproj project file is obviously lost each time
CMake is invoked. A cleaner solution would be to add this flag through
the CMAKE_SHARED_LINKER_FLAGS of osgdb_dicom's CMakeLists.txt file, as
in VirtualPlanetBuilder [5]. I've thus updated osgdb_dicom's
CMakeLists.txt file to read as:
IF (WIN32)
SET(TARGET_EXTERNAL_LIBRARIES wsock32.lib)
= I've added
IF(MSVC)
IF(${MSVC_VERSION} STREQUAL 1600)
# Overcome Visual Studio 2010 error LNK2005:
basic_ifstream symbols already defined in dcmingle.lib (didispfn.obj)
SET(CMAKE_SHARED_LINKER_FLAGS
${CMAKE_SHARED_LINKER_FLAGS} /FORCE:MULTIPLE)
ENDIF()
ENDIF()
= End of work-around
ENDIF()
However, it seem's that the default CMAKE_SHARED_LINKER_FLAGS
/machine:x64 is overriding customization, as osgdb_dicom linker
settings only shows /machine:x64. I've checked that the updated
CMakeLists.txt file was taken into account using an output message.
Am I missing something obvious here and is there a way to prevent such
an override? Or alternatively, is there a work-around for the Visual
Studio 2010 work-around?
Thanks,
Émeric
[1] http://forum.openscenegraph.org/viewtopic.php?t=8570
[2] http://forum.openscenegraph.org/viewtopic.php?t=8099
[3]
http://stackoverflow.com/questions/23885275/lnk2005-already-defined-linker-behaves-strange
[4]
http://social.msdn.microsoft.com/Forums/vstudio/en-US/191de00a-53c9-4bd9-9cb6-e844eb224ca2/lnk2005-when-using-stdostringstream?forum=vclanguage
[5]
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2011-September/253865.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] why the eye separation changed?
Dear Robert, thanks for your kind answers. Due to the eye separation problem, I can not operate continuously. I just press the Space key to load the init view-settings, and then switch to the next view, and then zoom in. Right now, I can not implement my own camera manipulator. Maybe I need a solution using the current osg function(though some code segement seem high efficiency). thanks. whu At 2014-09-24 22:32:57, Robert Osfield robert.osfi...@gmail.com wrote: Hi Whu, The TrackballManipulator operates in a mode where the virtual eye separation is scaled relative to the distance between the eye point and center of rotation. This approach allows one to move around objects of completely different scales i.e. whole earth or a single molecule and they will sit centered on screen and with a comfortable eye separation. While this approach can be convenient and feel natural it's artificial, in the real world our eyes don't actually work this this. However, even with it being an artificial way to manage eye separation it works really nicely for a wide range of tasks. However, it isn't a solution that can work in all situations all the time. In the case when you zoom in right in close to the center of rotation the TrackballManipulator has to contend with another problem that is specific to manipulators that more around a central point. If you keep zooming in so the look distance is close to zero and if you do nothing about this basically for all intents and purposes the eye point stops and the manipulator then becomes very unnatural to use as the end user isn't aware that the look distance is now near zero. A work around to this problem is to change the zoom in behaviour when you get really close to the central point, so rather then keeping on reducing the look distance you maintain the look distance and push the central point away from the eye. This workaround is a bit crude but it prevents the worst of artefacts associated with the look distance tending to zero. When this work around is applied the virtual eye separation will stop reducing further so this will be a small discontinuity in behaviour. From your description it sounds like the mouse wheel modification of the look distances doesn't have this workaround in place, which itself could lead to problems if one then tries to pan, or rotate around the very close central point, the stereo offsets would also differ to how the mouse button drive zoom in behaves. Is there a solution to this problem? Well basically you shouldn't keep zooming in as you simply can't keep a trackball working seamlessly with very small look distances, it's not a case of bugs, it's a case of a fundamental limitation with using trackballs when you zoom in too far towards the central point things start going wrong and you have to come up with workarounds not matter what you do. In your own application you might be want it behave in a way that makes sense for you application, what this might be I cannot say as I have absolutely no clue about your usage model. You are completely free to implement your own camera manipulation and management of eye separation and if the off the shelf functionality doesn't do exactly what you want then go ahead a roll your own. Robert. On 24 September 2014 15:12, whu wyg030...@163.com wrote: Dear all, I used the stereo mode in my osg program, and the trackball camera manipulator. But when I try to zoom nearer to the object, the mouse wheel and the right-key operation get different results. Using the right key (mouse) to zoom, it seemed that the eye separation changed bigger, and this make Physical discomfort. Using the mouse wheel to zoom, the result is right. I just want to find the reason, because the eye separation problem lead to some other trouble. Can someone give me some suggestions. Thanks. whu ___ 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] OSG deployment on Windows
Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewerQT example question
I'm using the new version, under Linux (although I will eventually be testing under windows as well, I need it to work on Ubuntu first). Like I mentioned, I am trying to extend the example to fit into the QGraphicsView approach. Based on various guides and discussions that I have found, this involves setting the GLWidget as the viewport of the QGraphicsView. In theory, this should let me use the OSG View as the background of the widget, and place QGraphicsItems in a QGraphicsScene that will appear on top of it. I can get this to work using the osgViewer::Viewer, for a single window, but when I try the same approach with a CompositeViewer and multiple windows, I get a variety of errors. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61146#61146 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG deployment on Windows
Hi Émeric, Placing the external libraries in OSG_ROOT\bin should work as long as the main executable is also in OSG_ROOT\bin. Windows should first search for DLLs in the same folder as the executable before searching in PATH. So there is no need to add your application to PATH, or worry about conflicting DLLs in PATH. I've deployed my application like this for years and never had any issues. Cheers, Farshid On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ 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 deployment on Windows
Hi Farshid, Correct, but what about the plug-ins and examples? They aren't installed in OSG_ROOT\bin. So if you only copy the DLLs in OSG_ROOT\bin, when trying to load a plug-in (installed in OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, this last one will thus be searched in the PATH, with the risk of finding a similarly named DLL elsewhere in the filesystem before reaching the expected on in OSG_ROOT\bin. How do you manage this situation on your own? Cheers, Émeric 2014-09-24 19:12 GMT+02:00 Farshid Lashkari fla...@gmail.com: Hi Émeric, Placing the external libraries in OSG_ROOT\bin should work as long as the main executable is also in OSG_ROOT\bin. Windows should first search for DLLs in the same folder as the executable before searching in PATH. So there is no need to add your application to PATH, or worry about conflicting DLLs in PATH. I've deployed my application like this for years and never had any issues. Cheers, Farshid On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ 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] OSG deployment on Windows
I deploy my applications with their own local copy of OSG in the same folder as the main application executable. I typically have a dozen different versions and flavors of OSG on my computer at once so OSG_ROOT becomes irrelevant. On Wed, Sep 24, 2014 at 11:39 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi Farshid, Correct, but what about the plug-ins and examples? They aren't installed in OSG_ROOT\bin. So if you only copy the DLLs in OSG_ROOT\bin, when trying to load a plug-in (installed in OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, this last one will thus be searched in the PATH, with the risk of finding a similarly named DLL elsewhere in the filesystem before reaching the expected on in OSG_ROOT\bin. How do you manage this situation on your own? Cheers, Émeric 2014-09-24 19:12 GMT+02:00 Farshid Lashkari fla...@gmail.com: Hi Émeric, Placing the external libraries in OSG_ROOT\bin should work as long as the main executable is also in OSG_ROOT\bin. Windows should first search for DLLs in the same folder as the executable before searching in PATH. So there is no need to add your application to PATH, or worry about conflicting DLLs in PATH. I've deployed my application like this for years and never had any issues. Cheers, Farshid On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ 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 -- 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 Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/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
Re: [osg-users] OSG deployment on Windows
Hi Émeric, I'm assuming OSG_ROOT refers to the install folder of your OSG based application. The plug-ins should go into OSG_ROOT\bin\osgPlugins-X.Y.Z. OSG will automatically prepend the osgPlugins-X.Y.Z\ path when attempting to load osgdb_*.dll plugins. For example, let's say I install my application into the C:\MyApp\ folder. Here is how I organize the files: C:\MyApp\bin\ contains: - Executables (.exe) - OSG library files (osg.dll, osgDB.dll, osgUtil.dll, ...) - External dependencies (zlib1.dll, libxml2.dll, ...) C:\MyApp\bin\osgPlugins-X.Y.Z\ contains: - All OSG reader/writer plugins (osgdb_*.dll) Any executable launched from the C:\MyApp\bin\ folder, will automatically load dependencies from that folder before searching PATH. When attempting to load a reader/writer plugin, OSG will automatically look in C:\MyApp\bin\osgPlugins-X.Y.Z\. If any of those plugins have external dependencies, they will be loaded from C:\MyApp\bin\, before searching in PATH. This should allow multiple OSG based applications using different versions to be installed on the system without conflicts. Hope this clears it up. Cheers, Farshid On Wed, Sep 24, 2014 at 10:39 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi Farshid, Correct, but what about the plug-ins and examples? They aren't installed in OSG_ROOT\bin. So if you only copy the DLLs in OSG_ROOT\bin, when trying to load a plug-in (installed in OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, this last one will thus be searched in the PATH, with the risk of finding a similarly named DLL elsewhere in the filesystem before reaching the expected on in OSG_ROOT\bin. How do you manage this situation on your own? Cheers, Émeric 2014-09-24 19:12 GMT+02:00 Farshid Lashkari fla...@gmail.com: Hi Émeric, Placing the external libraries in OSG_ROOT\bin should work as long as the main executable is also in OSG_ROOT\bin. Windows should first search for DLLs in the same folder as the executable before searching in PATH. So there is no need to add your application to PATH, or worry about conflicting DLLs in PATH. I've deployed my application like this for years and never had any issues. Cheers, Farshid On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ 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] osgViewerQT example question
I've made a couple of attempts, and I feel like I am very close... On one attempt, using a seperate osgViewer for each View, everything works but the Database Pager isn't happy about having multiple viewers looking at the same data. (osgEarth data under PagedLOD nodes flickers in and out of the various levels of detail) On another attempt, using a composite viewer, everything works as I would expect it to if I only have one view, and I am able to add QGraphicsItems to the scene, but if I attempt to add a second View, they get rendered to the same viewport, fighting over it, spit out a bunch of detected invalid value after renderBin draw errors, then crashes. On another attempt, having multiple views works fine, until I add a QGraphicsScene to the graphicsView. The items in the QGraphicsScene will render, but the osg view will not, sending Cannot make context current errors to the console. Across these three failure modes is the set of features I need working; I just need to find the proper way to mesh them together -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61152#61152 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] why the eye separation changed?
Hi Whu, If you don't like the default behaviour then you'll need to adapt it or roll your own. There isn't anyway the OSG can offer all the types of behaviour end users will want in their specific application, all the osgGA are simple and general purpose and aren't meant to cover all usage cases. You have a usage case that doesn't quite fit so you just need to do what the OSG has been written to allow you to do - write your own camera behaviours. Robert. On 24 September 2014 15:52, whu wyg030...@163.com wrote: Dear Robert, thanks for your kind answers. Due to the eye separation problem, I can not operate continuously. I just press the Space key to load the init view-settings, and then switch to the next view, and then zoom in. Right now, I can not implement my own camera manipulator. Maybe I need a solution using the current osg function(though some code segement seem high efficiency). thanks. whu At 2014-09-24 22:32:57, Robert Osfield robert.osfi...@gmail.com wrote: Hi Whu, The TrackballManipulator operates in a mode where the virtual eye separation is scaled relative to the distance between the eye point and center of rotation. This approach allows one to move around objects of completely different scales i.e. whole earth or a single molecule and they will sit centered on screen and with a comfortable eye separation. While this approach can be convenient and feel natural it's artificial, in the real world our eyes don't actually work this this. However, even with it being an artificial way to manage eye separation it works really nicely for a wide range of tasks. However, it isn't a solution that can work in all situations all the time. In the case when you zoom in right in close to the center of rotation the TrackballManipulator has to contend with another problem that is specific to manipulators that more around a central point. If you keep zooming in so the look distance is close to zero and if you do nothing about this basically for all intents and purposes the eye point stops and the manipulator then becomes very unnatural to use as the end user isn't aware that the look distance is now near zero. A work around to this problem is to change the zoom in behaviour when you get really close to the central point, so rather then keeping on reducing the look distance you maintain the look distance and push the central point away from the eye. This workaround is a bit crude but it prevents the worst of artefacts associated with the look distance tending to zero. When this work around is applied the virtual eye separation will stop reducing further so this will be a small discontinuity in behaviour. From your description it sounds like the mouse wheel modification of the look distances doesn't have this workaround in place, which itself could lead to problems if one then tries to pan, or rotate around the very close central point, the stereo offsets would also differ to how the mouse button drive zoom in behaves. Is there a solution to this problem? Well basically you shouldn't keep zooming in as you simply can't keep a trackball working seamlessly with very small look distances, it's not a case of bugs, it's a case of a fundamental limitation with using trackballs when you zoom in too far towards the central point things start going wrong and you have to come up with workarounds not matter what you do. In your own application you might be want it behave in a way that makes sense for you application, what this might be I cannot say as I have absolutely no clue about your usage model. You are completely free to implement your own camera manipulation and management of eye separation and if the off the shelf functionality doesn't do exactly what you want then go ahead a roll your own. Robert. On 24 September 2014 15:12, whu wyg030...@163.com wrote: Dear all, I used the stereo mode in my osg program, and the trackball camera manipulator. But when I try to zoom nearer to the object, the mouse wheel and the right-key operation get different results. Using the right key (mouse) to zoom, it seemed that the eye separation changed bigger, and this make Physical discomfort. Using the mouse wheel to zoom, the result is right. I just want to find the reason, because the eye separation problem lead to some other trouble. Can someone give me some suggestions. Thanks. whu ___ 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
Re: [osg-users] OSG deployment on Windows
Hi Chris, Are you then also putting the required plug-ins in the same folder and no more in a separate osgPlugins-X.Y.Z folder? Cheers, Émeric 2014-09-24 19:59 GMT+02:00 Chris Hanson xe...@alphapixel.com: I deploy my applications with their own local copy of OSG in the same folder as the main application executable. I typically have a dozen different versions and flavors of OSG on my computer at once so OSG_ROOT becomes irrelevant. On Wed, Sep 24, 2014 at 11:39 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi Farshid, Correct, but what about the plug-ins and examples? They aren't installed in OSG_ROOT\bin. So if you only copy the DLLs in OSG_ROOT\bin, when trying to load a plug-in (installed in OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, this last one will thus be searched in the PATH, with the risk of finding a similarly named DLL elsewhere in the filesystem before reaching the expected on in OSG_ROOT\bin. How do you manage this situation on your own? Cheers, Émeric 2014-09-24 19:12 GMT+02:00 Farshid Lashkari fla...@gmail.com: Hi Émeric, Placing the external libraries in OSG_ROOT\bin should work as long as the main executable is also in OSG_ROOT\bin. Windows should first search for DLLs in the same folder as the executable before searching in PATH. So there is no need to add your application to PATH, or worry about conflicting DLLs in PATH. I've deployed my application like this for years and never had any issues. Cheers, Farshid On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ 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 -- 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 Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • 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
Re: [osg-users] OSG deployment on Windows
OK, thanks for the clarification Farshid. Yes, I was using exactly the same structure. But I didn't knew that the OSG plug-ins were first looking for their dependencies is OSG_ROOT\bin before relying upon the PATH. I thought that, when not found in the OSG_ROOT\bin\osgPlugins-X.Y.Z folder, the required DLLs were searched for in the PATH. Émeric 2014-09-24 20:03 GMT+02:00 Farshid Lashkari fla...@gmail.com: Hi Émeric, I'm assuming OSG_ROOT refers to the install folder of your OSG based application. The plug-ins should go into OSG_ROOT\bin\osgPlugins-X.Y.Z. OSG will automatically prepend the osgPlugins-X.Y.Z\ path when attempting to load osgdb_*.dll plugins. For example, let's say I install my application into the C:\MyApp\ folder. Here is how I organize the files: C:\MyApp\bin\ contains: - Executables (.exe) - OSG library files (osg.dll, osgDB.dll, osgUtil.dll, ...) - External dependencies (zlib1.dll, libxml2.dll, ...) C:\MyApp\bin\osgPlugins-X.Y.Z\ contains: - All OSG reader/writer plugins (osgdb_*.dll) Any executable launched from the C:\MyApp\bin\ folder, will automatically load dependencies from that folder before searching PATH. When attempting to load a reader/writer plugin, OSG will automatically look in C:\MyApp\bin\osgPlugins-X.Y.Z\. If any of those plugins have external dependencies, they will be loaded from C:\MyApp\bin\, before searching in PATH. This should allow multiple OSG based applications using different versions to be installed on the system without conflicts. Hope this clears it up. Cheers, Farshid On Wed, Sep 24, 2014 at 10:39 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi Farshid, Correct, but what about the plug-ins and examples? They aren't installed in OSG_ROOT\bin. So if you only copy the DLLs in OSG_ROOT\bin, when trying to load a plug-in (installed in OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, this last one will thus be searched in the PATH, with the risk of finding a similarly named DLL elsewhere in the filesystem before reaching the expected on in OSG_ROOT\bin. How do you manage this situation on your own? Cheers, Émeric 2014-09-24 19:12 GMT+02:00 Farshid Lashkari fla...@gmail.com: Hi Émeric, Placing the external libraries in OSG_ROOT\bin should work as long as the main executable is also in OSG_ROOT\bin. Windows should first search for DLLs in the same folder as the executable before searching in PATH. So there is no need to add your application to PATH, or worry about conflicting DLLs in PATH. I've deployed my application like this for years and never had any issues. Cheers, Farshid On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ 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] OSG deployment on Windows
I just move the osgPlugins folder into the folder where the executable and top-level OSG DLLs are found. All seems to work without any fuss. On Wed, Sep 24, 2014 at 1:04 PM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi Chris, Are you then also putting the required plug-ins in the same folder and no more in a separate osgPlugins-X.Y.Z folder? Cheers, Émeric 2014-09-24 19:59 GMT+02:00 Chris Hanson xe...@alphapixel.com: I deploy my applications with their own local copy of OSG in the same folder as the main application executable. I typically have a dozen different versions and flavors of OSG on my computer at once so OSG_ROOT becomes irrelevant. On Wed, Sep 24, 2014 at 11:39 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi Farshid, Correct, but what about the plug-ins and examples? They aren't installed in OSG_ROOT\bin. So if you only copy the DLLs in OSG_ROOT\bin, when trying to load a plug-in (installed in OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, this last one will thus be searched in the PATH, with the risk of finding a similarly named DLL elsewhere in the filesystem before reaching the expected on in OSG_ROOT\bin. How do you manage this situation on your own? Cheers, Émeric 2014-09-24 19:12 GMT+02:00 Farshid Lashkari fla...@gmail.com: Hi Émeric, Placing the external libraries in OSG_ROOT\bin should work as long as the main executable is also in OSG_ROOT\bin. Windows should first search for DLLs in the same folder as the executable before searching in PATH. So there is no need to add your application to PATH, or worry about conflicting DLLs in PATH. I've deployed my application like this for years and never had any issues. Cheers, Farshid On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO emeric.masch...@gmail.com wrote: Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ 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 -- 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 Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • 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 -- 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 Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/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
