Re: [osg-users] MSVS2015 3rdparty build

[Carl-Gustaf Kung]

bbjorn wrote:
> Well, there is no need to if you do not desire. The only thing you need to 
> do, is to point to the location of the source for each library you desire to 
> build. Heck, you can even skip the CMake GUI and do everything using CMake 
> command-line. Just supply the paths with using the -D flag and you are set. 
> That way you can integrated my CMake scripts in your automated build scripts. 
> Or you could just defined them as environment variables if that is more to 
> you liking.


Yeah, I understood that after your first post. Tryed this evening and I got it 
work, with some minor problems:

* Curl does not build. I pulled source from git, and I don't know if it is due 
to change in Curl or something else, but your cmake file is configured to 
include some sources which are not found in curl source. They are few 
curl_ntlm.c, curl_ntlm_msgs.c, curl_sasl_gssapi.c, curl_sasl_ssapi.c and 
http_negotiate_sspi. Anyway Curl comes with it's own cmake file which works 
fine "out of the box", so I have opted to comment it out completely from your 
top level cmake.

* Giflib failes due to missing strings.h included from "ported" getopt.h. I 
have included dummy strings.h which just includes standard string.h.
* Is liFtiff oficially promoted to liff? :-)

Thanks for help!

ha det fint :)

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





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

[osg-users] [build] DAE build failure.. dae.h not found

[Dave Sargrad]

Hi,
I almost figured out how to get dae built. At least its building now. I'm 
seeing the following build error:


> -- Build started: Project: Plugins dae, Configuration: Debug x64 --
> 190>  Building Custom Rule 
> C:/osg/OpenSceneGraph-3.4.0/OpenSceneGraph-3.4.0/src/osgPlugins/dae/CMakeLists.txt
> 190>  CMake does not need to re-run because 
> C:\osg\OpenSceneGraph-3.4.0\build64\src\osgPlugins\dae\CMakeFiles\generate.stamp
>  is up-to-date.
> 190>  daeReader.cpp
> 190>c:\osg\openscenegraph-3.4.0\openscenegraph-3.4.0\src\osgplugins\dae\daeReader.h(19):
>  fatal error C1083: Cannot open include file: 'dae.h': No such file or 
> directory
> 190>  daeRAnimations.cpp
> 190>c:\osg\openscenegraph-3.4.0\openscenegraph-3.4.0\src\osgplugins\dae\daeReader.h(19):
>  fatal error C1083: Cannot open include file: 'dae.h': No such file or 
> directory
> 190>  daeRGeometry.cpp
> 190>c:\osg\openscenegraph-3.4.0\openscenegraph-3.4.0\src\osgplugins\dae\daeReader.h(19):
>  fatal error C1083: Cannot open include file: 'dae.h': No such file or 
> directory
> 190>  daeRMaterials.cpp
> 190>c:\osg\openscenegraph-3.4.0\openscenegraph-3.4.0\src\osgplugins\dae\daeReader.h(19):
>  fatal error C1083: Cannot open include file: 'dae.h': No such file or 
> directory
> 190>  daeRSceneObjects.cpp
> 190>c:\osg\openscenegraph-3.4.0\openscenegraph-3.4.0\src\osgplugins\dae\daeReader.h(19):
>  fatal error C1083: Cannot open include file: 'dae.h': No such file or 
> directory
> 190>  daeRSkinning.cpp
> 190>c:\osg\openscenegraph-3.4.0\openscenegraph-3.4.0\src\osgplugins\dae\daeReader.h(19):
>  fatal error C1083: Cannot open include file: 'dae.h': No such file or 
> directory
> 190>  daeRTransforms.cpp
> 190>c:\osg\openscenegraph-3.4.0\openscenegraph-3.4.0\src\osgplugins\dae\daeReader.h(19):
>  fatal error C1083: Cannot open include file: 'dae.h': No such file or 
> directory
> 190>  daeWAnimations.cpp
> 190>c:\osg\openscenegraph-3.4.0\openscenegraph-3.4.0\src\osgplugins\dae\daeWriter.h(49):
>  fatal error C1083: Cannot open include file: 'dae.h': No such file or 
> directory
> 190>  daeWGeometry.cpp



