Re: [osg-users] Float vs double in BOUNDINGSPHERE and BOUNDINGBOX

[Robert Osfield]

Hi Maxim,

The default to BoundingBoxf and BoundingSphref is partly a historical reason.

Scene graphs traversals are memory bandwidth limited so you only want
to pay for the extra memory size if there is specific value in doing
so.

Robert.
On Fri, 29 Jun 2018 at 05:00, Maxim Stere  wrote:
>
> Hi,
>
> Is there a reason why OSG_USE_FLOAT_BOUNDINGBOX and 
> OSG_USE_FLOAT_BOUNDINGSPHERE are set to YES in cmake by default?
>
> Since most CPUs now use doubles natively and emulate floats, making float 
> calculations a little slower, would it not be better for OSG speed and 
> performance to have these options be set to OFF by default?
>
> Doubles would take up more RAM but what is more important for intersection 
> speeds in OSG, RAM use or CPU number crunching?
>
> 
> Thank you,
> --Maxim
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74219#74219
>
>
>
>
>
> ___
> 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] OpenSceneGraph-3.6.2 release candidate 3

[Maxim Stere]

Made a Windows GL3 profile PR #570. It should fix some GL3 CMake problems on 
windows...


Thank you,
--Maxim

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





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

[osg-users] Float vs double in BOUNDINGSPHERE and BOUNDINGBOX

[Maxim Stere]

Hi,

Is there a reason why OSG_USE_FLOAT_BOUNDINGBOX and 
OSG_USE_FLOAT_BOUNDINGSPHERE are set to YES in cmake by default?

Since most CPUs now use doubles natively and emulate floats, making float 
calculations a little slower, would it not be better for OSG speed and 
performance to have these options be set to OFF by default?

Doubles would take up more RAM but what is more important for intersection 
speeds in OSG, RAM use or CPU number crunching?


Thank you,
--Maxim

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





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

Re: [osg-users] GL3 Profile

[Maxim Stere]

Made a PR #570

I will investigate windows GL libraries further, and see if I can make the 
Kronos GL headers work on windows without much modifications. 
If I succeed I'll make another PR with fixes that will give users full GL 
functionality on Windows.


Thank you,
--Maxim

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





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

[osg-users] [forum] Android can't build osgdb_png

[lin hui]

Hi,

I'm building Android libs on Windows, other 3rdparty libs like osgdb_jpeg  can 
all be build, except osgdb_png , is there something special and i missed?


Thank you!

Cheers,
lin

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





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

Re: [osg-users] The naming of VulkanSceneGraph

[Robert Osfield]

On Thu, 28 Jun 2018 at 14:53, Eric Sokolowsky  wrote:
> Trademark holders *must* defend their trademarks, or they lose them.

Indeed this is true.  It's only part of the story though.

Khronos mission is to develop and promote open APIs, as part of this
they trademark projects they undertake, they also develop APIs then
promote their use.  If Khronos do view VulkanSceneGraph as potentially
infringing then we'll need to discuss with them about granting
permission to use this name, the benefit for Khronos is the it is
significant step in promoting their own cause.

We have three options:

  1) Ignore the issue, if Khronos decide they want to discuss the name
then deal with it then.

  2) Reach out to Khronos and be co-operative

  3) Change the name to something else less relevant

Currently, approach 2 is what Chris has kicked off, no response yet,
so we may need to reach out a bit further.

I am about head off on holiday for a week so won't be doing any
chasing up myself right away.

With Siggraph coming up this might be a good time to reach out and
chat face to face. I won't personally be attending, but If you are
attending then let us know.

The project is less than a month old, so I'm not too concerned about
things as they stand right now.  If things don't go the way I'd prefer
then we just fallback to 3, the design and code won't change, it'd be
a wasted opportunity and bit of money spent on URLs but nothing major.

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

Re: [osg-users] Conan C++ dependency manager

[Julien Valentin]

Hi,

I forgot to add the plugin path to PATH in the script
You can contribute to add something like this and make a PR...

