OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Texture2DArray Internal Texture Format (OSG3.4.0)


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
Tare
Newbie


Joined: 04 Apr 2018
Posts: 7

PostPosted: Wed Apr 04, 2018 10:35 am    Post subject:
Texture2DArray Internal Texture Format (OSG3.4.0)
Reply with quote

Hi,

since I couldn't get 3.6.0 rc2 to run, I have been working with 3.4.0, so I'm not sure if this is happening in the current version.

I have been trying out Texture2DArrays and have loaded in 16 images, set them to a Texture2Array object and tried to display it. When calling frame the first time, I got some warnings:
"Warning: Texture2DArray::applyTexImage2DArray_subload(..) given image do have wrong dimension or internal format."
None of the loaded images is displayed as a texture.
I have debugged into the OSG Code to look for the error, and it turns out, that upon loading (a bmp file for every texture, all have the same width and height), the internal texture format of the images is set to 3 (which is GL_RGB at some point of the code), but the Texture2DArray internal format is 6407, which is also GL_RGB.

I went on to set the image internal texture format to GL_RGB (which in this case is 6407) and now it works.

I'd add a minimal working example, but the forum seems to not let me do that, so sorry about that.

EDIT:
Now that I have been approved, I am able to add the code:

Code:

#include <Windows.h>
#include <osg/Node>
#include <osg/Texture2DArray>
#include <osgDB/Readfile>
#include <osgViewer/Viewer>

int main()
{
   osg::ref_ptr<osg::Texture2DArray> texArray = new osg::Texture2DArray;
   std::string path = "YOUR_TEXTURE_PATH_HERE";
   for (int i = 0; i < 16; i++)
   {
      osg::ref_ptr<osg::Image> img = osgDB::readImageFile(path + "YOUR_IMAGES_HERE" + std::to_string(i) + "YOUR_IMAGE_EXTENSION_HERE");
      //Comment out the following line, then it should work.
      //img->setInternalTextureFormat(GL_RGB);
      texArray->setImage(i, img);
   }
   
   osg::ref_ptr<osg::Node> quad = osgDB::readNodeFile("quad.obj");
   osg::ref_ptr<osg::StateSet> ssQuad = quad->getOrCreateStateSet();
   ssQuad->setTextureAttributeAndModes(0, texArray);

   osg::ref_ptr<osg::Shader> vert = osgDB::readShaderFile("TexArray.vert");
   osg::ref_ptr<osg::Shader> frag = osgDB::readShaderFile("TexArray.frag");
   osg::ref_ptr<osg::Program> prog = new osg::Program;
   prog->addShader(vert);
   prog->addShader(frag);
   ssQuad->setAttributeAndModes(prog, osg::StateAttribute::ON);

   osgViewer::Viewer viewer;
   viewer.setSceneData(quad);
   viewer.getCamera()->getGraphicsContext()->getState()->setUseModelViewAndProjectionUniforms(true);
   viewer.getCamera()->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(true);

   return viewer.run();
}


Here my TexArray.vert:

Code:

#version 400

layout(location = 0)in vec4 osg_Vertex;
layout(location = 3)in vec2 osg_MultiTexCoord0;

out vec2 vTexCoords;

uniform mat4 osg_ModelViewProjectionMatrix;
void main(void)
{
   gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex;
   vTexCoords = osg_MultiTexCoord0.xy;
}


Here my TexArray.frag:

Code:

#version 400

uniform sampler2DArray texArray;

in vec3 vWorldPos;
in vec2 vTexCoords;

out vec4 finalColor;

void main(void)
{
   finalColor = vec4(texture(texArray, vec3(vTexCoords, 0)).xyz, 1.0);
}


Last edited by Tare on Thu Apr 19, 2018 11:31 am; edited 1 time in total
Back to top
View user's profile Send private message
Tare
Newbie


Joined: 04 Apr 2018
Posts: 7

