[osg-users] OSG Training

[Tony Vasile]

Does anyone know of people or companies offering OpenSceneGraph training in 
Australia, preferably in Sydney. There was one training company offering 
something but looking at their web site, the course has been removed.

Tony V


Tony V

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67725#67725





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph Travis + Coverity scan up and running

[Jason Beverage]

Really cool Robert.  I'd love to get TravisCI setup for osgEarth as well,
we might pick your brain on it here soon.

On Tue, Jun 21, 2016 at 5:03 AM Robert Osfield 
wrote:

> With help form Ralf Habacker and Jordi Torress we now have Travis
> build testing and Coverity scan up and running.  If you got to the
> OSG's github page :
>
>https://github.com/openscenegraph/OpenSceneGraph
>
> and look down to the README.md you'll see two little bullet icons:
>
>   [build | passing]  [ coverity | passed 5 new defects]
>
> You can click on the build icon and it'll take you to the Travis build
> logs, and click on the Coverity one and it'll take you to our new
> Coverity analysis page.
>
> For the up coming OpenSceneGraph-3.6 stable release I would like to
> improve the Coverity defect count. I have already made dozens of small
> fixes to code highlight by Coverity, there is still a long way to go.
> For this effort I'd appreciate help from the community :-)
>
> My personally priority is to squash the High priority ones first, then
> move on to Midium and then lower priority ones.  Also defects picked
> up in the core libraries like osg, osgUtil, osgDB, osgGA, osgViewer
> are ones that will benefit the most users.
>
> As well as code fixes just reviewing the defect reports and accessing
> how crucial it is would be helpful.  The Coverity web interface allows
> you to add comments as well as adjust properties/categorization of
> defects.  For this you'll need to either log into via your Github
> account or create a Coverity account.
>
> As work on cleaning up defects progresses I will apply the fixes to
> master as they come in and then every couple of days merge these
> changes as a block to the new coverity_scan branch which will then
> fire off a Coverity scan so we can get an update of how the clean up
> is progressing.
>
> When doing fixes please make sure that you fully understand the code
> you are modifying and the nature of the defect.  It's all too easy to
> fix a warning/defect report on code that was working fine and then
> have the new "improved" code introduce a bug that neither produces
> warning or a Coverity scan.  I say this as I have made this mistake
> myself before, and also spotted such mistakes when merging changes
> from others.
>
> Thanks in advance for you help,
> 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] OpenThreads build error (OSG 3.4.0)

[Rick Irons]

Hi Robert,

Thanks for the response.  I will wait to hear what others have to say.

Thanks,
Rick

-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Tuesday, June 21, 2016 10:49 AM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] OpenThreads build error (OSG 3.4.0)

Hi Rick,

On 21 June 2016 at 15:33, Rick Irons  wrote:
> Any thoughts on this issue?
>
> We are trying out option #2 below (Define WIN32_IE to 0x0600 in the 
> Open Thread cmake list file) since it is the more conservative of the 
> approaches.
> No issues so far.

I don't have Windows expertise to comment on specifics like this so have to 
defer to members of the community that have Windows knowledge like yourself.

One thing that is a bit curious though is why you are seeing build problems 
with 3.4.0 when others using Windows didn't report problems during the 3.4.0 
release testing cycle.  I have a Windows 7 dual boot on this system that I 
occasionally boot into and haven't seen problems, I think I have VS2013 
installed as well.

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] freetype build support on Windows

[Stuart Mentzer]

Hi Robert,

Here is what should be the final version of FindFreetype.cmake that is based on 
the now-accepted CMake patches. This supports the new freetype include path 
structure and fixes the failure to find the debug library on Windows due to its 
name having a 'd' suffix.

The only differences are wrt the license requirement when not bundled with 
CMake and the adjustments necessary to include CMake modules.

Once the patches are part of OSG's oldest supported CMake this 
FindFreetype.cmake can be dropped from OSG.

If you'd like me to post this to osg-submission just let me know.

Cheers,
Stuart

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67722#67722




Attachments: 
http://forum.openscenegraph.org//files/findfreetype_213.7z


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Side by side viewers with different field of view

[Robert Osfield]

On 21 June 2016 at 17:05, Steven Powers  wrote:
> Hi Robert,
>
> Both views have the same eye point (view matrix) and vertical FOV. The only 
> thing that differs is the horizontal FOV. I would expect the edges to match 
> but I'm not sure why they are not.

The should match if the vertical FOV matches and the orientation of
horizontal viewing direction and rotated accurately to match the
common edge correctly.