it would be something like it
osgPlongins="release dependant plugin path"
self.env_info.PATH.append(os.path.join(self.package_folder, osgPlongins))

Cheers


cfjob wrote:
> Hi,
> I encounter a problem that the osgDB::readImageFile can not read the image 
> files.
> I know that the osgDB need related plugins to read files, and I uploaded the 
> osgPlugins folder with other osg libs. It seems conan didn't let osg find the 
> plugins, did anyone encounter similar problem? How to deal with it?
> 
> 
> mp3butcher wrote:
> > You can test current recipes and improve them...
> > https://github.com/mp3butcher/osg_conan_recipe
> > 
> > Edit:
> > Here's a blog from a guy that have more experience with conan than me
> > https://www.micheleadduci.net/blog/2017/02/05/Fourteen-days-with-conan/
> > It points some CMake limitations I haven't experienced with Ubuntu and 
> > win32 package...
> > 
> > 
> > Chris Hanson wrote:
> > > I've been hoping for Conan support for OSG for some time.
> > > 
> > > Python is a complex tool, but powerful, and I'm willing to accept its 
> > > complexity in return for what it can do.
> > > 
> > > 
> > > On Sun, Feb 4, 2018 at 2:05 PM, Julien Valentin < ()> wrote:
> > > 
> > > > https://www.youtube.com/watch?v=nLdB1ErncBg 
> > > > (https://www.youtube.com/watch?v=nLdB1ErncBg)
> > > > 
> > > > 
> > > > mp3butcher wrote:
> > > > 
> > > > > Thanks for the link
> > > > > I didn't know this tool, i should test it
> > > > > 
> > > > > In conan, there's tools to download, to unzip, to invoke system 
> > > > > package manager, virtual runtime environment (manage env vars)
> > > > > python makes conan sexy and flexible.
> > > > > Further it manages dependancies (will dl what missing 
> > > > > -sourcesORbuilt- for the recipe you wanna build package for)
> > > > > I know they're trying to do business with package hosting, but who 
> > > > > can blame them
> > > > > 
> > > > > I don't know if all these features are included in hunter...
> > > > > If you have knowledge about hunter, can you provide us a simple 
> > > > > example apply to osg win32 package?
> > > > > 
> > > > > Cheers
> > > > > 
> > > > > 
> > > > > remoe wrote:
> > > > > 
> > > > > > Hi All,
> > > > > > 
> > > > > > Why they use python? Python itself has complicated dependencies. 
> > > > > > Someone has wrote a CMake based system:
> > > > > > 
> > > > > > https://github.com/ruslo/hunter (https://github.com/ruslo/hunter)
> > > > > > 
> > > > > > Or write your own in GoLang :)
> > > > > > 
> > > > > > Cheers,
> > > > > > Remo
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > --
> > > > Read this topic online here:
> > > > http://forum.openscenegraph.org/viewtopic.php?p=72923#72923 
> > > > (http://forum.openscenegraph.org/viewtopic.php?p=72923#72923)
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > osg-users mailing list
> > > >  ()
> > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > > >  
> > > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > -- 
> > > Chris 'Xenon' Hanson, omo sanza lettere.  http://www.alphapixel.com/ 
> > > (http://www.alphapixel.com/)
> > > Training • Consulting • Contracting
> > > 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 
> > > • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> > > Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • 
> > > Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • 
> > > Android
> > > @alphapixel (https://twitter.com/alphapixel) facebook.com/alphapixel 
> > > (http://facebook.com/alphapixel) (775) 623-PIXL [7495]
> > > 
> > >  --
> > > Post generated by Mail2Forum
> > 
> 



Twirling twirling twirling toward freedom

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





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

Re: [osg-users] Open to updates to the Doxygen configuration files?

[Orphen]

Hi Robert,

Thank you for your response. Laurens just coincidentally answered a 
similar question in the thread "[osg-users] OSG API Guides" earlier. I 
didn't realize we needed to set BUILD_DOCUMENTATION:BOOL=ON when running 
CMake, and I didn't know the make target existed, either.


With his and your answers combined, I was able to generate the 
documentation for OSG 3.7 with Doxygen 1.8.13 without a hitch.


Should we list these steps in the README? Without finding them there, I 
poked around the OSG website and found what I thought were the official 
steps 
(http://www.openscenegraph.org/index.php/documentation/user-guides/106-create-doxygen-documentation). 
This is what led me to think the Doxygen files were malformed.


Thanks,
-Orphen


On 06/28/2018 12:44 AM, Robert Osfield wrote:

Hi Orphen,

On Thu, 28 Jun 2018 at 07:52, Orphen  wrote:

I tried to build the Doxygen documentation on master today using Doxygen
1.8. The Doxyfiles are a bit dated, and some parts are malformed (ex:
environment variable expansion). This causes Doxygen to report some
errors and then give up.

Which version of the OSG are you seeing issues with?  Later versions
should be more up to date w.r.t Doxygen.

With the OpenSceneGraph-3.6 branch I just ran:

make doc_openscenegraph

And it worked without warnings or errors.  My doxygen version is:

$ doxygen -v
1.8.11

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] OSG API Guides

[Maxim Stere]

Ah, got it!

It looks like the instructions on 
http://www.openscenegraph.org/index.php/documentation/guides/user-guides/106-create-doxygen-documentation
Are wrong.

You first need to run cmake on the solution with BUILD_DOCUMENTATION:BOOL=ON

Then if you are in Windows you need to manually tell VS to build the 
doc_openscengraph, building ALL_BUILD will not do it. 

If you want to do it manually, then after running cmake with 
BUILD_DOCUMENTATION:BOOL=ON you need to do:


Code:

cd c:\development\OpenSceneGraph (or what ever folder you have it in)
export OSGHOME=`c:\development\OpenSceneGraph` or set if you are on windows
doxygen doc/core_Doxyfile not doxygen doc/Doxyfiles/core_Doxyfile




That will run the cmake generated doxy file...


Thank you,
--Maxim

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





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

Re: [osg-users] The naming of VulkanSceneGraph

[Eric Sokolowsky]

Trademark holders *must* defend their trademarks, or they lose them.

On Mon, Jun 25, 2018 at 6:43 PM, Chris Hanson  wrote:

> I think the Vulkan compliance tests (and name usage) only applies to
> implementations OF the Vulkan API. I don't think it applies to software
> USING Vulkan.
>
> I think VulkanSceneGraph is a good and descriptive name, I just don't want
> to see a lot of activity sunk into that name and then have it torpedoed by
> Khronos as I feel might happen.
>
> Trademark holders are notably defensive about their properties, whether we
> like that or not.
>
>
>
> On Mon, Jun 25, 2018 at 12:51 PM Curtis Rubel  wrote:
>
>> Hi,
>>
>>  https://www.khronos.org/vulkan/adopters/
>>
>>  I think this page will alleviate anymore discussion, at
>> least it sounds pretty straight forward to me that as long as
>> VulcanSceneGraph passes their tests it seems OK to use the name.
>> Of course I am no a lawyer either but this text seems to be pretty
>> simple and in laymen's terms.
>>
>> Cheers,
>> Curtis
>>
>> --
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=74159#74159
>>
>>
>>
>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> --
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
> http://www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4
> • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
> osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
> iPhone/iPad/iOS • Android
> @alphapixel  facebook.com/alphapixel (775)
> 623-PIXL [7495]
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Constructor parameters of osg::Uniform

[Werner Modenbach]

Am 28.06.2018 um 15:03 schrieb Robert Osfield:
> On Thu, 28 Jun 2018 at 13:57, Robert Osfield  wrote:
>> The original osg::Uniform class is a bit of unwieldy mess. In
>> hindsight we shouldn't have gone for this particular implementation as
>> it's a bit too open ended.
> As a bit of background, Mike Weiblen with a bit of input from myself
> created the GLSL support for the OSG before OpenGL 2.0 came out and on
> prototype drivers.  It was completely bleeding edge of OpenGL as well
> as trying to implement this stuff in scene graphs, there was no prior
> art, it was very much winging it.  The fact that is has lasted so long
> without a major rewrite suggests Mike came up with reasonable
> solution.
>
> The first git log entry for osg::Uniform is :
>
> Date:   Thu Feb 24 13:33:35 2005 +
>
> From Mike Weiblen, adding prelimimnary GL Shader Language support
> into core OSG lib.
>with renaming and reordering by Robert Osfield,
>
> 13 years later it's easy to spot better ways of doing it, but kinda
> cool this stuff was once pushing things forward - this work was even
> used a demo at the OpenGL BOF that GLSL/2,0 was launched :-)
>
> Robert.

-- 
*TEXION Software Solutions, Rotter Bruch 26a, D-52068 Aachen*
Phone: +49 241 475757-0
Fax: +49 241 475757-29
Web: http://texion.eu
eMail: i...@texion.eu
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Constructor parameters of osg::Uniform

[Werner Modenbach]

It would be the easiest putting an "explicit " in front of the
constructor but I guess there would be far to many reclaims then :)

- Werner -

Am 28.06.2018 um 15:03 schrieb Robert Osfield:
> On Thu, 28 Jun 2018 at 13:57, Robert Osfield  wrote:
>> The original osg::Uniform class is a bit of unwieldy mess. In
>> hindsight we shouldn't have gone for this particular implementation as
>> it's a bit too open ended.
> As a bit of background, Mike Weiblen with a bit of input from myself
> created the GLSL support for the OSG before OpenGL 2.0 came out and on
> prototype drivers.  It was completely bleeding edge of OpenGL as well
> as trying to implement this stuff in scene graphs, there was no prior
> art, it was very much winging it.  The fact that is has lasted so long
> without a major rewrite suggests Mike came up with reasonable
> solution.
>
> The first git log entry for osg::Uniform is :
>
> Date:   Thu Feb 24 13:33:35 2005 +
>
> From Mike Weiblen, adding prelimimnary GL Shader Language support
> into core OSG lib.
>with renaming and reordering by Robert Osfield,
>
> 13 years later it's easy to spot better ways of doing it, but kinda
> cool this stuff was once pushing things forward - this work was even
> used a demo at the OpenGL BOF that GLSL/2,0 was launched :-)
>
> Robert.

-- 
*TEXION Software Solutions, Rotter Bruch 26a, D-52068 Aachen*
Phone: +49 241 475757-0
Fax: +49 241 475757-29
Web: http://texion.eu
eMail: i...@texion.eu
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Constructor parameters of osg::Uniform

[Robert Osfield]

On Thu, 28 Jun 2018 at 13:57, Robert Osfield  wrote:
> The original osg::Uniform class is a bit of unwieldy mess. In
> hindsight we shouldn't have gone for this particular implementation as
> it's a bit too open ended.

As a bit of background, Mike Weiblen with a bit of input from myself
created the GLSL support for the OSG before OpenGL 2.0 came out and on
prototype drivers.  It was completely bleeding edge of OpenGL as well
as trying to implement this stuff in scene graphs, there was no prior
art, it was very much winging it.  The fact that is has lasted so long
without a major rewrite suggests Mike came up with reasonable
solution.

The first git log entry for osg::Uniform is :

Date:   Thu Feb 24 13:33:35 2005 +

From Mike Weiblen, adding prelimimnary GL Shader Language support
into core OSG lib.
   with renaming and reordering by Robert Osfield,

13 years later it's easy to spot better ways of doing it, but kinda
cool this stuff was once pushing things forward - this work was even
used a demo at the OpenGL BOF that GLSL/2,0 was launched :-)

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

