Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

[Stuart Mentzer]

  
  
Hi Chris,
Here's what I've got. You probably need to adjust the bat for
  your PATH setup. It isn't polished for general use yet so let me
  know if you have questions. I have only verified it with osgviewer
  so far: VC++ is (still!) too broken for MI + covariant returns to
  build my application so I have to refactor a bit before I can go
  further.
[The batch file is embedded in the text: most email systems block
  bat files.]

Stuart
--
  
Stuart G Mentzer
Objexx Engineering
Office  1.781.455.1150 x11
Mobile 1.781.708.3872

  
On 4/20/2016 5:23 PM, Chris Hanson
  wrote:


  
​Stuart, I am about to build OSG with VS2015 Community. Is your
build cookbook available somewhere so I'm not reinventing the
wheel?
  
  
  
  ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



  

OSG VC++ 2015 Build on Windows

Notes:
 mcd is a script for md then cd
 A subset of optional dependencies was used for this first try

cmake.VC.r.bat: (installs OSG to C:\OSG) (without /arch arg for build that 
works on generic CPU)
@echo off
setlocal
set 
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\bin;C:\MinGW\bin;C:\Git\cmd;C:\CMake\bin
set INCLUDE=
set LIB=
set LIBPATH=
call setVC14.64.bat
set CC=cl
set CXX=cl
del CMakeCache.txt >nul 2>nul
C:\CMake\bin\cmake.exe -G "MinGW Makefiles" -DCMAKE_COLOR_MAKEFILE:BOOL=0 
-DCMAKE_INSTALL_PREFIX="C:/OSG" -DCMAKE_BUILD_TYPE=RELEASE 
-DCMAKE_CXX_FLAGS_RELEASE="/nologo /EHsc /DNOMINMAX /DWIN32_LEAN_AND_MEAN 
/DNDEBUG /O2 /GS- /MD" -DCMAKE_C_FLAGS_RELEASE="/nologo /EHsc /DNOMINMAX 
/DWIN32_LEAN_AND_MEAN /DNDEBUG /O2 /GS- /MD" %*
make -j%NUMBER_OF_PROCESSORS% VERBOSE=true
make install
endlocal


zlib:
mcd zlib_build
..\cmake.VC.r.bat ../zlib
copy zconf.h ..\zlib

minizip: (after zlib)
option(USE_AES "enables building of aes library" OFF)
mcd minizip_build
..\cmake.VC.r.bat -DZLIB_LIBRARY:FILEPATH="../zlib_build/zlib.lib" 
-DZLIB_INCLUDE_DIR:PATH="../zlib" ../minizip

curl:
option(CURL_STATICLIB "Set to ON to build libcurl with static linking." ON)
mcd curl_build
..\cmake.VC.r.bat ../curl

freetype:
mcd freetype_build
..\cmake.VC.r.bat /I ../freetype

giflib:
copy osg-3rdparty-cmake\giflib\* giflib
mcd giflib_build
..\cmake.VC.r.bat -DGIFLIB_SOURCE_DIR:PATH="../giflib" -DSKIP_INSTALL_ALL=1 
../giflib

glut:
copy osg-3rdparty-cmake\glut\* glut
mcd glut_build
..\cmake.VC.r.bat -DGLUT_SOURCE_DIR:PATH="../glut" -DSKIP_INSTALL_ALL=1 ../glut

jpeg:
copy osg-3rdparty-cmake\libjpeg\* jpeg
mcd jpeg_build
..\cmake.VC.r.bat -DLIBJPEG_SOURCE_DIR:PATH="../jpeg" -DSKIP_INSTALL_ALL=1 
../jpeg

lpng: (after zlib)
mcd lpng_build
..\cmake.VC.r.bat -DZLIB_INCLUDE_DIR:PATH="../zlib" 
-DZLIB_LIBRARY:FILEPATH="../zlib_build/zlib" -DPNG_STATIC=1 ../lpng

tiff:
mcd tiff_build
..\cmake.VC.r.bat -DCMAKE_PREFIX_PATH:PATH=".." ../tiff
(not finding zlib, jpeg, ... packages)

Collect all 3rd party libraries in 3rdparty\lib directory and rename them:
freetype.lib
giflib.lib
glut32.lib
jpeg.lib
libcurl.lib
libcurl.dll
libcurl.dll.manifest
libpng16.lib(rename from libpng16_static.lib)
libpng16.dll
libpng16.dll.manifest
minizip.lib
tiff.lib
tiff.dll
tiff.dll.manifest
zlib.lib

Collect all 3rd party library headers in 3rdparty\include

OSG:

Put OSG 3.4.0 source in OSG directory

Top-level CMakeLists.txt:
 IF(MSVC) block (Use newest Windows Kits directory):