PostPosted: Thu Apr 19, 2018 10:14 am    Post subject:
Texture2DArray Internal Texture Format (OSG3.4.0)
Reply with quote

Hi,

since I couldn't get 3.6.0 rc2 to run, I have been working with 3.4.0, so I'm not sure if this is happening in the current version.

I have been trying out Texture2DArrays and have loaded in 16 images, set them to a Texture2Array object and tried to display it. When calling frame the first time, I got some warnings:
"Warning: Texture2DArray::applyTexImage2DArray_subload(..) given image do have wrong dimension or internal format."
None of the loaded images is displayed as a texture.
I have debugged into the OSG Code to look for the error, and it turns out, that upon loading (a bmp file for every texture, all have the same width and height), the internal texture format of the images is set to 3 (which is GL_RGB at some point of the code), but the Texture2DArray internal format is 6407, which is also GL_RGB.

I went on to set the image internal texture format to GL_RGB (which in this case is 6407) and now it works.

I'd add a minimal working example, but the forum seems to not let me do that, so sorry about that.

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







------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11758

PostPosted: Thu Apr 19, 2018 1:32 pm    Post subject:
Texture2DArray Internal Texture Format (OSG3.4.0)
Reply with quote

Hi Tim,

It looks like some modern OpenGL drivers don't like the number of
components of texture being used as the internal texture format so
plugins that use this approach end up causing a problem. In 3.6.0 we
did fix a few places where this was happen, off the top of my head I
don't recall if the bmp plugin was amongst those fixed. W.r.t not
being able to attach files to the forum posts, this will be the case
for new posters, it's a mechanism required to prevent spammers from
abusing the forum.

More pressing an issue is what cause problems when you tried 3.6.0
rc2? I fixed all the issues that were reported for the final 3.6.0,
there is chance that the issue you say has been fixed, but as you
don't provide any inform there is no way for me to know. Could you
please explain the issue you saw.

Robert.

On 4 April 2018 at 11:35, Tim Whowantstoknow <> wrote:
Quote:
Hi,

since I couldn't get 3.6.0 rc2 to run, I have been working with 3.4.0, so I'm not sure if this is happening in the current version.

I have been trying out Texture2DArrays and have loaded in 16 images, set them to a Texture2Array object and tried to display it. When calling frame the first time, I got some warnings:
"Warning: Texture2DArray::applyTexImage2DArray_subload(..) given image do have wrong dimension or internal format."
None of the loaded images is displayed as a texture.
I have debugged into the OSG Code to look for the error, and it turns out, that upon loading (a bmp file for every texture, all have the same width and height), the internal texture format of the images is set to 3 (which is GL_RGB at some point of the code), but the Texture2DArray internal format is 6407, which is also GL_RGB.

I went on to set the image internal texture format to GL_RGB (which in this case is 6407) and now it works.

I'd add a minimal working example, but the forum seems to not let me do that, so sorry about that.

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








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Tare
Newbie


Joined: 04 Apr 2018
Posts: 7

PostPosted: Tue Apr 24, 2018 1:35 pm    Post subject:
Reply with quote

Hi Robert,

Quote:
More pressing an issue is what cause problems when you tried 3.6.0
rc2?


when I was using cmake on the rc, I didn't get library files for several components (e.g. osgViewer). Thus, the "generating" worked without errors, but I couldn't use the outcome since half of osg wasn't there to use. I will download the newest version and try again soon. In any case, a collegue of mine got the new version running, so either it is fixed or it was a local problem.

Kind Regards,
Tim
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11758

PostPosted: Tue Apr 24, 2018 2:15 pm    Post subject:
Texture2DArray Internal Texture Format (OSG3.4.0)
Reply with quote

HI Tim.