Re: [osg-users] Constructor parameters of osg::Uniform

[Robert Osfield]

On Thu, 28 Jun 2018 at 13:06, Sebastian Messerschmidt
 wrote:
> @Robert:
> Any insights?

The original osg::Uniform class is a bit of unwieldy mess. In
hindsight we shouldn't have gone for this particular implementation as
it's a bit too open ended.

In master I have written a osg::UniformBase class and a template
uniform class that enables use to create a series of explictly typed
uniforms such as IntUnfirom, FloatUnfiorm etc.  This scheme is a bit
more robust when it comes to being able to easily pick the type you
want.

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

Re: [osg-users] Constructor parameters of osg::Uniform

[Sebastian Messerschmidt]

Hi Werner,



Hi all,

I recently discovered a strange case in creation of a Uniform:

farRadiusRescaleUniform=newosg::Uniform("farRadiusRescale",2.0f);

The only constructor I could find is like that:

Uniform(Typetype,conststd::string,intnumElements=1);

The wrong construction sometimes leads to unexpected results.
Why is the compiler not reclaming about this mismatch in parameters?


This is called implicit conversion and is totally legal.
In order to make to compiler avoid implicit conversion it can be tagged 
as explicit. As i've tumbled over this one more than once it might 
acutally be a good idea to change the uniform constructors which take 
only the name and "numElements".