If these are all matched perhaps the visual artefact is arising from
somewhere else.  Any chance that the sky and reflection rendering
aren't behaving themselves?

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Side by side viewers with different field of view

[Steven Powers]

Hi Robert,

Both views have the same eye point (view matrix) and vertical FOV. The only 
thing that differs is the horizontal FOV. I would expect the edges to match but 
I'm not sure why they are not.

Thank you!

Cheers,
Steven

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67719#67719





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenThreads build error (OSG 3.4.0)

[Robert Osfield]

Hi Rick,

On 21 June 2016 at 15:33, Rick Irons  wrote:
> Any thoughts on this issue?
>
> We are trying out option #2 below (Define WIN32_IE to 0x0600 in the Open
> Thread cmake list file) since it is the more conservative of the approaches.
> No issues so far.

I don't have Windows expertise to comment on specifics like this so
have to defer to members of the community that have Windows knowledge
like yourself.

One thing that is a bit curious though is why you are seeing build
problems with 3.4.0 when others using Windows didn't report problems
during the 3.4.0 release testing cycle.  I have a Windows 7 dual boot
on this system that I occasionally boot into and haven't seen
problems, I think I have VS2013 installed as well.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenThreads build error (OSG 3.4.0)

[Rick Irons]

Hi all,

Any thoughts on this issue?

We are trying out option #2 below (Define WIN32_IE to 0x0600 in the Open Thread 
cmake list 
file)
 since it is the more conservative of the approaches.  No issues so far.

Thanks,
Rick

From: Rick Irons
Sent: Friday, June 17, 2016 1:08 PM
To: 'osg-users@lists.openscenegraph.org' 
Subject: OpenThreads build error (OSG 3.4.0)

Hi,

Our internal development environment was just recently updated and we are now 
encountering an OpenThreads build error on Windows with OSG 3.4.0.  The build 
error is included in the following Visual Studios 2013 build output...

1>-- Rebuild All started: Project: OpenThreads, Configuration: Debug x64 
--
2>-- Skipped Rebuild All: Project: uninstall, Configuration: Debug x64 
--
2>Project not selected to build for this solution configuration
1>  WIN32Condition.cpp
1>c:\program files (x86)\windows kits\8.1\include\shared\sdkddkver.h(272): 
fatal error C1189: #error :  _WIN32_WINNT settings conflicts with _WIN32_IE 
setting
1>  Win32Mutex.cpp
1>c:\program files (x86)\windows kits\8.1\include\shared\sdkddkver.h(272): 
fatal error C1189: #error :  _WIN32_WINNT settings conflicts with _WIN32_IE 
setting
1>  Win32Thread.cpp
1>c:\program files (x86)\windows kits\8.1\include\shared\sdkddkver.h(272): 
fatal error C1189: #error :  _WIN32_WINNT settings conflicts with _WIN32_IE 
setting
1>  Win32ThreadBarrier.cpp
1>  Version.cpp
1>  Atomic.cpp
1>c:\program files (x86)\windows kits\8.1\include\shared\sdkddkver.h(272): 
fatal error C1189: #error :  _WIN32_WINNT settings conflicts with _WIN32_IE 
setting
1>  Generating Code...
3>-- Rebuild All started: Project: osg, Configuration: Debug x64 --
3>  AlphaFunc.cpp
3>  AnimationPath.cpp
3>  ApplicationUsage.cpp
3>  ArgumentParser.cpp

The source of the issue appears to be the following line in sdkddkver.h

#if ((_WIN32_WINNT < _WIN32_WINNT_WIN2K) && (_WIN32_IE > _WIN32_IE_IE60SP1))

...where WIN32_WINNT is 0x0400 (per Open Thread 
definition),
 WIN32_WINNT_WIN2K is 
0x0500, WIN32_IE is 
0x0700 (new default in our dev environment), and WIN32_IE_IE60SP1 is 
0x0601.
  What appears to now be tripping the error is that the default value of 
WIN32_IE has changed in our dev environment from 0x0600 to 0x0700.

I am interested in feedback regarding how to properly address this issue.  
Possible options include...


1.)Changing WIN32_WINNT to 0x0500 in the Open Thread cmake list 
file.



2.)Define WIN32_IE to 0x0600 in the Open Thread cmake list 
file.

Thank you.

Rick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [osgPlugins] fbx plugin compile error

[Pelle Nordqvist]

Hi Robert, I grabbed the latest master today and I got this compilation
error
on xubuntu 14.04, g++ 4.8.4