# Objexx
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} 
/LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" 
CACHE INTERNAL "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} 
/LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" 
CACHE INTERNAL "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} 
/LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" 
CACHE INTERNAL "" FORCE)
include_directories(AFTER "C:/Projects/OSG/freetype/include")
 Enable packages on this line and add C:\CMake\bin to PATH so cpack is found:
OPTION(BUILD_OSG_PACKAGES "Set to ON to generate CPack configuration files 
and packaging targets" ON)

mcd OSG_build
..\cmake.VC.r.bat ../OSG___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

[Chris Hanson]

​Stuart, I am about to build OSG with VS2015 Community. Is your build
cookbook available somewhere so I'm not reinventing the wheel?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Multipass Technique

[Alex Taylor]

Hi all,

I'm interested in trying out the MultiPassTechnique for for volume
rendering and I have a few questions after looking through the source code
and the example.

1) In the example, here is the description of the convex hull that can be
used by MultipassTechnique:

--hull","load 3D hull that defines the extents of the region to volume
render.

The hull is then read in from a file, if specified. My first question is,
what is the expected form of the geometry that one adds to the Tile via
addChild? It's not clear to me in the example without seeing an example of
a file that contains a hull.

2) There are different shaders and enums for three different scenarios:
CUBE, HULL, and CUBE AND HULL. What do each of these scenarios mean? When
would each be useful?

3) I'm interested in Multi-pass technique because I'd like to be able to
implement a clipping "ROI" defined by an data-axes aligned cube. Would it
be possible to define a cube shaped convex hull and have the portion of my
data that is inside be rendered and have the portion outside the cube be
clipped? Is this within the use cases that were in mind when Multipass
Technique was added?

I appreciate any help people can give me, I'd really like to get started
with MultipassTechnique, looks like a good addition to the library.

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

Re: [osg-users] osgEarth Feature multiple draw

[Michele Onnis]

Hi,

thanks for the reply,  now I can focus on the right solution. I will try to 
implement the chunk approach also :)
For any other questions related to osgEarth I will use the specific forum.

-- Michele

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





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

Re: [osg-users] get middle mouse event

[Trajce Nikolov NICK]

Hi Sebastian,

I think that is the proper way. Further you can get ea.getButtom() to
inspect which mouse button was pushed

Nick

On Wed, Apr 20, 2016 at 3:28 PM, Sebastian Schmidt 
wrote:

> Hi,
>
> I try to get the mouse event, when the middle button is pushed.
>
> By default the WindowManager receives the event, but unfortunately it is
> sent as normal mouse push to the widget.
>
> Is there any chance to catch this special event in my widget, without
> using the osgGA::GUIEventHandler?
> ...
>
> Thank you!
>
> Cheers,
> Sebastian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=66893#66893
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

[osg-users] get middle mouse event

[Sebastian Schmidt]

Hi,

I try to get the mouse event, when the middle button is pushed.

By default the WindowManager receives the event, but unfortunately it is sent 
as normal mouse push to the widget.

Is there any chance to catch this special event in my widget, without using the 
osgGA::GUIEventHandler?
... 

Thank you!

Cheers,
Sebastian

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





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

Re: [osg-users] osgEarth Feature multiple draw

[Glenn Waldron]

Michele,

Yours is the most appropriate approach. There isn't a way to do what you
want with an existing higher-level construct.

I developed a similar capability in a client application; we call it a a
"track history". You are correct that localizing the geometry will
eliminate jitter; however, if the track is long enough, you will need to
break the track into multiple chunks and localize each chunk.

By the way, there is a forum/list specifically for osgEarth-related
questions: http://forum.osgearth.org

Good luck!


Glenn Waldron

On Wed, Apr 20, 2016 at 3:38 AM, Michele Onnis 
wrote:

> Hi,
>
> I'm using the osgEarth library and I'm trying to draw Time Space Position
> Information datasets with a playback functionality. I want to draw the
> whole trajectory and then draw a subrange of the SAME trajectory, with a
> different style, for playback purposes: the playback subrange is
> "translated" over time to achieve the animation playback.
>
> In the first approach, I used two different node graphs based on
> osgEarth::Feature classes (Feature / Session / FeatureSource /
> FeatureModelGraph). I wanted to share the feature and specify two different
> draws of same feature (total range and partial range), but I could not find
> a way to do this. So, at every frame I add geometry to the playback feature
> and this action drops the framerate.
>
> To solve the problem, I've tried to switch to a "lower level"
> implementation based on osg::Geometry. In this case, I share the vertex
> array between the whole trajectory and the playback trajectory, then I
> specified two DrawArrays with different ranges for the different renders.
> The performance of this solution is perfect, but the geometry shows jitter
> problems related to the single precision of the GPU (geometry is specified
> in world coordinates).
>
> I know that in the second scenario I have to "localize" the geometry in a
> local origin to minimize the jitter, but I ask if there is a way to achieve
> the same results with the "higher level" approach (osgEarth::Feature
> classes), because I'd rather take advantage of all optimizations in this
> classes. So, how can I specify a single Feature and then specify multiple
> renders of the same Feature, with different ranges of the data and
> different styles?
>
> Thank you!
>
> Cheers,
> Michele
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=66886#66886
>
>
>
>
>
> ___
> 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] osgSim::GeographicLocation