Can you please tell me what I might be missing?

Thank you!

Cheers,
Dave

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





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

Re: [osg-users] Best Pipeline For Integrating Blender Models?

[Christian Buchner]

My workflow is to export the model from Blender to one of OBJ, DAE
(Collada) or FBX and to check in osgviewer which of these formats has less
issues. Then I run osgconv to convert it into OSG, OSGT, IVE or OSGB
formats as needed.

Christian


2016-06-05 21:05 GMT+02:00 Dave Sargrad :

> Hi.
> I'm trying to get the daereader plugin built. Not sure what I need to do
> in cmake.
>
> I've gone into the collada section and I have filled out the collada
> entries that I think I might have to set, really am not sure how to set
> them properly.
>
> https://drive.google.com/open?id=0BzUf-8Ad-iIkclpDdEpYV19FVVk
>
> I dont see the dae reader plugin show up in my project. Also I see the
> following error when i try to do an INSTALL
>
>
> > 1>  CMake Error at src/osgPlugins/dae/cmake_install.cmake:32 (file):
> > 1>file INSTALL cannot find
> > 1>
> "C:/osg/OpenSceneGraph-3.4.0/build64/bin/osgPlugins-3.4.0/osgdb_daed.dll".
> > 1>  Call Stack (most recent call first):
> > 1>src/osgPlugins/cmake_install.cmake:61 (include)
> > 1>src/cmake_install.cmake:52 (include)
> > 1>cmake_install.cmake:96 (include)
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=67423#67423
>
>
>
>
>
> ___
> 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,

OK, I am testing a patched FindFreetype.cmake with OSG now. If that works I'll 
submit it to CMake and to OSG. If it is better to post it to the 
osg-submissions list rather than here I can do that but it is then separate 
from the context of this discussion.

It doesn't seem practical for us to fix freetype but I'll file a suggestion 
with them to reconsider this build approach. For now, with a wiki note on 
refreshing the source, the only freetype improvement we can benefit from is 
making osgPlugins/freetype/CMakeLists.txt able to add PNG_LIBRARY (or other 
freetype optional libs?) to the target libraries if needed. I don't know enough 
CMake yet to do that automatically and adding a variable to pass to the cmake 
call seems like cruft. If OSG has no benefit from PNG support in freetype then 
a note not to enable it is probably the way to go.

Cheers,
Stuart

On 6/5/2016 7:41 AM, Robert Osfield wrote:

HI Stuart,

It sounds like taking the CMake FindFreetype.cmake modifying to work
and then getting this checked over by the cmake community as being
suitable for them to merge and then sending the final rev along to me
to merge would enable us to roll out the improved support prior to the
next CMake release.  If the CMake release is made before we push out
3.6 then we wouldn't need to add it locally.

With the freetype wiring to PNG+ZLIB, this sounds like the could
improve things with their own source/build system.  I don't know
freetype well enough to know how easy it would be to fix things to
make it easier to switch.  This type of issue is why the OSG has
plugins and NodeKits - the core libraries are kept with minimal
dependencies, this way the dependency chain doesn't pollute anything
more than it needs to.

Robert.



On 5 June 2016 at 02:35, Stuart Mentzer  wrote:

Hi Robert,

I have asked the CMake community about updating their FindFreetype.cmake to
support Windows debug library naming and I will follow up to try and get
that fixed in upcoming releases. I was pointed to how they do it correctly
for zlib so I could make a variant of their FindFreetype.cmake for OSG to
use until their fix is released. This would retain their support for the old
and new include structure. If you'd like me to submit that let me know.