@Robert:
Any insights?

Cheers
Sebastian



- Werner -


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


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

[osg-users] Constructor parameters of osg::Uniform

[Werner Modenbach]

Hi all,

I recently discovered a strange case in creation of a Uniform:

farRadiusRescaleUniform=newosg::Uniform("farRadiusRescale",2.0f);

The only constructor I could find is like that:

Uniform(Typetype,conststd::string,intnumElements=1);

The wrong construction sometimes leads to unexpected results.
Why is the compiler not reclaming about this mismatch in parameters?

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

Re: [osg-users] Exporting OpenFlight Models

[Daniel Emminizer, Code 5773]

Hi Robert,

Thanks for the merge!  It helps.


A little explanation, if you have any interest.  It's a little long, but I hope 
to explain why we're looking at Core Profile.  I'd like to think it's for good 
reason.

I'm with you on the OSX issues.  I think it's a shame about what's going on 
over there.  I've seen your comments on the mailing list about their direction 
of development and I do agree with it.

However, core profile isn't a requirement only on OSX.  We have a lot of users 
that run our software on a variety of hardware and platforms, supporting 
primarily Windows and RedHat systems, but also other Linux variants, on both 
real and virtual hardware.  In a perfect world, everyone is using a reasonable 
graphics card (better than an etch-a-sketch) with good drivers.  But what we've 
found is far from that.