[Sebastian Messerschmidt]

Am 20.04.2016 um 10:55 schrieb Robert Osfield:

Hi Sebastian,

On 20 April 2016 at 09:49, Sebastian Messerschmidt 
> wrote:


Am 20.04.2016 um 10:05 schrieb Robert Osfield:

Hi Sebastian,

On 20 April 2016 at 08:17, Sebastian Messerschmidt
> wrote:

Openflight databases seem to use this user-data at the root
node to describe the geographic base coordinates of
UTM-databases.
Unfortunately this class doesn't seem to have a serializer
for the osgXYZ file formats. What is the best way to add such
serialization capabilities?


Been a very very long time since I heard mention of the
osgSim::GeoographicLocation class...  just been sitting there
quietly minding it's own business.

The issue right now is, that I somehow have to distribute the
lat,lon origin in some OpenFlight centric workflow. I could
totally do this differently by transforming the information into
my own format.


Looking at the implementation now the two parameters that need to
be serialized at the latitude and longitude paramters.  If these
used the setName()/getName() convention then it'd be easy to add
serializers using the standard ADD_DOUBLE_SERIALIZER( Name, 0.0);
serializers (for instance see the usage in
src/osgWrappers/serializers/osg/ ).

As these don't follow the setName/getName() one will either have
to write a custom serializer for it or simply change the naming
across to the setName()/getName() convention that the almost all
of the OSG uses.  I'd be inclined to do the later. Then just add
the GeographicLocation serializers to the
src/osgWrappes/serializers/osgSim.  This would mean that the
change could only be add to OSG master and no backported to
OSG-3.4 or OSG-3.2 as the ABI would change, but personally I'd be
happy with this.

I'll try to do this then and present the submission when I find
the time.



The other route which would with recent OSG versions would be to copy 
the GeographicLocation data to the a Node's UserValue i.e.


  node->setValue("latitude", geographicLocation->latitude());
  node->setValue("longitude", geographicLocation->longitude));

The values then would be serialized automatically.


That's what I'm doing right now. It would be nice ot to lose the data 
when using osgconv however. So thanks for the pointer but I provide a 
general fix for it.

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] osgSim::GeographicLocation

[Robert Osfield]

Hi Sebastian,

On 20 April 2016 at 09:49, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

> Am 20.04.2016 um 10:05 schrieb Robert Osfield:
>
> Hi Sebastian,
>
> On 20 April 2016 at 08:17, Sebastian Messerschmidt <
> sebastian.messerschm...@gmx.de> wrote:
>
>> Openflight databases seem to use this user-data at the root node to
>> describe the geographic base coordinates of UTM-databases.
>> Unfortunately this class doesn't seem to have a serializer for the osgXYZ
>> file formats. What is the best way to add such serialization capabilities?
>>
>
> Been a very very long time since I heard mention of the
> osgSim::GeoographicLocation class...  just been sitting there quietly
> minding it's own business.
>
> The issue right now is, that I somehow have to distribute the lat,lon
> origin in some OpenFlight centric workflow. I could totally do this
> differently by transforming the information into my own format.
>
>
> Looking at the implementation now the two parameters that need to be
> serialized at the latitude and longitude paramters.  If these used the
> setName()/getName() convention then it'd be easy to add serializers using
> the standard ADD_DOUBLE_SERIALIZER( Name, 0.0); serializers (for instance
> see the usage in src/osgWrappers/serializers/osg/ ).
>
> As these don't follow the setName/getName() one will either have to write
> a custom serializer for it or simply change the naming across to the
> setName()/getName() convention that the almost all of the OSG uses.  I'd be
> inclined to do the later.  Then just add the GeographicLocation serializers
> to the src/osgWrappes/serializers/osgSim.  This would mean that the change
> could only be add to OSG master and no backported to OSG-3.4 or OSG-3.2 as
> the ABI would change, but personally I'd be happy with this.
>
> I'll try to do this then and present the submission when I find the time.
>


The other route which would with recent OSG versions would be to copy the
GeographicLocation data to the a Node's UserValue i.e.

  node->setValue("latitude", geographicLocation->latitude());
  node->setValue("longitude", geographicLocation->longitude));

The values then would be serialized automatically.

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