Wrt the PNG on/off issue, I now understand the approach they use. The upshot
is that as long as you refresh the freetype source tree you are building
with from the original code before each build you can switch PNG support on
or off in the cmake command with -DWITH_PNG=ON or OFF and without manually
editing ftoption.h. (Same holds for ZLIB support.) The reason is that the
build goes in and modifies ftoption.h in the source tree (as well as making
a copy in the build tree) and the modification only uncomments those
defines, so you can't build with PNG enabled and then PNG disabled without
refreshing the source first. This is an unfortunate approach but that is
what we are stuck with. Most builders don't switch the PNG or ZLIB support
on and off so this probably doesn't often trip people up. The best we can
probably do is add a note on an appropriate wiki page. I added this refresh
step to my build scripts.

Stuart

On 6/4/2016 3:36 PM, Robert Osfield wrote:

Hi Stuart,

It sounds like the version of Freestyle is broken or it requires a tweak to
configuration. Have you approached the freetype community about these
issues.

The debug vs release issue is something that would be worth raising with the
cake community as it sounds like a revision to their Findfreetype.cmake.

Robert

On 3 Jun 2016 11:24 p.m., "Stuart Mentzer"  wrote:

Hi Robert,

Here's what I found doing release and debug builds from yersterday's git
master code with Visual C++ 2015:

freetype even using -DWITH_PNG=OFF will still try to include png.h and for
some reason requires ftoption.h (both copies) to be modified (or overridden)
to comment out the line:
#define FT_CONFIG_OPTION_USE_PNG
This is unfortunate and actually makes it easier to build freetype with
PNG support. With the freetype mods OSG builds including the freetype
plugin. Configuring freetype with or without PNG support is up to the
builder but it would be good if the CMakeLists.txt could handle both
situations without needing changes like I made.

The freetype build headers under include\freetype2\freetype even though
freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG
doesn't really need to ship with freetype or other 3rd party lib headers.

The debug build is able to build freetype with the same mods but the OSG
build doesn't find it:
-- Could NOT find Freetype (missing:  FREETYPE_LIBRARY) (found version
"2.6.3")
which I assume is due to not looking for the name freetyped, as I found
with my OSG 3.4.0 build. So the OSG build can complete but it won't build
the freetype plugin.

The debug build fails at "Installing the project..." because it appears
something is wrong with the 

Re: [osg-users] osg::View NO_LIGHT bug?

[Julien Valentin]

If you don't want any light in your scene
You just  have to
setMode(GL_LIGHTING,OFF,OVERRIDE) on you root's stateset
Hope it helps


Ben Axelrod wrote:
> I cannot seem to turn off the light in osg::View. I can change it between 
> headlight and sky light, but when I try NO_LIGHT, I still get the headlight. 
> 
> > _viewer->getCamera()->getView()->setLightingMode(osg::View::SKY_LIGHT); 
> > //works
>  
> 
> > _viewer->getCamera()->getView()->setLightingMode(osg::View::HEADLIGHT); 
> > //works
>  
> 
> > _viewer->getCamera()->getView()->setLightingMode(osg::View::NO_LIGHT); 
> > //still get headlight
>  
> 
> How can I turn off this default light? How is it related to the osg::Lights 
> in the scene? I noticed when I add an osg::Light, then the headlight is 
> overridden. How can I change the light parameters of the SKY_LIGHT or 
> HEADLIGHT? 
> 
> I am using osg version 2.6. 
> 
> Thanks, 
> -Ben
> 
>  --
> Post generated by Mail2Forum


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





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

Re: [osg-users] osg::View NO_LIGHT bug?

[Nickolai Medvedev]

Well, we can deceive viewer if we make so:


Code:
viewer.getLight()->setAmbient(osg::Vec4(0.0,0.0,0.0,1.0));
viewer.getLight()->setPosition(osg::Vec4(0.0,0.0,0.0,1.0));
viewer.getLight()->setDiffuse(osg::Vec4(0.0,0.0,0.0,1.0));
viewer.getLight()->setConstantAttenuation(0.003);
viewer.getLight()->setLinearAttenuation(0.1);
viewer.getLight()->setQuadraticAttenuation(0.1);
viewer.getLight()->setName("global_light");
viewer.getLight()->setLightNum(0);

viewer.setLightingMode(osg::View::SKY_LIGHT);



The light source still be exist, but will be invisible.

Cheers,
Nickolai

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

The included CMakeLists file is for the 3ds plugin.

My suggestion is to disable the variable shadowing warnings for this project, 
since it is basically an external library although included as source files. 
The other option is to fix all the variable name reuse for that project, which 
feels kind of unnecessary as lib3ds is pretty much abandoned as project (no 
activity since 2013). Autodesk has also stopped their development of this 
format years ago.

Regards
Björn


Från: osg-users  för Robert Osfield 

Skickat: den 4 juni 2016 19:42:10
Till: OpenSceneGraph Users
Ämne: Re: [osg-users] Preparing to make 3.5.3 dev release, please test

Hi François,

I have removed the register keyword usage from
Matrix_implementation.cpp and added the "" to the CMakeLists.txt.
These changes are now checked into git mater.

Robert.

On 4 June 2016 at 16:23, François Bérard  wrote:
> Hi Robert,
>
> On 3/6/16 18:46, Robert Osfield wrote:
>>
>> Rather than add this to the root CMakeLists.txt file I have added a
>> Clang specific section to the src/osgPlugins/cfg/CMakeLists.txt thus:
>>
>> # lex/yacc generated files use register that causes warnings with
>> CLang under OSX so disable this warnings.
>> IF(${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
>> SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wno-deprecated-register)
>> ENDIF()
>>
>> This is now checked into master.  Could remove you your own mds and test
>> this?
>
>
> there is a small pb which breaks the build:
>
> Scanning dependencies of target osgdb_cfg
> [ 79%] Building CXX object
> src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/CameraConfig.cpp.o
> clang: error: no input files
> /bin/sh: -Wno-deprecated-register: command not found
> make[2]: ***
> [src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/CameraConfig.cpp.o] Error 127
> make[1]: *** [src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/all] Error 2
> make: *** [all] Error 2
>
>
> adding double quotes fixes it:
>
>  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated-register")
>
> Also, the warning appears in osg/Matrix_implementation.cpp (see attached
> log), you may want to add the definition to the CMakelist of libosg. I tried
> by adding the IF block juste before the SETUP_LIBRARY, it worked. But
> removing the two register keywords in the matrix code may be the best
> approach: they are most probably always ignored by the compilers.
>
> ___
> 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
# List of C files to be compiled as C++ (else CMake sets ".c" to be compiled as 
pure C)
SET(C_FILES
lib3ds/lib3ds_io.c# Modified to support OSG endianness
)

SET(TARGET_SRC
ReaderWriter3DS.cpp
WriterNodeVisitor.cpp
WriterCompareTriangle.cpp

${C_FILES}
lib3ds/lib3ds_atmosphere.c
lib3ds/lib3ds_background.c
lib3ds/lib3ds_camera.c
lib3ds/lib3ds_chunk.c
lib3ds/lib3ds_chunktable.c
lib3ds/lib3ds_file.c
lib3ds/lib3ds_light.c
lib3ds/lib3ds_material.c
lib3ds/lib3ds_math.c
lib3ds/lib3ds_matrix.c
lib3ds/lib3ds_mesh.c
lib3ds/lib3ds_node.c
lib3ds/lib3ds_quat.c
lib3ds/lib3ds_shadow.c
lib3ds/lib3ds_track.c
lib3ds/lib3ds_util.c
lib3ds/lib3ds_vector.c
lib3ds/lib3ds_viewport.c
)
SET(TARGET_H
WriterNodeVisitor.h
WriterCompareTriangle.h
lib3ds/lib3ds.h
lib3ds/lib3ds_impl.h
)

IF (MSVC)
#disable specific warning level 4 warnings:
#C4456 declaration of 'c' hides previous local declaration
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /wd4456")
ENDIF(MSVC)
 
 end var setup  ###
SETUP_PLUGIN(3ds)
ADD_DEFINITIONS( -DLIB3DS_STATIC )# lib3ds is included, so we need the 
flag
SET_SOURCE_FILES_PROPERTIES(${C_FILES} PROPERTIES LANGUAGE "CXX")# 
Force some files to be compiled as C++
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best Pipeline For Integrating Blender Models?

[Dave Sargrad]

Hi.
I'm trying to get the daereader plugin built. Not sure what I need to do in 
cmake.

I've gone into the collada section and I have filled out the collada entries 
that I think I might have to set, really am not sure how to set them properly.

https://drive.google.com/open?id=0BzUf-8Ad-iIkclpDdEpYV19FVVk

I dont see the dae reader plugin show up in my project. Also I see the 
following error when i try to do an INSTALL


> 1>  CMake Error at src/osgPlugins/dae/cmake_install.cmake:32 (file):
> 1>file INSTALL cannot find
> 1>
> "C:/osg/OpenSceneGraph-3.4.0/build64/bin/osgPlugins-3.4.0/osgdb_daed.dll".
> 1>  Call Stack (most recent call first):
> 1>src/osgPlugins/cmake_install.cmake:61 (include)
> 1>src/cmake_install.cmake:52 (include)
> 1>cmake_install.cmake:96 (include)


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





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

[osg-users] Best Pipeline For Integrating Blender Models?

[Dave Sargrad]

Hi,

What is the recommended format for export from Blender and Import into OSG? I 
could use Collada (and integrate the Collada plugin into OSG), or I could use 
the Osg Exporter (Blender plugin). Which plugin is easy to use? Are they 
equivalent in functionality? 

In short, which avenue would you recommend? 
1] Use Blenders' OSG Exporter Plugin
or 
2] Use OSG's Collada Plugin

Thank you!

Cheers,
Dave

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





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

Re: [osg-users] MSVS2015 3rdparty build

[Björn Blissing]

memory_leak wrote:
> 
> When building with your cmakes I have tryed pretty much what you describe. 
> 1st i downloaded all code for every project in their respective folder, than 
> I put your cmake files in the respective folder and top level one in top 
> level directory where all other src folders were. 


No no... You should not move anything. Keep the files from GitHub as they are, 
otherwise the top level script may not find the scripts for each library.


memory_leak wrote:
> 
> Prospect of configuring manually each and every one did occur to me but I 
> have to admiit, not overly appealing :).
> 
> Now from your answer I understand  I should do some extra work to tell your 
> cmake from my batch file where to find things. That is probably reason why I 
> got only project files for "build all" and "install" but not individual 
> project files.


Well, there is no need to if you do not desire. The only thing you need to do, 
is to point to the location of the source for each library you desire to build. 
Heck, you can even skip the CMake GUI and do everything using CMake 
command-line. Just supply the paths with using the -D flag and you are set. 
That way you can integrated my CMake scripts in your automated build scripts. 
Or you could just defined them as environment variables if that is more to you 
liking.

Regards
Björn

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





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

Re: [osg-users] [build] x64 vs x86

[Dave Sargrad]

Thank you Sebastian.

I do use the CMake GUI. Which parameter do I need to modify in order to point 
to the correct compiler? Its not clear looking at the CMake parameters which 
one to modify. The only parameter that seems to reference Visual Studio happens 
to be CMAKE_LINKER. I dont see a CMAKE_COMPILER parameter.



SMesserschmidt wrote:
> Hi Dave,
> 
> Usually you simply have to choose the correct compiler (If you use the 
> CMakeGUI you need to check the "Visual Studio 12 2013 Win64").
> 
> 


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





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

Re: [osg-users] MSVS2015 3rdparty build

[Carl-Gustaf Kung]

Thanks for clafirications, I will give it another try.