On 24 April 2018 at 14:35, Tim Whowantstoknow <> wrote:
Quote:
when I was using cmake on the rc, I didn't get library files for several components (e.g. osgViewer). Thus, the "generating" worked without errors, but I couldn't use the outcome since half of osg wasn't there to use. I will download the newest version and try again soon. In any case, a collegue of mine got the new version running, so either it is fixed or it was a local problem.

Sounds like a build failure somewhere along the line. What platform
and build tools are you using?

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Tare
Newbie


Joined: 04 Apr 2018
Posts: 7

PostPosted: Wed Apr 25, 2018 9:32 am    Post subject:
Reply with quote

I am working on Windows 10 and used CMaker 3.10.1 to build everything. The Compiler was Visual studio 2017 (Visual Studio 15 2017 Win64).

I have attached my CMake Cache, if you're looking for some particular setting.
Back to top
View user's profile Send private message
Tare
Newbie


Joined: 04 Apr 2018
Posts: 7

PostPosted: Thu Apr 26, 2018 7:28 am    Post subject:
Reply with quote

I am trying to build the current code of OSG again (CMake 3.10.1, Visual Studio 15 2017 Win64, Win 10.0.15064). First thing, I get a deprecated warning:

Code:
CMake Deprecation Warning at CMakeLists.txt:40 (cmake_policy):
  The OLD behavior for policy CMP0008 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


Just a side node, CMake didn't find the gdal_i.lib on its own. Otherwise there were no further warnings.

I could not find the Qt settings right now. Has Qt support been dropped?

CMake genertation and solution build both succeeded without a problem and on first glance, all the libraries have been build. So either I had some incorrect setups with rc2 or there was a general issue that has been fixed along the road.
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11758

PostPosted: Thu Apr 26, 2018 8:15 am    Post subject:
Texture2DArray Internal Texture Format (OSG3.4.0)
Reply with quote

Hi Tim Whowantstoknow (Could you please change you "surname", we don't
have a problem with remaining anonymous but use of deliberately
obnoxious names is not cool, it's we are community of people not
cartoon characters),

On 26 April 2018 at 08:28, Tim Whowantstoknow <> wrote:
Quote:
CMake Deprecation Warning at CMakeLists.txt:40 (cmake_policy):
The OLD behavior for policy CMP0008 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.

Longer term this will need to be removed, but for now this should be benign.

Elements like this may not be need now at all so we might be able to
remove them. You could try removing it,

Quote:
Just a side node, CMake didn't find the gdal_i.lib on its own. Otherwise there were no further warnings.

The OpenSceneGraph/FindGDAL.cmake searches a range of standard
locations for the files but if it's not in these then it won't be able
to find it. How have you installed GDAL? Did you set the GDAL_DIR?

Quote:
I could not find the Qt settings right now. Has Qt support been dropped?

It's in the NEWS for the release, osgQt has been moved out into its
own dedicated project.

https://github.com/openscenegraph/osgQt

Quote:
CMake genertation and solution build both succeeded without a problem and on first glance, all the libraries have been build. So either I had some incorrect setups with rc2 or there was a general issue that has been fixed along the road.

I don't recall any relevant build changes in the rc's or since 3.6.0
was released. It's very hard to debug platform problems remotely, so
it might your colleagues who've had a successful build who might be
able to spot what specifically went. If there is an OSG CMake error
somewhere then we can roll a fix into the OSG.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts DXT texture compression urbanchaos General [forum] 9 Tue May 08, 2018 12:13 pm View latest post
No new posts How do I create a graphics context on... srinivas General 3 Tue Apr 24, 2018 11:40 am View latest post
No new posts 'fatal error C1128: number of section... Jason Beverage General 2 Wed Apr 18, 2018 7:59 pm View latest post
No new posts EXTERNAL: Re: EXTERNAL: Re: Writing t... Rowley, Marlin R General 0 Wed Apr 18, 2018 2:31 pm View latest post
No new posts EXTERNAL: Re: Writing texture coordin... robertosfield General 1 Sat Apr 14, 2018 5:48 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP