Re: [osg-users] hardware instancing with VertexAttribs and VertexAttribsDivisor
Hi Community,
me again on this. I have it working, however, it looks really bad when
using large coordinates (when placed on UTM or Geocentric). The model is
somewhat distorted due to precission issues. I know how to avoid this, like
working with double matrices, but when I pass double matrix on the vertex
shader it kills the performance - from 60Fps to ~1 fps. Bellow is the
vertex shader. Any hints?
Thanks a bunch as always
#version 150 compatibility
uniform mat4 osg_ModelViewProjectionMatrix;
uniform mat3 osg_NormalMatrix;
uniform vec3 lightDirection;
in vec3 vPosition;
in vec3 vNormal;
in vec2 vTexCoord;
in mat4 vInstanceModelMatrix;
smooth out vec2 texCoord;
smooth out vec3 normal;
smooth out vec3 lightDir;
void main()
{
gl_Position = /*osg_ModelViewProjectionMatrix*/
gl_ModelViewProjectionMatrix * vInstanceModelMatrix * vec4(vPosition, 1.0);
texCoord = vTexCoord;
mat3 instanceNormalMatrix = mat3(vInstanceModelMatrix[0][0],
vInstanceModelMatrix[0][1], vInstanceModelMatrix[0][2],
vInstanceModelMatrix[1][0], vInstanceModelMatrix[1][1],
vInstanceModelMatrix[1][2],
vInstanceModelMatrix[2][0], vInstanceModelMatrix[2][1],
vInstanceModelMatrix[2][2]);
normal = osg_NormalMatrix * instanceNormalMatrix * vNormal;
lightDir = lightDirection;
}
On Tue, Nov 25, 2014 at 12:06 PM, Robert Osfield
wrote:
> Hi All,
>
> On 24 November 2014 at 09:28, Sebastian Messerschmidt <
> sebastian.messerschm...@gmx.de> wrote:
>
>> The example I was looking for was in the submissions, called:
>>
>> [osg-submissions] New example : culling and LODing performed on GPU side
>>
>> Unfortunately Robert didn't approve or merge the nescessary changes.
>> Maybe it went unnoticed.
>>
>
> I am still progressing through the submissions backlog and am delighted to
> say that this wee gem of an example is now checked into svn/trunk - look
> for osggpucull. I haven't had a chance to spend the time understanding it
> yet, but the code is there.
>
> Robert.
>
>
> ___
> 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
Re: [osg-users] hardware instancing with VertexAttribs and VertexAttribsDivisor
Hi Nick,
One way to improve this is to place your "root" somewhere near the
center of your instanced geometry and subtract the center from your
instances positions.
This way the coordinates to be multiplied stay small in relation (as the
big precision loss due to View*Model is done on the CPU side (during
cull) instead of multiplying big coordinates one the GPU with the inverse.
So decorate your CustomGeometry subgraph with a transform and modify
your instances position accordingly.
Hi Community,
me again on this. I have it working, however, it looks really bad when
using large coordinates (when placed on UTM or Geocentric). The model
is somewhat distorted due to precission issues. I know how to avoid
this, like working with double matrices, but when I pass double matrix
on the vertex shader it kills the performance - from 60Fps to ~1 fps.
Bellow is the vertex shader. Any hints?
Thanks a bunch as always
#version 150 compatibility
uniform mat4 osg_ModelViewProjectionMatrix;
uniform mat3 osg_NormalMatrix;
uniform vec3 lightDirection;
in vec3 vPosition;
in vec3 vNormal;
in vec2 vTexCoord;
in mat4 vInstanceModelMatrix;
smooth out vec2 texCoord;
smooth out vec3 normal;
smooth out vec3 lightDir;
void main()
{
gl_Position = /*osg_ModelViewProjectionMatrix*/
gl_ModelViewProjectionMatrix * vInstanceModelMatrix * vec4(vPosition,
1.0);
texCoord = vTexCoord;
mat3 instanceNormalMatrix = mat3(vInstanceModelMatrix[0][0],
vInstanceModelMatrix[0][1], vInstanceModelMatrix[0][2],
vInstanceModelMatrix[1][0], vInstanceModelMatrix[1][1],
vInstanceModelMatrix[1][2],
vInstanceModelMatrix[2][0], vInstanceModelMatrix[2][1],
vInstanceModelMatrix[2][2]);
normal = osg_NormalMatrix * instanceNormalMatrix * vNormal;
lightDir = lightDirection;
}
On Tue, Nov 25, 2014 at 12:06 PM, Robert Osfield
mailto:robert.osfi...@gmail.com>> wrote:
Hi All,
On 24 November 2014 at 09:28, Sebastian Messerschmidt
mailto:sebastian.messerschm...@gmx.de>> wrote:
The example I was looking for was in the submissions, called:
[osg-submissions] New example : culling and LODing performed
on GPU side
Unfortunately Robert didn't approve or merge the nescessary
changes. Maybe it went unnoticed.
I am still progressing through the submissions backlog and am
delighted to say that this wee gem of an example is now checked
into svn/trunk - look for osggpucull. I haven't had a chance to
spend the time understanding it yet, but the code is there.
Robert.
___
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
Re: [osg-users] hardware instancing with VertexAttribs and VertexAttribsDivisor
Thanks Sebastian.I could of thought of this. Let me give it a shot. Thanks
again!
Nick
On Mon, Dec 1, 2014 at 9:26 AM, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:
> Hi Nick,
>
> One way to improve this is to place your "root" somewhere near the center
> of your instanced geometry and subtract the center from your instances
> positions.
> This way the coordinates to be multiplied stay small in relation (as the
> big precision loss due to View*Model is done on the CPU side (during cull)
> instead of multiplying big coordinates one the GPU with the inverse.
> So decorate your CustomGeometry subgraph with a transform and modify your
> instances position accordingly.
>
> Hi Community,
>
> me again on this. I have it working, however, it looks really bad when
> using large coordinates (when placed on UTM or Geocentric). The model is
> somewhat distorted due to precission issues. I know how to avoid this, like
> working with double matrices, but when I pass double matrix on the vertex
> shader it kills the performance - from 60Fps to ~1 fps. Bellow is the
> vertex shader. Any hints?
>
> Thanks a bunch as always
>
> #version 150 compatibility
>
> uniform mat4 osg_ModelViewProjectionMatrix;
> uniform mat3 osg_NormalMatrix;
> uniform vec3 lightDirection;
>
> in vec3 vPosition;
> in vec3 vNormal;
> in vec2 vTexCoord;
> in mat4 vInstanceModelMatrix;
>
> smooth out vec2 texCoord;
> smooth out vec3 normal;
> smooth out vec3 lightDir;
>
> void main()
> {
> gl_Position = /*osg_ModelViewProjectionMatrix*/
> gl_ModelViewProjectionMatrix * vInstanceModelMatrix * vec4(vPosition, 1.0);
> texCoord = vTexCoord;
>
> mat3 instanceNormalMatrix = mat3(vInstanceModelMatrix[0][0],
> vInstanceModelMatrix[0][1], vInstanceModelMatrix[0][2],
> vInstanceModelMatrix[1][0], vInstanceModelMatrix[1][1],
> vInstanceModelMatrix[1][2],
> vInstanceModelMatrix[2][0], vInstanceModelMatrix[2][1],
> vInstanceModelMatrix[2][2]);
>
> normal = osg_NormalMatrix * instanceNormalMatrix * vNormal;
> lightDir = lightDirection;
> }
>
> On Tue, Nov 25, 2014 at 12:06 PM, Robert Osfield > wrote:
>
>> Hi All,
>>
>> On 24 November 2014 at 09:28, Sebastian Messerschmidt <
>> sebastian.messerschm...@gmx.de> wrote:
>>
>>> The example I was looking for was in the submissions, called:
>>>
>>> [osg-submissions] New example : culling and LODing performed on GPU side
>>>
>>> Unfortunately Robert didn't approve or merge the nescessary changes.
>>> Maybe it went unnoticed.
>>>
>>
>> I am still progressing through the submissions backlog and am delighted
>> to say that this wee gem of an example is now checked into svn/trunk - look
>> for osggpucull. I haven't had a chance to spend the time understanding it
>> yet, but the code is there.
>>
>> Robert.
>>
>>
>> ___
>> 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
> listosg-users@lists.openscenegraph.orghttp://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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] hardware instancing with VertexAttribs and VertexAttribsDivisor
Yeah, work well now. Thanks !!!
Nick
On Mon, Dec 1, 2014 at 9:45 AM, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:
> Thanks Sebastian.I could of thought of this. Let me give it a shot.
> Thanks again!
>
> Nick
>
> On Mon, Dec 1, 2014 at 9:26 AM, Sebastian Messerschmidt <
> sebastian.messerschm...@gmx.de> wrote:
>
>> Hi Nick,
>>
>> One way to improve this is to place your "root" somewhere near the center
>> of your instanced geometry and subtract the center from your instances
>> positions.
>> This way the coordinates to be multiplied stay small in relation (as the
>> big precision loss due to View*Model is done on the CPU side (during cull)
>> instead of multiplying big coordinates one the GPU with the inverse.
>> So decorate your CustomGeometry subgraph with a transform and modify your
>> instances position accordingly.
>>
>> Hi Community,
>>
>> me again on this. I have it working, however, it looks really bad when
>> using large coordinates (when placed on UTM or Geocentric). The model is
>> somewhat distorted due to precission issues. I know how to avoid this, like
>> working with double matrices, but when I pass double matrix on the vertex
>> shader it kills the performance - from 60Fps to ~1 fps. Bellow is the
>> vertex shader. Any hints?
>>
>> Thanks a bunch as always
>>
>> #version 150 compatibility
>>
>> uniform mat4 osg_ModelViewProjectionMatrix;
>> uniform mat3 osg_NormalMatrix;
>> uniform vec3 lightDirection;
>>
>> in vec3 vPosition;
>> in vec3 vNormal;
>> in vec2 vTexCoord;
>> in mat4 vInstanceModelMatrix;
>>
>> smooth out vec2 texCoord;
>> smooth out vec3 normal;
>> smooth out vec3 lightDir;
>>
>> void main()
>> {
>> gl_Position = /*osg_ModelViewProjectionMatrix*/
>> gl_ModelViewProjectionMatrix * vInstanceModelMatrix * vec4(vPosition, 1.0);
>> texCoord = vTexCoord;
>>
>> mat3 instanceNormalMatrix = mat3(vInstanceModelMatrix[0][0],
>> vInstanceModelMatrix[0][1], vInstanceModelMatrix[0][2],
>> vInstanceModelMatrix[1][0], vInstanceModelMatrix[1][1],
>> vInstanceModelMatrix[1][2],
>> vInstanceModelMatrix[2][0], vInstanceModelMatrix[2][1],
>> vInstanceModelMatrix[2][2]);
>>
>> normal = osg_NormalMatrix * instanceNormalMatrix * vNormal;
>> lightDir = lightDirection;
>> }
>>
>> On Tue, Nov 25, 2014 at 12:06 PM, Robert Osfield <
>> robert.osfi...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> On 24 November 2014 at 09:28, Sebastian Messerschmidt <
>>> sebastian.messerschm...@gmx.de> wrote:
>>>
The example I was looking for was in the submissions, called:
[osg-submissions] New example : culling and LODing performed on GPU side
Unfortunately Robert didn't approve or merge the nescessary changes.
Maybe it went unnoticed.
>>>
>>> I am still progressing through the submissions backlog and am
>>> delighted to say that this wee gem of an example is now checked into
>>> svn/trunk - look for osggpucull. I haven't had a chance to spend the time
>>> understanding it yet, but the code is there.
>>>
>>> Robert.
>>>
>>>
>>> ___
>>> 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
>> listosg-users@lists.openscenegraph.orghttp://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
Re: [osg-users] Qt5 integration first try
Hi All, I'm a little confused. There are several topics related to Qt5 porting. Is there an official branch of the OSG code for the Qt5 porting? I'm interessed in this work since we have a couple of Qt applications with OSG and I could test and or contribute if necessary. We didn't move to Qt5 yet for the OSG compatibility. Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61928#61928 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Half Side-by-side
Hello, I'm trying to display a simple OpenSceneGraph application on a 3d active tv that supports SBS Half (Half Side-by-Side) in FullHD resolution. I've already tried using stereo configuration for Side-by-side (HORIZONTAL_SPLIT) but the result is a stretched image. It seems that HORIZIONTAL_SPLIT was introduced to support output for CardBoard-like devices. Does exist a simple configuration to obtain the type of output I'm looking for? Or it is required to set it manually configuring the osg camera? Thanks in advance, Francesco Argese ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Half Side-by-side
Hi Francesco, On 1 December 2014 at 11:40, Francesco Argese wrote: > I'm trying to display a simple OpenSceneGraph application on a 3d > active tv that supports SBS Half (Half Side-by-Side) in FullHD > resolution. > Do you have any specs on this particular configuration of stereo? > > I've already tried using stereo configuration for Side-by-side > (HORIZONTAL_SPLIT) but the result is a stretched image. It seems that > HORIZIONTAL_SPLIT was introduced to support output for CardBoard-like > devices. > HORIZONTAL_SPLIT pre-dates CardBoard-like devices by a decade :-) HORIZONTAL_SPLIT is typically used when one has two displays outputs each attached to a separate projector. Does exist a simple configuration to obtain the type of output I'm > looking for? Or it is required to set it manually configuring the osg > camera? > I'm not familiar with SBS so can't comment on the specifics. Things you could try are try setting the env var OSG_SPLIT_STEREO_AUTO_ADJUST_ASPECT_RATIO to OFF, but you'll need to set the Fov of the main camera yourself. Or simply set up Stereo yourself use a slave Camera configuration. In the svn/trunk version of the OSG there is now a osgViewer::ViewConfig class with various subclasses from it in include/osgViewer/config. It could be that a new Config implementation for SBS could be written. However, this might not be needed if the existing stereo combinations can be tweaked to do what you need. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt5 integration first try
HI Gianni, Have a look at the svn/trunk version of the OSG or one of the 3.3.x dev releases as there is various additions for Qt5 support. Robert. On 1 December 2014 at 11:03, Gianni Ambrosio wrote: > Hi All, > I'm a little confused. There are several topics related to Qt5 porting. Is > there an official branch of the OSG code for the Qt5 porting? > I'm interessed in this work since we have a couple of Qt applications with > OSG and I could test and or contribute if necessary. We didn't move to Qt5 > yet for the OSG compatibility. > > Cheers, > Gianni > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=61928#61928 > > > > > > ___ > 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] OpenGLContext Destructor Context Deletion
Hi,
I am using OSG 3.2.1
When the setPixelFormat() method in GraphicsWindowWin32::setWindow( HWND handle
) is called, it creates an openGL context: "Win32WindowingSystem::OpenGLContext
openGLContext;" which later is destroyed due to calling its destructor when
existing the setPixelFormat() method.
Basically, a context is created and then deleted before the normal rendering
starts in the second context:
Code:
wglChoosePixelFormat(2A013DC8,02F0E160)=1
wglSetPixelFormat(2A013DC8,1,02F0E160)=true
wglCreateContext(2A013DC8)=0001
wglGetCurrentContext()=
wglMakeCurrent(2A013DC8,0001)=true
wglGetProcAddress("wglChoosePixelFormatARB")=03A15E60
wglChoosePixelFormatARB(2A013DC8,1B833E28,,1,02F0E0F0,02F0E0E4)=true
wglSetPixelFormat(DB012495,1,02F0E244)=true
wglMakeCurrent(DB012495,)=true
wglMakeCurrent(2A013DC8,)=true
wglDeleteContext(0001)=true
wglCreateContext(DB012495)=0002
wglMakeCurrent(DB012495,0002)=true
Is this intentional? How can I prevent the creation of this temporary context?
Thank you!
Cheers,
Ronny[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61932#61932
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] texture sharing between different osg objects?
Hi, when I use osgDB::readNodeFile on several objects, and those objects all reference the same texture file on disk - is it possible to make OSG use the same texture on all loaded subgraphs? Currently it seems like I have the same texture loaded over and over, consuming precious texture memory (and also rescaling the texture to powers of 2 multiple times...) Can osgUtil::Optimizer somehow recognize identical texture file names and make the entire scene graph use the same texture handles? Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] texture sharing between different osg objects?
HI Christian, osgUtil::Optimizer has a visitor called StateVisitor that looks for duplicate state a removes it, by default it's called when you call Optimizer::optimize(..); The Optimizer will however only work on the scene graph you give it, so you have to give it the root node and is typically used at start up on the main scene graph. For scene graphs that incremental add new subgraphs there is the osgDB::SharedStateManager that you can osgDB::Registry and have it do the merge for you. Robert. On 1 December 2014 at 14:32, Christian Buchner wrote: > Hi, > > when I use osgDB::readNodeFile on several objects, and those objects all > reference the same texture file on disk - is it possible to make OSG use > the same texture on all loaded subgraphs? Currently it seems like I have > the same texture loaded over and over, consuming precious texture memory > (and also rescaling the texture to powers of 2 multiple times...) > > Can osgUtil::Optimizer somehow recognize identical texture file names and > make the entire scene graph use the same texture handles? > > Christian > > > ___ > 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] Qt5 integration first try
Hi Robert, is there any OSG stable release planned for 2015 (hopefully supporting Qt5)? Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61935#61935 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Half Side-by-side
> Hello, > > I'm trying to display a simple OpenSceneGraph application on a 3d > active tv that supports SBS Half (Half Side-by-Side) in FullHD > resolution. > > I've already tried using stereo configuration for Side-by-side > (HORIZONTAL_SPLIT) but the result is a stretched image. It seems that > HORIZIONTAL_SPLIT was introduced to support output for CardBoard-like > devices. > > Does exist a simple configuration to obtain the type of output I'm > looking for? Or it is required to set it manually configuring the osg > camera? There's a wiki page which might help, but I don't think it solves your stretching problem. http://trac.openscenegraph.org/projects/osg//wiki/Support/UserGuides/StereoSettings Depending on your GFX card you might be able to set quad-buffer and do the left/right split at the GFX card. Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Half Side-by-side
Hi Francesco, For 3D TVs, the Side-by-Side and Top-Bottom modes will take the image on each half of the output, and stretch it to fill the entire display. Robert's advice of turning OFF the OSG_SPLIT_STEREO_AUTO_ADJUST_ASPECT_RATIO option should solve your problem. You want each eye to be rendered using the full aspect ratio of the TV. The output will look squished on your monitor, but the 3D TV will display it at the proper aspect ratio. Cheers, Farshid On Mon, Dec 1, 2014 at 3:40 AM, Francesco Argese wrote: > Hello, > > I'm trying to display a simple OpenSceneGraph application on a 3d > active tv that supports SBS Half (Half Side-by-Side) in FullHD > resolution. > > I've already tried using stereo configuration for Side-by-side > (HORIZONTAL_SPLIT) but the result is a stretched image. It seems that > HORIZIONTAL_SPLIT was introduced to support output for CardBoard-like > devices. > > Does exist a simple configuration to obtain the type of output I'm > looking for? Or it is required to set it manually configuring the osg > camera? > > Thanks in advance, > Francesco Argese > ___ > 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] texture sharing between different osg objects?
Hi Christian,
Also you could try to activate caching and sharing of nodes/textures:
Here is some snippet from my code:
{
osgDB::SharedStateManager::ShareMode mode =
osgDB::SharedStateManager::SHARE_NONE;// =
osgDB::SharedStateManager::SHARE_ALL;
mode = mConfig.mGlobalState.mShareStates ?
static_cast(mode |
osgDB::SharedStateManager::SHARE_STATESETS) : mode;
mode = mConfig.mGlobalState.mShareTextures
?static_cast(mode |
osgDB::SharedStateManager::SHARE_TEXTURES) : mode;
osgDB::Registry::instance()->getOrCreateSharedStateManager()->setShareMode(mode);
}
{
//setup caching
osgDB::Options::CacheHintOptions opts;
opts = static_cast(opts
|osgDB::Options::CACHE_IMAGES);
opts = static_cast(opts
|osgDB::Options::CACHE_NODES);
opt->setObjectCacheHint(static_cast(opts));
osgDB::Registry::instance()->setOptions(opt);
}
Cheers
Sebastian
Hi,
when I use osgDB::readNodeFile on several objects, and those objects
all reference the same texture file on disk - is it possible to make
OSG use the same texture on all loaded subgraphs? Currently it seems
like I have the same texture loaded over and over, consuming precious
texture memory (and also rescaling the texture to powers of 2 multiple
times...)
Can osgUtil::Optimizer somehow recognize identical texture file names
and make the entire scene graph use the same texture handles?
Christian
___
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] texture sharing between different osg objects?
thanks Sebastian. Does this piece of code have to be placed in the
beginning of the program during the initialization phase?
I haven"t come across these classes so far... seems to be advanced stuff
that is not even covered in the OSG books...
Christian
2014-12-01 18:10 GMT+01:00 Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de>:
> Hi Christian,
>
> Also you could try to activate caching and sharing of nodes/textures:
>
> Here is some snippet from my code:
>
>
>
> {
> osgDB::SharedStateManager::ShareMode mode =
> osgDB::SharedStateManager::SHARE_NONE;// =
> osgDB::SharedStateManager::SHARE_ALL;
>
> mode = mConfig.mGlobalState.mShareStates ?
> static_cast(mode |
> osgDB::SharedStateManager::SHARE_STATESETS) : mode;
> mode = mConfig.mGlobalState.mShareTextures
> ?static_cast(mode |
> osgDB::SharedStateManager::SHARE_TEXTURES) : mode;
>
>
> osgDB::Registry::instance()->getOrCreateSharedStateManager()->setShareMode(mode);
>
> }
>
>
> {
> //setup caching
> osgDB::Options::CacheHintOptions opts;
> opts = static_cast(opts
> |osgDB::Options::CACHE_IMAGES);
> opts = static_cast(opts
> |osgDB::Options::CACHE_NODES);
>
> opt->setObjectCacheHint(static_cast(opts));
> osgDB::Registry::instance()->setOptions(opt);
> }
>
>
> Cheers
> Sebastian
>
> Hi,
>
> when I use osgDB::readNodeFile on several objects, and those objects all
> reference the same texture file on disk - is it possible to make OSG use
> the same texture on all loaded subgraphs? Currently it seems like I have
> the same texture loaded over and over, consuming precious texture memory
> (and also rescaling the texture to powers of 2 multiple times...)
>
> Can osgUtil::Optimizer somehow recognize identical texture file names
> and make the entire scene graph use the same texture handles?
>
> Christian
>
>
>
> ___
> osg-users mailing
> listosg-users@lists.openscenegraph.orghttp://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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] texture sharing between different osg objects?
Hi Christian
thanks Sebastian. Does this piece of code have to be placed in the
beginning of the program during the initialization phase?
I haven"t come across these classes so far... seems to be advanced
stuff that is not even covered in the OSG books...
You can place them anywhere, but to get an effect, you should activate
before loading.
I'm also puzzled why these options are kept below the radar, as they
enable loading of databases with huge count of references which share
the same geometry and textures.
It should also work for multiple referenced images.
As for the books: They are great for starting and will help you get an
idea where to go when you encounter a real-life problem, but they won't
show you all the tricks ;-)
Cheers
Sebastian
Christian
2014-12-01 18:10 GMT+01:00 Sebastian Messerschmidt
mailto:sebastian.messerschm...@gmx.de>>:
Hi Christian,
Also you could try to activate caching and sharing of nodes/textures:
Here is some snippet from my code:
{
osgDB::SharedStateManager::ShareMode mode =
osgDB::SharedStateManager::SHARE_NONE;// =
osgDB::SharedStateManager::SHARE_ALL;
mode = mConfig.mGlobalState.mShareStates ?
static_cast(mode |
osgDB::SharedStateManager::SHARE_STATESETS) : mode;
mode = mConfig.mGlobalState.mShareTextures
?static_cast(mode |
osgDB::SharedStateManager::SHARE_TEXTURES) : mode;
osgDB::Registry::instance()->getOrCreateSharedStateManager()->setShareMode(mode);
}
{
//setup caching
osgDB::Options::CacheHintOptions opts;
opts = static_cast(opts
|osgDB::Options::CACHE_IMAGES);
opts = static_cast(opts
|osgDB::Options::CACHE_NODES);
opt->setObjectCacheHint(static_cast(opts));
osgDB::Registry::instance()->setOptions(opt);
}
Cheers
Sebastian
Hi,
when I use osgDB::readNodeFile on several objects, and those
objects all reference the same texture file on disk - is it
possible to make OSG use the same texture on all loaded
subgraphs? Currently it seems like I have the same texture loaded
over and over, consuming precious texture memory (and also
rescaling the texture to powers of 2 multiple times...)
Can osgUtil::Optimizer somehow recognize identical texture file
names and make the entire scene graph use the same texture handles?
Christian
___
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 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