Yeah, of course I don't expect everything to be superoptimized either. As 
mentioned I did managed to build each and every one manually as instructed by 
original libraries, and some with a bit of hacking (giflib). But I wish I could 
automate everything. Goal is to be able to fire up a batch script, get srcs 
from github (or with wget), configure everything and build without need to open 
any gui tool such as cmake. 

When building with your cmakes I have tryed pretty much what you describe. 1st 
i downloaded all code for every project in their respective folder, than I put 
your cmake files in the respective folder and top level one in top level 
directory where all other src folders were. I than opened cmake-gui and 
configured stuff for tope-level project, but it didn't build individual 
projects. Prospect of configuring manually each and every one did occur to me 
but I have to admiit, not overly appealing :). 

Now from your answer I understand  I should do some extra work to tell your 
cmake from my batch file where to find things. That is probably reason why I 
got only project files for "build all" and "install" but not individual project 
files.

The ting is I already have a batch script that will automaticly configure cmake 
variables depending on what compiler is present in my path, bitness and paths 
where I want stuff to build in and to install to, compiler flags etc. It works 
often time "out of the box so to say", but sometimes there are such cases as 
this where I have to figure out extra things to make it work.

Just fooling around with nick, my real name is as strange as nick, you wouldn't 
believe me anyway :).

Thanks for answer and best regards
/arthur

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





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

Re: [osg-users] [build] x64 vs x86

[Sebastian Messerschmidt]

Hi Dave,

Usually you simply have to choose the correct compiler (If you use the 
CMakeGUI you need to check the "Visual Studio 12 2013 Win64").

Also you'll need to use the correct 64bit-3rd-party libraries.
That should be all, the rest is taken care of by CMake.

Cheers
Sebastian

Hi,
I've been using OSG for a while now. I've never revisited the problem I had 
getting cmake to recognize that I have a 64 bit windows platform. So I've 
always been building/compiling using the x86 3rd party dependencies.

I've tried the obvious things like configuring the following cmake options to 
the x64 variants:
CMAKE_EXE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS

By default these options are set to /Machine:X86.

Yet of course when I configure the project I see the following:



32 bit architecture detected


The full CMAKE configuration that I am using may be seen here.
https://drive.google.com/open?id=0BzUf-8Ad-iIkVFZVd01BZFNkcUk

I'm using Visual Studio 2013 in a standard configuration. I'd think that its 
easy to get OSG to build for 64 bit. I'm clearly missing something very simple.

Can someone please point me to information that might help.


Thank you!

Cheers,
Dave[/quote]

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





___
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] [build] x64 vs x86

[Dave Sargrad]

Hi,
I've been using OSG for a while now. I've never revisited the problem I had 
getting cmake to recognize that I have a 64 bit windows platform. So I've 
always been building/compiling using the x86 3rd party dependencies.

I've tried the obvious things like configuring the following cmake options to 
the x64 variants:
CMAKE_EXE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS

By default these options are set to /Machine:X86.

Yet of course when I configure the project I see the following:


> 32 bit architecture detected


The full CMAKE configuration that I am using may be seen here.
https://drive.google.com/open?id=0BzUf-8Ad-iIkVFZVd01BZFNkcUk

I'm using Visual Studio 2013 in a standard configuration. I'd think that its 
easy to get OSG to build for 64 bit. I'm clearly missing something very simple.

Can someone please point me to information that might help.


Thank you!

Cheers,
Dave[/quote]

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





___
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

[Robert Osfield]

HI Stuart,

It sounds like taking the CMake FindFreetype.cmake modifying to work
and then getting this checked over by the cmake community as being
suitable for them to merge and then sending the final rev along to me
to merge would enable us to roll out the improved support prior to the
next CMake release.  If the CMake release is made before we push out
3.6 then we wouldn't need to add it locally.

With the freetype wiring to PNG+ZLIB, this sounds like the could
improve things with their own source/build system.  I don't know
freetype well enough to know how easy it would be to fix things to
make it easier to switch.  This type of issue is why the OSG has
plugins and NodeKits - the core libraries are kept with minimal
dependencies, this way the dependency chain doesn't pollute anything
more than it needs to.