Re: [osg-users] osgSim::GeographicLocation

[Sebastian Messerschmidt]

Am 20.04.2016 um 10:05 schrieb Robert Osfield:

Hi Sebastian,

On 20 April 2016 at 08:17, Sebastian Messerschmidt 
> wrote:


Openflight databases seem to use this user-data at the root node
to describe the geographic base coordinates of UTM-databases.
Unfortunately this class doesn't seem to have a serializer for the
osgXYZ file formats. What is the best way to add such
serialization capabilities?


Been a very very long time since I heard mention of the 
osgSim::GeoographicLocation class...  just been sitting there quietly 
minding it's own business.
The issue right now is, that I somehow have to distribute the lat,lon 
origin in some OpenFlight centric workflow. I could totally do this 
differently by transforming the information into my own format.


Looking at the implementation now the two parameters that need to be 
serialized at the latitude and longitude paramters.  If these used the 
setName()/getName() convention then it'd be easy to add serializers 
using the standard ADD_DOUBLE_SERIALIZER( Name, 0.0); serializers (for 
instance see the usage in src/osgWrappers/serializers/osg/ ).


As these don't follow the setName/getName() one will either have to 
write a custom serializer for it or simply change the naming across to 
the setName()/getName() convention that the almost all of the OSG 
uses.  I'd be inclined to do the later.  Then just add the 
GeographicLocation serializers to the 
src/osgWrappes/serializers/osgSim.  This would mean that the change 
could only be add to OSG master and no backported to OSG-3.4 or 
OSG-3.2 as the ABI would change, but personally I'd be happy with this.

I'll try to do this then and present the submission when I find the time.

Cheers
Sebastian


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] osgSim::GeographicLocation

[Robert Osfield]

Hi Sebastian,

On 20 April 2016 at 08:17, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

> Openflight databases seem to use this user-data at the root node to
> describe the geographic base coordinates of UTM-databases.
> Unfortunately this class doesn't seem to have a serializer for the osgXYZ
> file formats. What is the best way to add such serialization capabilities?
>

Been a very very long time since I heard mention of the
osgSim::GeoographicLocation class...  just been sitting there quietly
minding it's own business.

Looking at the implementation now the two parameters that need to be
serialized at the latitude and longitude paramters.  If these used the
setName()/getName() convention then it'd be easy to add serializers using
the standard ADD_DOUBLE_SERIALIZER( Name, 0.0); serializers (for instance
see the usage in src/osgWrappers/serializers/osg/ ).

As these don't follow the setName/getName() one will either have to write a
custom serializer for it or simply change the naming across to the
setName()/getName() convention that the almost all of the OSG uses.  I'd be
inclined to do the later.  Then just add the GeographicLocation serializers
to the src/osgWrappes/serializers/osgSim.  This would mean that the change
could only be add to OSG master and no backported to OSG-3.4 or OSG-3.2 as
the ABI would change, but personally I'd be happy with this.

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

[osg-users] osgEarth Feature multiple draw

[Michele Onnis]

Hi,

I'm using the osgEarth library and I'm trying to draw Time Space Position 
Information datasets with a playback functionality. I want to draw the whole 
trajectory and then draw a subrange of the SAME trajectory, with a different 
style, for playback purposes: the playback subrange is "translated" over time 
to achieve the animation playback.

In the first approach, I used two different node graphs based on 
osgEarth::Feature classes (Feature / Session / FeatureSource / 
FeatureModelGraph). I wanted to share the feature and specify two different 
draws of same feature (total range and partial range), but I could not find a 
way to do this. So, at every frame I add geometry to the playback feature and 
this action drops the framerate.

To solve the problem, I've tried to switch to a "lower level" implementation 
based on osg::Geometry. In this case, I share the vertex array between the 
whole trajectory and the playback trajectory, then I specified two DrawArrays 
with different ranges for the different renders. The performance of this 
solution is perfect, but the geometry shows jitter problems related to the 
single precision of the GPU (geometry is specified in world coordinates).

I know that in the second scenario I have to "localize" the geometry in a local 
origin to minimize the jitter, but I ask if there is a way to achieve the same 
results with the "higher level" approach (osgEarth::Feature classes), because 
I'd rather take advantage of all optimizations in this classes. So, how can I 
specify a single Feature and then specify multiple renders of the same Feature, 
with different ranges of the data and different styles?

Thank you!

Cheers,
Michele

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





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

[osg-users] osgSim::GeographicLocation

[Sebastian Messerschmidt]

Hi,

Openflight databases seem to use this user-data at the root node to 
describe the geographic base coordinates of UTM-databases.
Unfortunately this class doesn't seem to have a serializer for the 
osgXYZ file formats. What is the best way to add such serialization 
capabilities?


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