[ 83%] Building CXX object
src/osgPlugins/fbx/CMakeFiles/osgdb_fbx.dir/ReaderWriterFBX.o
/home/simuser/Downloads/OpenSceneGraph-master/src/osgPlugins/fbx/ReaderWriterFBX.cpp:
In member function ‘virtual osgDB::ReaderWriter::WriteResult
ReaderWriterFBX::writeNode(const osg::Node&, const string&, const Options*)
const’:
/home/simuser/Downloads/OpenSceneGraph-master/src/osgPlugins/fbx/ReaderWriterFBX.cpp:602:75:
error: cannot convert ‘const char* const*’ to ‘const char*’ in
initialization
 char const * versions =
lExporter->GetCurrentWritableVersions();

I think I dropped into this #ifdef branch due to an older fbx SDK installed,
anyway I simply changed the offending line to
const char* const* versions = lExporter->GetCurrentWritableVersions();

I attached the updated file for review.

Cheers,

/Per
#include 
#include 
#ifndef WIN32
#include //for strncasecmp
#endif

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#if defined(_MSC_VER)
#pragma warning( disable : 4505 )
#pragma warning( default : 4996 )
#endif
#include 

#include "ReaderWriterFBX.h"
#include "fbxReader.h"
#include "WriterNodeVisitor.h"

/// Returns true if the given node is a basic root group with no special information.
/// Used in conjunction with UseFbxRoot option.
/// Identity transforms are considered as basic root nodes.
bool isBasicRootNode(const osg::Node& node)
{
const osg::Group* osgGroup = node.asGroup();
if (!osgGroup || node.asGeode())// WriterNodeVisitor handles Geodes the "old way" (= Derived from Node, not Group as for now). Geodes may be considered "basic root nodes" when WriterNodeVisitor will be adapted.
{
// Geodes & such are not basic root nodes
return false;
}

// Test if we've got an empty transform (= a group!)
const osg::Transform* transform = osgGroup->asTransform();
if (transform)
{
if (const osg::MatrixTransform* matrixTransform = transform->asMatrixTransform())
{
if (!matrixTransform->getMatrix().isIdentity())
{
// Non-identity matrix transform
return false;
}
}
else if (const osg::PositionAttitudeTransform* pat = transform->asPositionAttitudeTransform())
{
if (pat->getPosition() != osg::Vec3d() ||
pat->getAttitude() != osg::Quat() ||
pat->getScale() != osg::Vec3d(1.0f, 1.0f, 1.0f) ||
pat->getPivotPoint() != osg::Vec3d())
{
// Non-identity position attribute transform
return false;
}
}
else
{
// Other transform (not identity or not predefined type)
return false;
}
}

// Test the presence of a non-empty stateset
if (node.getStateSet())
{
osg::ref_ptr emptyStateSet = new osg::StateSet;
if (node.getStateSet()->compare(*emptyStateSet, true) != 0)
{
return false;
}
}

return true;
}


class CleanUpFbx
{
FbxManager* m_pSdkManager;
public:
explicit CleanUpFbx(FbxManager* pSdkManager) : m_pSdkManager(pSdkManager)
{}

~CleanUpFbx()
{
m_pSdkManager->Destroy();
}
};

//Some files don't correctly mark their skeleton nodes, so this function infers
//them from the nodes that skin deformers linked to.
void findLinkedFbxSkeletonNodes(FbxNode* pNode, std::set& fbxSkeletons)
{
if (const FbxGeometry* pMesh = FbxCast(pNode->GetNodeAttribute()))
{
for (int i = 0; i < pMesh->GetDeformerCount(FbxDeformer::eSkin); ++i)
{
const FbxSkin* pSkin = (const FbxSkin*)pMesh->GetDeformer(i, FbxDeformer::eSkin);

for (int j = 0; j < pSkin->GetClusterCount(); ++j)
{
const FbxNode* pSkeleton = pSkin->GetCluster(j)->GetLink();
fbxSkeletons.insert(pSkeleton);
}
}
}

for (int i = 0; i < pNode->GetChildCount(); ++i)
{
findLinkedFbxSkeletonNodes(pNode->GetChild(i), fbxSkeletons);
}
}