Requirements wise, we're using osgEarth on top of OSG.  They're invested pretty 
heavily in Interface Blocks ( 
https://www.khronos.org/opengl/wiki/Interface_Block_(GLSL) ), which require 
OpenGL 3.1 (GLSL 1.4), but there are also several shaders that start to push 
into GLSL 3.3 territory (GLSL 3.3).  Ultimately we have a required minimum 
version of OpenGL in the 3.3 territory. That is no problem on most systems.

But we've run into more issues on three system configurations in particular:

* VMware systems running Windows using hardware acceleration
* Linux systems running Intel drivers (open source)
* Linux systems running Nvidia cards with open source drivers

In all three of these systems, we're seeing Mesa-based accelerated systems 
where core profile is supported somewhere between version GL 3.3 and GL 4.2.  
But compatibility profile support is extremely lacking.  Some of these systems 
report "high" OpenGL versions of 2.0, with GLSL shader versions of 1.4 or 1.5 
(note the official mismatch between OpenGL version and GLSL version).  Others 
support only OpenGL 1.x, with GLSL versions as low as 1.2 in compatibility 
profile.

But they have full core profile support.

We're stuck with these systems because we don't get to configure the hardware 
on our users' systems.  The third bullet in particular can be frustrating 
because the users have good hardware, but are unable (for a variety of reasons) 
to install the proprietary drivers that address these issues.


As I understand, some of the newer Mesa drivers are pushing towards better 
compatibility profile support.  While that's great, we've seen a drastic 
difference in correctness of compatibility profile features across Nvidia to 
ATI to Intel drivers.  Now there's Mesa drivers to consider too, and the 
various related variants.  We've noticed fewer differences (bugs) as we migrate 
towards a more shader-heavy infrastructure and away from relying on 
compatibility profile, er, hacks.

However, even if Mesa were to support better compatibility mode drivers, that 
does not help us now, where we are stuck supporting RedHat 6 and RedHat 7 
machines with the much older Mesa implementations.

Simply telling our users they must upgrade their hardware and drivers isn't a 
reasonable path forward; in many cases they cannot.  We could try to back up to 
OpenGL 1.x and GLSL 1.2 to hit lowest common denominator, but that is extremely 
limiting, and would take a great deal of effort.  Vulkan isn't an option for 
hopefully obvious reasons.  Our remaining option to run on these systems is 
Core Profile.

Core Profile is supported on far more systems past 3.3 since Compatibility 
Profile is optional.  It's messy comparatively and although I don't like it, I 
understand why Compatibility Profile support is more dicey for drivers to 
implement correctly (or at all in some cases)

I also understand your desire to want to support and push primarily 
Compatibility Profile.  Mixing and matching the two is messy, and requiring a 
full new build of OpenSceneGraph to run on systems that only support Core 
Profile can be painful, at least on the Windows side, due to long build times 
(thanks MSVC) and poor system support for modern GL (e.g. glcorearb.h 
discussion in the last week).  But that's our problem to deal with, not 
necessarily yours, and that's OK.

Anyways, I just wanted to point out that it's more than just OSX that needs 
Core Profile.  If you're doing anything with more modern GLSL you'll also need 
to be looking at Core Profile, or you'll lock yourself away from a reasonable 
segment of a potential user base.  And unlike Vulkan, support for Core Profile 
seems to be pretty reasonable across drivers for hardware that's been deployed 
in the last 8 years, at least in our particular user base.

I appreciate your receptiveness to patches that help with Core Profile support. 
 The work you did on VAO and Text in particular have been invaluable.  Thanks 
for your work on OpenSceneGraph.  Sorry for the long message.

 - Dan

 

> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of 

Re: [osg-users] Conan C++ dependency manager

[Ben Chern]

Hi,
I encounter a problem that the osgDB::readImageFile can not read the image 
files.
I know that the osgDB need related plugins to read files, and I uploaded the 
osgPlugins folder with other osg libs. It seems conan didn't let osg find the 
plugins, did anyone encounter similar problem? How to deal with it?


mp3butcher wrote:
> You can test current recipes and improve them...
> https://github.com/mp3butcher/osg_conan_recipe
> 
> Edit:
> Here's a blog from a guy that have more experience with conan than me
> https://www.micheleadduci.net/blog/2017/02/05/Fourteen-days-with-conan/
> It points some CMake limitations I haven't experienced with Ubuntu and win32 
> package...
> 
> 
> Chris Hanson wrote:
> > I've been hoping for Conan support for OSG for some time.
> > 
> > Python is a complex tool, but powerful, and I'm willing to accept its 
> > complexity in return for what it can do.
> > 
> > 
> > On Sun, Feb 4, 2018 at 2:05 PM, Julien Valentin < ()> wrote:
> > 
> > > https://www.youtube.com/watch?v=nLdB1ErncBg 
> > > (https://www.youtube.com/watch?v=nLdB1ErncBg)
> > > 
> > > 
> > > mp3butcher wrote:
> > > 
> > > > Thanks for the link
> > > > I didn't know this tool, i should test it
> > > > 
> > > > In conan, there's tools to download, to unzip, to invoke system package 
> > > > manager, virtual runtime environment (manage env vars)
> > > > python makes conan sexy and flexible.
> > > > Further it manages dependancies (will dl what missing -sourcesORbuilt- 
> > > > for the recipe you wanna build package for)
> > > > I know they're trying to do business with package hosting, but who can 
> > > > blame them
> > > > 
> > > > I don't know if all these features are included in hunter...
> > > > If you have knowledge about hunter, can you provide us a simple example 
> > > > apply to osg win32 package?
> > > > 
> > > > Cheers
> > > > 
> > > > 
> > > > remoe wrote:
> > > > 
> > > > > Hi All,
> > > > > 
> > > > > Why they use python? Python itself has complicated dependencies. 
> > > > > Someone has wrote a CMake based system:
> > > > > 
> > > > > https://github.com/ruslo/hunter (https://github.com/ruslo/hunter)
> > > > > 
> > > > > Or write your own in GoLang :)
> > > > > 
> > > > > Cheers,
> > > > > Remo
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > --
> > > Read this topic online here:
> > > http://forum.openscenegraph.org/viewtopic.php?p=72923#72923 
> > > (http://forum.openscenegraph.org/viewtopic.php?p=72923#72923)
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > osg-users mailing list
> > >  ()
> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > -- 
> > Chris 'Xenon' Hanson, omo sanza lettere.  http://www.alphapixel.com/ 
> > (http://www.alphapixel.com/)
> > Training • Consulting • Contracting
> > 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • 
> > GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> > Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • 
> > Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • 
> > Android
> > @alphapixel (https://twitter.com/alphapixel) facebook.com/alphapixel 
> > (http://facebook.com/alphapixel) (775) 623-PIXL [7495]
> > 
> >  --
> > Post generated by Mail2Forum
> 


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





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

Re: [osg-users] Open to updates to the Doxygen configuration files?

[Robert Osfield]

Hi Orphen,

On Thu, 28 Jun 2018 at 07:52, Orphen  wrote:
> I tried to build the Doxygen documentation on master today using Doxygen
> 1.8. The Doxyfiles are a bit dated, and some parts are malformed (ex:
> environment variable expansion). This causes Doxygen to report some
> errors and then give up.

Which version of the OSG are you seeing issues with?  Later versions
should be more up to date w.r.t Doxygen.

With the OpenSceneGraph-3.6 branch I just ran:

   make doc_openscenegraph

And it worked without warnings or errors.  My doxygen version is:

$ doxygen -v
1.8.11

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

Re: [osg-users] OSG API Guides

[L. Voerman]

The working doxyfiles are generated by cmake in the build folder.
(if BUILD_DOCUMENTATION:BOOL=ON)
Those will have these variables expanded.
Laurens.

On Tue, Jun 26, 2018 at 3:21 PM Maxim Stere  wrote:

> Just got a chance to sit down and try to build the documentation.
>
> Is the Doxy file created for linux only? Or is there another way to
> manually generate the docs?
>
> I'm getting:
>
> Code:
> error: tag HTML_FOOTER: footer file
> `${OpenSceneGraph_SOURCE_DIR}/doc/Doxyfiles/custom_Footer.html' does not
> exist
>
>
>
> when I run:
> D:\Development\OpenSceneGraph-3.6.1>C:\Program
> Files\doxygen\bin\doxygen.exe ./doc/Doxyfiles/core_Doxyfile
>
> ${OpenSceneGraph_SOURCE_DIR} seems to be a CMake variable?
> Should that be set somewhere?
>
> 
> Thank you,
> --Maxim
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74170#74170
>
>
>
>
>
> ___
> 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] Open to updates to the Doxygen configuration files?

[Orphen]

Hi Robert,

I tried to build the Doxygen documentation on master today using Doxygen 
1.8. The Doxyfiles are a bit dated, and some parts are malformed (ex: 
environment variable expansion). This causes Doxygen to report some 
errors and then give up.


Are you open to me updating the Doxyfiles?

Cheers,
-Orphen

PS: I'm aware of the at-least-first-name policy, respectfully; I go by 
Orphen ( :


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

[osg-users] OpenSceneGraph-3.6.2 release candidate 3

[Robert Osfield]

Hi All,

My plan is to tag 3.6.2 tomorrow, as there were two fixes yesterday
that I merged with the 3.6 branch I have made release candidate 3:

https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.2-rc3

Thanks for testing and feedback :-)

Robert.

-- ChangeLog since rc2

Wed, 27 Jun 2018 21:21:31 -0700
Author : Larry-Hu
Remove call to nonexistent member seekpos() of std::fpos in VS 2017
version 15.8 or later

Wed, 27 Jun 2018 12:57:20 -0400
Author : Daniel Emminizer
OpenFlight: Textures now correctly export in GLCORE mode.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org