Robert.



On 5 June 2016 at 02:35, Stuart Mentzer  wrote:
> Hi Robert,
>
> I have asked the CMake community about updating their FindFreetype.cmake to
> support Windows debug library naming and I will follow up to try and get
> that fixed in upcoming releases. I was pointed to how they do it correctly
> for zlib so I could make a variant of their FindFreetype.cmake for OSG to
> use until their fix is released. This would retain their support for the old
> and new include structure. If you'd like me to submit that let me know.
>
> Wrt the PNG on/off issue, I now understand the approach they use. The upshot
> is that as long as you refresh the freetype source tree you are building
> with from the original code before each build you can switch PNG support on
> or off in the cmake command with -DWITH_PNG=ON or OFF and without manually
> editing ftoption.h. (Same holds for ZLIB support.) The reason is that the
> build goes in and modifies ftoption.h in the source tree (as well as making
> a copy in the build tree) and the modification only uncomments those
> defines, so you can't build with PNG enabled and then PNG disabled without
> refreshing the source first. This is an unfortunate approach but that is
> what we are stuck with. Most builders don't switch the PNG or ZLIB support
> on and off so this probably doesn't often trip people up. The best we can
> probably do is add a note on an appropriate wiki page. I added this refresh
> step to my build scripts.
>
> Stuart
>
> On 6/4/2016 3:36 PM, Robert Osfield wrote:
>
> Hi Stuart,
>
> It sounds like the version of Freestyle is broken or it requires a tweak to
> configuration. Have you approached the freetype community about these
> issues.
>
> The debug vs release issue is something that would be worth raising with the
> cake community as it sounds like a revision to their Findfreetype.cmake.
>
> Robert
>
> On 3 Jun 2016 11:24 p.m., "Stuart Mentzer"  wrote:
>>
>> Hi Robert,
>>
>> Here's what I found doing release and debug builds from yersterday's git
>> master code with Visual C++ 2015:
>>
>> freetype even using -DWITH_PNG=OFF will still try to include png.h and for
>> some reason requires ftoption.h (both copies) to be modified (or overridden)
>> to comment out the line:
>> #define FT_CONFIG_OPTION_USE_PNG
>> This is unfortunate and actually makes it easier to build freetype with
>> PNG support. With the freetype mods OSG builds including the freetype
>> plugin. Configuring freetype with or without PNG support is up to the
>> builder but it would be good if the CMakeLists.txt could handle both
>> situations without needing changes like I made.
>>
>> The freetype build headers under include\freetype2\freetype even though
>> freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG
>> doesn't really need to ship with freetype or other 3rd party lib headers.
>>
>> The debug build is able to build freetype with the same mods but the OSG
>> build doesn't find it:
>> -- Could NOT find Freetype (missing:  FREETYPE_LIBRARY) (found version
>> "2.6.3")
>> which I assume is due to not looking for the name freetyped, as I found
>> with my OSG 3.4.0 build. So the OSG build can complete but it won't build
>> the freetype plugin.
>>
>> The debug build fails at "Installing the project..." because it appears
>> something is wrong with the new pdb installation support:
>> -- Installing: C:/OSG.VC.xd/bin/osgd.dll
>> CMake Error at src/osg/cmake_install.cmake:39 (file):
>>   file INSTALL cannot find
>>   "C:/Projects/OSG/VC.xd/OSG/src/osg/PREFIX-NOTFOUNDosgd.pdb".
>> Call Stack (most recent call first):
>>   src/cmake_install.cmake:33 (include)
>>   cmake_install.cmake:100 (include)
>> The osgd.pdb file is present and next to osgd.dll as expected.
>>
>> I see that others are reporting success with the Visual C++ 2015 build but
>> I don't know how they are addressing the freetype PNG issues or if they
>> tried the debug build yet. It looks like there are still some issues but
>> maybe they will offer some input here. I'm happy to make another pass if
>> that helps.
>>
>> Stuart
>>
>> --
>>