void resolveBindMatrices(
osg::Node& root,
const BindMatrixMap& boneBindMatrices,
const std::map& nodeMap)
{
std::set nodeNames;
for (std::map::const_iterator it = nodeMap.begin(); it != nodeMap.end(); ++it)
{
nodeNames.insert(it->second->getName());
}

for (BindMatrixMap::const_iterator it = boneBindMatrices.begin();
it != boneBindMatrices.end();)
{
FbxNode* const fbxBone = it->first.first;
std::map::const_iterator nodeIt = nodeMap.find(fbxBone);
if (nodeIt != nodeMap.end())
{
const osg::Matrix bindMatrix = it->second;

[osg-users] Most efficient way to get the gl_ModelViewMatrix of PREVIOUS frame?

[Philipp Meyer]

Hi,

I am currently working on a Shader that is supposed to color fragments 
approaching the camera red and fragments departing the camera green.
So for example, if an object in the scene is traveling towards the camera, it 
should be rendered red, otherwise green.

For that, my basic idea was to compute the distance of each fragment to the 
camera, and then subtract the distance of the same fragment from the previous 
frame. If the result is negative, the fragment would approach the camera and 
therefore be red, otherwise green.

The challenge here is to get the fragment position from the previous frame 
though.
>From my understanding, the fragments position relative to the camera (0,0,0,1) 
>is calculated by interpolating
gl_Vertex * gl_ModelViewMatrix, where ModelViewMatrix is calculated as 
(viewmatrix * modelmatrix).

So, what I would need is something like "gl_ModelViewMatrixPreviousFrame".
While it is relatively easy to pass the previous viewmatrix to the shader by 
setting a uniform on the parent camera in OSG and updating it in the program 
render loop, how would one go about passing the old modelMatrix? The model 
matrix can be different for every primitive in the scene, so wouldn't I need a 
million uniforms for that? How would that even work?

Thank you!

Cheers,
Philipp

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67713#67713





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OpenSceneGraph Travis + Coverity scan up and running

[Robert Osfield]

With help form Ralf Habacker and Jordi Torress we now have Travis
build testing and Coverity scan up and running.  If you got to the
OSG's github page :

   https://github.com/openscenegraph/OpenSceneGraph

and look down to the README.md you'll see two little bullet icons:

  [build | passing]  [ coverity | passed 5 new defects]

You can click on the build icon and it'll take you to the Travis build
logs, and click on the Coverity one and it'll take you to our new
Coverity analysis page.

For the up coming OpenSceneGraph-3.6 stable release I would like to
improve the Coverity defect count. I have already made dozens of small
fixes to code highlight by Coverity, there is still a long way to go.
For this effort I'd appreciate help from the community :-)

My personally priority is to squash the High priority ones first, then
move on to Midium and then lower priority ones.  Also defects picked
up in the core libraries like osg, osgUtil, osgDB, osgGA, osgViewer
are ones that will benefit the most users.

As well as code fixes just reviewing the defect reports and accessing
how crucial it is would be helpful.  The Coverity web interface allows
you to add comments as well as adjust properties/categorization of
defects.  For this you'll need to either log into via your Github
account or create a Coverity account.

As work on cleaning up defects progresses I will apply the fixes to
master as they come in and then every couple of days merge these
changes as a block to the new coverity_scan branch which will then
fire off a Coverity scan so we can get an update of how the clean up
is progressing.

When doing fixes please make sure that you fully understand the code
you are modifying and the nature of the defect.  It's all too easy to
fix a warning/defect report on code that was working fine and then
have the new "improved" code introduce a bug that neither produces
warning or a Coverity scan.  I say this as I have made this mistake
myself before, and also spotted such mistakes when merging changes
from others.

Thanks in advance for you help,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Origin of computing maximum level in osgdem

[Robert Osfield]

Hi Maya,

There isn't any particular "literature" that I used when working out the
maths, I just used my own knowledge of maths and derived things myself.
It's not complicated.

Each successive level you double the resolution in each so you get a
formula in the sytle:

   resolution (L) = tileSize * 2 ^ (L)

So to work out the number of levels you require to hit a target resolution
you simply take the log of both side and restructure things a little to
account for in needing an integer Level.

Robert.

On 20 June 2016 at 23:02, maya leonard  wrote:

> Hello,
>
> Can someone point me to the literature for computing
>
> (1 ) AR = xRange/ yRange in
>
>   bool DataSet::computeOptimumTileSystemDimensions(int& C1, int& R1)
>   Lines 247- 270 DataSet.cpp
>
> and
>
> (2) int k_cols = int( ceil( 1.0 + ::log( destination_xRange / (_C1 *
> sourceResolutionX * tileSize ) ) / ::log(2.0) ) );
>   int k_rows = int( ceil( 1.0 + ::log( destination_yRange / (_R1 *
> sourceResolutionY * tileSize ) ) / ::log(2.0) ) );
>
>   bool DataSet::computeOptimumLevel(Source* source, int maxLevel, int&
> level)
>  Lines 201 - 210 DataSet.cpp
>
> Thank you
>
> Maya
>
>
>
> ___
> 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