Re: [osg-users] How to properly compile osg with EGL support?

[Chris Hanson]

Awesome!

On Tue, Apr 30, 2019 at 8:14 AM Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> me again :)
>
> I had to re-read what Omar wrote in this thread. To make it work you
> really need to link explicitly to EGL, GLdispatch and OpenGL. All works now
>
> Thanks Omar and Chris!
>
> On Tue, Apr 30, 2019 at 7:38 AM Trajce Nikolov NICK <
> trajce.nikolov.n...@gmail.com> wrote:
>
>> Hi Community,
>>
>> we are back on this issue now days. I have tried the osgEGL project from
>> guthub and I am having the same problem I had before. Crash .. Here is the
>> stack trace. Any clue?
>>
>> 0glGetString0x762ccae9
>> 1osg::State::initializeExtensionProcs()0x76d1e3ed
>> 2osg::GraphicsContext::makeCurrent()0x76c2a4f2
>> 3osg::GraphicsThread::run()0x76c30117
>> 4OpenThreads::ThreadPrivateActions::StartThread(void *)
>> 0x76873375
>> 5start_thread
>> /usr/lib/debug/.build-id/b1/7c21299099640a6d863e423d99265824e7bb16.debug
>> 3330x748d46ba
>> 6clone/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so109
>> 0x7599741d
>>
>>
>>
>>
>> On Fri, Jan 25, 2019 at 9:47 AM Omar Álvarez 
>> wrote:
>>
>>> I have created a small repo with my changes based on your code. I will
>>> try to update the readme today, but compiling it is pretty straightforward.
>>>
>>> https://github.com/omaralvarez/osgEGL
>>>
>>> I still need to clean up the code and see what is going on with the
>>> warnings, but it looks like it is working properly with the OSG master
>>> branch.
>>>
>>> El jue., 24 ene. 2019 a las 23:49, Trajce Nikolov NICK (<
>>> trajce.nikolov.n...@gmail.com>) escribió:
>>>
 Hi,

 here is how far we have got (not too far but I think it is in the right
 direction). Let see if you have some

 On Thu, Jan 24, 2019 at 12:06 AM Omar Álvarez 
 wrote:

> Hi,
>
> Sounds good. Tomorrow morning I will compile it. I will probably also
> make some changes in how GL is used in CMake since to make EGL work you
> need to link to GLVND GL. Thanks for the tips to get OSG to compile.
>
> If you have some code already I will gladly take a look and see if I
> can make it work. I’ll be happy to share my findings with everybody. If
> everything goes ok we should have a working example and maybe a tutorial.
> Do you have a github repo?
>
> Regards,
>
> Omar.
> ___
> 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 mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>
>>
>> --
>> trajce nikolov nick
>>
>
>
> --
> trajce nikolov nick
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
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

Re: [osg-users] Convert .earth file to .osg format

[Chris Hanson]

>
>
> Band 1 Block=1024x1 Type=Float32, ColorInterp=Gray
>  don't see the measurement value type, but I'm fairly sure they are both
> in meters. (I also confirmed the above data in QGIS.)
>

This seems plausible. Did you check to see what value range this elevation
TIFF has?

I can't see anything obviously wrong.

-- 
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

Re: [osg-users] Best Practices and Switches

[David Heitbrink]

Thank you for your reply.

In general my CPU load is pretty good, what I am really concerned about is 
reducing the number of OpenGL calls/driver overhead. If I have 200 signs all 
under there own switch, each sign is only 4-64 triangles each, and all the 
signs share the same texture mosaic.  Having 200 unique drawls can get 
expensive, especially for such a low poly objects. Ideally the 200 street signs 
would get combined in the same draw object. My assumption was this cannot 
happen with each sign being under its own switch.

My second question is 2 part, if I remove the switches, would I want to then 
export the result to a file and reload the file run, then run the optimizer. Or 
would the performance of the optimizer be all the same if I ran it on a graph 
that I had just programmatically removed the switches from. I am basically 
concerned with running into "nodeWeCannotRemove".  

Also, the second part is..what criteria does the MERGE_GEOMETRY option use 
to merge geometry. 

For example lets say I wanted to go a step further, and remove the textures 
from the state sets, and add an attribute for a texture index for each vertex. 
Then I could say use a texture array or bindless texture in the shader to 
reference the texture to use. We should be able to start combining nodes with 
dissimilar textures.

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





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

Re: [osg-users] Best Practices and Switches

[Robert Osfield]

Hi David,

On Tue, 30 Apr 2019 at 17:38, David Heitbrink  wrote:
> I have some scenes with tons of osgSim::MultiSwitch's, I think for some of my 
> scenes it can be in the low 1000s. For a scene these are typically setup 
> once, and then rarely changed. From what I understand a lot of the optimize 
> operations do not work across switches, which makes sense, I would think it 
> would be hard to merge geometry with something that can change.
>
> Since these switches rarely change, I was thinking about loading my switch 
> options from a file, then just removing the switches, and attaching the 
> selected child of the multi-switch to its parent. In general is this a solid 
> approach, or is just setting "DataVariance" to static for the switch good 
> enough?
>
> Typically the object size under these switches are pretty small. Often times 
> they are just 4 triangles.

Having 1000's of Switch nodes can create a CPU load that ideally is
only somethng you'd want to pay for if you are actively using them as
Switches.  If the Switches just get to one state and for the rest of
the applications life remain the same then just replacing them with
the subgraph that is enabled should provide a performance gain.

Another alternative would be to use the osg::Node::setNodeMask(uint
mask) instead of a Switch.  It doesn't have exactly the same
functionality as the switch but can be close enough for many tasks and
as all nodes have a NodeMask and they are always checked during
traversal you don't pay any extra cost in using the NodeMask as a
switch.

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

[osg-users] Best Practices and Switches

[David Heitbrink]

I have some scenes with tons of osgSim::MultiSwitch's, I think for some of my 
scenes it can be in the low 1000s. For a scene these are typically setup once, 
and then rarely changed. From what I understand a lot of the optimize 
operations do not work across switches, which makes sense, I would think it 
would be hard to merge geometry with something that can change.

Since these switches rarely change, I was thinking about loading my switch 
options from a file, then just removing the switches, and attaching the 
selected child of the multi-switch to its parent. In general is this a solid 
approach, or is just setting "DataVariance" to static for the switch good 
enough?

Typically the object size under these switches are pretty small. Often times 
they are just 4 triangles.

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





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

Re: [osg-users] Convert .earth file to .osg format

[Steven Jones]

Chris,

When I examine an image GeoTiff with GDALinfo, here's what is output:

Driver: GTiff/GeoTIFF
Files: N33W118_D004_S001_T001_L00_U0_R0a.tif
Size is 1024, 1024
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-118.000,34.000)
Pixel Size = (0.00097656250,-0.00097656250)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_SOFTWARE=GeoJasPer 
Image Structure Metadata:
  COMPRESSION=JPEG
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-118.000,  34.000) (118d 0' 0.00"W, 34d 0' 0.00"N)
Lower Left  (-118.000,  33.000) (118d 0' 0.00"W, 33d 0' 0.00"N)
Upper Right (-117.000,  34.000) (117d 0' 0.00"W, 34d 0' 0.00"N)
Lower Right (-117.000,  33.000) (117d 0' 0.00"W, 33d 0' 0.00"N)
Center  (-117.500,  33.500) (117d30' 0.00"W, 33d30' 0.00"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue

This is one of the GeoTiff elevation files:

Driver: GTiff/GeoTIFF
Files: N33W118_D001_S001_T001_L00_U0_R0.tif
Size is 1024, 1024
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-118.00048828125,33.99951171875)
Pixel Size = (0.00097656250,-0.00097656250)
Metadata:
  AREA_OR_POINT=Point
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-118.0004883,  33.9995117) (118d 0' 1.76"W, 33d59'58.24"N)
Lower Left  (-118.0004883,  32.9995117) (118d 0' 1.76"W, 32d59'58.24"N)
Upper Right (-117.0004883,  33.9995117) (117d 0' 1.76"W, 33d59'58.24"N)
Lower Right (-117.0004883,  32.9995117) (117d 0' 1.76"W, 32d59'58.24"N)
Center  (-117.5004883,  33.4995117) (117d30' 1.76"W, 33d29'58.24"N)
Band 1 Block=1024x1 Type=Float32, ColorInterp=Gray

I don't see the measurement value type, but I'm fairly sure they are both in 
meters. (I also confirmed the above data in QGIS.)

I'll also look into gdalbuildvrt - Thanks!

Steven

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





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

Re: [osg-users] Convert .earth file to .osg format

[Glenn Waldron]

Steven,
You should consider making a GDAL VRT. It's a format for compositing source
files together into one virtual data source. You can build it by hand or
use the gdalbuildvrt tool.

https://www.gdal.org/gdalbuildvrt.html

Glenn Waldron / osgEarth


On Mon, Apr 29, 2019 at 7:02 PM Chris Hanson  wrote:

> On Mon, Apr 29, 2019 at 9:09 PM Steven Jones  wrote:
>
>> I receive no error messages, and the build completes, but when I use
>> osgviewer to inspect the .ive file, it is completely flat - no visible
>> change in elevation - terrain resolution is perfect though.
>
>
>   Is the imagery in place and proper resolution?
>
>
>> Below is the command line that I've used to build the database - I've
>> changed the LOD level to various settings, even up to 8, and tried other
>> settings based on osgdem's -h info (such as --PagedLOD), but no joy.
>> osgdem --geocentric -t C:\DB\N33\W118\004_Imagery -d
>> C:\DB\N33\W118\001_Elevation -l 8 -o db.ive
>>
>
>   What elevation units is your elevation data in?
>
>   Can you verify that OSG or osgDEM is able to read it ok otherwise? Do
> you have any other known-good sample data to throw at it to see if your
> elevation file values just aren't being understood correctly?
>
>
>> Also, if I create the database as .osg instead of .ive, osgviewer throws
>> the following error:  "Problem, no locator found in any of the terrain
>> layers."
>>
>
>   Is your OSG even built with the deprecated .osg format plugin?
>
>   You can save as the more modern .osgb (binary) and .osgt (text) formats
> instead of .osg and .ive. They are preferred now, though I haven't tried
> them with VPB/osgdem myself.
>
>   If you can get it into .osg or .osgt format -- or use osgconv to convert
> the successful .ive file(s) to .osg/.osgt you might be able to examine the
> data values in the created rasters and see if there are all zeros or just
> some VERY small values.
>
>
>> Maybe I'm missing something obvious, but for the life of me I can't get
>> past this point... ;-(   (It is very important that the database render the
>> elevation in a 3D format.)
>> One other item of interest is that neither --interpolate-imagery nor
>> --interpolate-terrain work in osgDem... They both throw errors that they
>> are unrecognized commands. The version of VPB/osgDem I'm running is 0.9.11
>> (I was trying different options to generate the database when I encountered
>> this.)
>>
>
>   Huh. I can't recall if I ever used them. You'd have to look into the
> source to see if they're even there or if they're able to be made to work.
>
> --
> 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] How to properly compile osg with EGL support?

[Trajce Nikolov NICK]

me again :)

I had to re-read what Omar wrote in this thread. To make it work you really
need to link explicitly to EGL, GLdispatch and OpenGL. All works now

Thanks Omar and Chris!

On Tue, Apr 30, 2019 at 7:38 AM Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> Hi Community,
>
> we are back on this issue now days. I have tried the osgEGL project from
> guthub and I am having the same problem I had before. Crash .. Here is the
> stack trace. Any clue?
>
> 0glGetString0x762ccae9
> 1osg::State::initializeExtensionProcs()0x76d1e3ed
> 2osg::GraphicsContext::makeCurrent()0x76c2a4f2
> 3osg::GraphicsThread::run()0x76c30117
> 4OpenThreads::ThreadPrivateActions::StartThread(void *)
> 0x76873375
> 5start_thread
> /usr/lib/debug/.build-id/b1/7c21299099640a6d863e423d99265824e7bb16.debug
> 3330x748d46ba
> 6clone/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so109
> 0x7599741d
>
>
>
>
> On Fri, Jan 25, 2019 at 9:47 AM Omar Álvarez 
> wrote:
>
>> I have created a small repo with my changes based on your code. I will
>> try to update the readme today, but compiling it is pretty straightforward.
>>
>> https://github.com/omaralvarez/osgEGL
>>
>> I still need to clean up the code and see what is going on with the
>> warnings, but it looks like it is working properly with the OSG master
>> branch.
>>
>> El jue., 24 ene. 2019 a las 23:49, Trajce Nikolov NICK (<
>> trajce.nikolov.n...@gmail.com>) escribió:
>>
>>> Hi,
>>>
>>> here is how far we have got (not too far but I think it is in the right
>>> direction). Let see if you have some
>>>
>>> On Thu, Jan 24, 2019 at 12:06 AM Omar Álvarez 
>>> wrote:
>>>
 Hi,

 Sounds good. Tomorrow morning I will compile it. I will probably also
 make some changes in how GL is used in CMake since to make EGL work you
 need to link to GLVND GL. Thanks for the tips to get OSG to compile.

 If you have some code already I will gladly take a look and see if I
 can make it work. I’ll be happy to share my findings with everybody. If
 everything goes ok we should have a working example and maybe a tutorial.
 Do you have a github repo?

 Regards,

 Omar.
 ___
 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 mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> --
> trajce nikolov nick
>


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