[2.1] Hlms Normal Map question
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
[2.1] Hlms Normal Map question
Hello!... I guess I'll be posting lots of questions regarding 2.1 these days...
I encounter another problem with ogre 2.1 (or I am just stupid =D)
I have a cube I made in blender, this cube has its faces as "Smooth", then with another cube with its faces as "Flat", I baked the normals (as tangent)... So if I put this baked normal texture in my smooth cube it looks like "Flat" =)!
The problem is that in Ogre 2.1 it doesnt look like flat:
The first cube is completely smooth, the second is the smooth one with the normal map, the third one is a cube with subdivision on its edges so it looks like flat
Obviously my goal here is to make my second cube (which has 6 faces) to look like the third one (which has 54 faces)
If you notice I do get sharp edges, but the surface doesn't look flat at all
Off course in blender looks perfect!
lastly this is my normal map:
and the cube, I just made a simple cube then applied smart uv project
Any ideas? thank you very much in advance!!
I encounter another problem with ogre 2.1 (or I am just stupid =D)
I have a cube I made in blender, this cube has its faces as "Smooth", then with another cube with its faces as "Flat", I baked the normals (as tangent)... So if I put this baked normal texture in my smooth cube it looks like "Flat" =)!
The problem is that in Ogre 2.1 it doesnt look like flat:
The first cube is completely smooth, the second is the smooth one with the normal map, the third one is a cube with subdivision on its edges so it looks like flat
Obviously my goal here is to make my second cube (which has 6 faces) to look like the third one (which has 54 faces)
If you notice I do get sharp edges, but the surface doesn't look flat at all
Off course in blender looks perfect!
lastly this is my normal map:
and the cube, I just made a simple cube then applied smart uv project
Any ideas? thank you very much in advance!!
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
I don't understand what you expect.
I also don't understand if the middle cube has higher tesselation or not.
Last, but not least, what is the Hlms material you're using?
I also don't understand if the middle cube has higher tesselation or not.
Last, but not least, what is the Hlms material you're using?
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
What I am trying to do is:
I have a smooth object and I want it to look not-smooth (flat faces), like in this photo:
but! I want to do it using a normal map
smooth faces object + baked nromal map = flat faces object
In other words; I have a mesh like the sphere on the left, and using a normal map I want it to look like the one in the right
This works in blender.. If you apply the normal map I uploaded to a cube with "Shading: Smooth" in blender... it would look like if "Shading: Flat"
but its not the same in Ogre =(
Thanks!
I have a smooth object and I want it to look not-smooth (flat faces), like in this photo:
but! I want to do it using a normal map
smooth faces object + baked nromal map = flat faces object
In other words; I have a mesh like the sphere on the left, and using a normal map I want it to look like the one in the right
This works in blender.. If you apply the normal map I uploaded to a cube with "Shading: Smooth" in blender... it would look like if "Shading: Flat"
but its not the same in Ogre =(
Thanks!
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
Two things:
1. The HLMS material you're using. I want to know its definition. I think I'm seeing the reflection texture. Take it away for better comparison.
2. There's no way to achieve a flat looking cube when that's your normal map, since it makes the normals smooth! You must be doing something wrong on Blender that it isn't showing you the normal mapped version.
1. The HLMS material you're using. I want to know its definition. I think I'm seeing the reflection texture. Take it away for better comparison.
2. There's no way to achieve a flat looking cube when that's your normal map, since it makes the normals smooth! You must be doing something wrong on Blender that it isn't showing you the normal mapped version.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
1. the material is generated by code:
2. I believe it is possible, because the cube is "smooth" and the normal map its like opposite smooth so it will compensate the original normals to make them look flat. In blender works just fine.
If I disable the normal map texture from the last 2 cubes you'll see the effect
Code: Select all
Ogre::HlmsManager *hlmsManager = Ogre::Root::getSingletonPtr()->getHlmsManager();
Ogre::HlmsTextureManager *hlmsTextureManager = hlmsManager->getTextureManager();
Ogre::HlmsPbs *hlmsPbs = static_cast<Ogre::HlmsPbs*>( hlmsManager->getHlms(Ogre::HLMS_PBS) );
Ogre::String datablockName = GET_NAME(bMaterial);
Ogre::HlmsPbsDatablock *datablock = static_cast<Ogre::HlmsPbsDatablock*>(
hlmsPbs->createDatablock( datablockName,
Ogre::HlmsMacroBlock(),
Ogre::HlmsBlendblock(),
Ogre::HlmsParamVec() ) );
Ogre::HlmsTextureManager::TextureLocation texLocation = hlmsTextureManager->createOrRetrieveTexture( "SaintPetersBasilica.dds", Ogre::HlmsTextureManager::TEXTURE_TYPE_ENV_MAP );
datablock->setTexture( Ogre::PBSM_REFLECTION, texLocation.xIdx, texLocation.texture );
datablock->setDiffuse( Ogre::Vector3(0,1,0) );
datablock->setRoughness( 0.5 );
datablock->setFresnel( Ogre::Vector3(0,0,0), false );
Ogre::HlmsTextureManager::TextureLocation texLocation = hlmsTextureManager->createOrRetrieveTexture( "normalCube.png", Ogre::HlmsTextureManager::TEXTURE_TYPE_NORMALS );
datablock->setTexture( Ogre::PBSM_NORMAL, texLocation.xIdx, texLocation.texture );
If I disable the normal map texture from the last 2 cubes you'll see the effect
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
Is it too much if I ask for the blend files? (for both pictures)
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
Yes! I tried to attached before it but it was too heavy, so I just put the pics
so here is a link =)
https://www.dropbox.com/s/fpqp1kgskf6wh ... blend?dl=0
Thank you so much for the help!
so here is a link =)
https://www.dropbox.com/s/fpqp1kgskf6wh ... blend?dl=0
Thank you so much for the help!
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
I see. Well... the one w/ the normal maps looks weird; doesn't exactly match to one or the other, even when I set the normal to -1
More importantly, Blender is only loading one face of the DDS. You'll have to convert the cubemap to a format layout the Blender can recognize as a cubemap before comparing with the Hlms' output (also may be the Hlms wants the inverse normal map; but first the output of Blender without normal maps needs to match Hlms').
More importantly, Blender is only loading one face of the DDS. You'll have to convert the cubemap to a format layout the Blender can recognize as a cubemap before comparing with the Hlms' output (also may be the Hlms wants the inverse normal map; but first the output of Blender without normal maps needs to match Hlms').
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
Thank you very much for your help!
Actually the reflection was just to see it more clearly, but even without the reflection looks different than blender =(
Tried inverting the normals too but looks bad anyways
at least the edges look sharp =D
Actually the reflection was just to see it more clearly, but even without the reflection looks different than blender =(
Tried inverting the normals too but looks bad anyways
at least the edges look sharp =D
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
Actually looks pretty close if I replicate the conditions: 1 single directional light, invert the normal map.
It won't look 100% the same due to possible sRGB missmatches, and roughness vs harndess values.
Also pull the latest 2.1 changes; I discovered a bug in the normal mapping shader code a couple hours ago.
It won't look 100% the same due to possible sRGB missmatches, and roughness vs harndess values.
Also pull the latest 2.1 changes; I discovered a bug in the normal mapping shader code a couple hours ago.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
It has to be with normal maps not inverted to look good on blender, maybe blender does normal mapping a little different, I'll investigate a little more..
at least I help you find a bug? ahhaha
Thank you very much for the help
at least I help you find a bug? ahhaha
Thank you very much for the help
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
Hello, I am still having this problem =(
but before going any deeper (post an example repro, screenshots etc), I would like to know if I am doing something wrong with the normal texture format:
I want to save my normal maps as DDS, wich format/compression is the recomended?
Photoshop:
Gimp:
Shader says:
Thank you very much in advance!
but before going any deeper (post an example repro, screenshots etc), I would like to know if I am doing something wrong with the normal texture format:
I want to save my normal maps as DDS, wich format/compression is the recomended?
Photoshop:
Gimp:
Shader says:
But I tried both and the app crash with this error (in this case, saved in Gimp using "BC5 / ATI2 3Dc")://Normal texture must be in U8V8 or BC5 format!
...
//Normal texture must be in LA format!
and I am loading the texture as TEXTURE_TYPE_NORMALSOGRE EXCEPTION(9:UnimplementedException): unpack from PF_BC5_UNORM not implemented in PixelUtil::unpackColour at /home/sergio/ogre/OgreMain/src/OgrePixelFormat.cpp (line 777)
terminate called after throwing an instance of 'Ogre::Exception'
what(): OGRE EXCEPTION(9:UnimplementedException): unpack from PF_BC5_UNORM not implemented in PixelUtil::unpackColour at /home/sergio/ogre/OgreMain/src/OgrePixelFormat.cpp (line 777)
The program has unexpectedly finished.
Code: Select all
Ogre::HlmsTextureManager::TextureLocation texLocation = hlmsTextureManager->createOrRetrieveTexture( fileName, Ogre::HlmsTextureManager::TEXTURE_TYPE_NORMALS);
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
The format is either U8V8 or BC5S aka BC5_SNORM.
U8V8 is signed normalized uncompressed lossless. In your photoshop plugin it's 8.8 VU 16 bpp | signed. In GIMP the option isn't there.
BC5S is signed normalized compressed lossy. The option is in neither of your plugins; they're exposing BC5U which is the unsigned variant.
I use Visual Studio 2013 (non-express edition) to convert it from RGBA to BC5_SNORM. Alternatively you can use texconv to batch convert your files with the following command:
Use texconv from that link I gave you. There is a different "texconv" utility bundled with DX SDK 2010 that doesn't work.
Last but not least, the most common issue with normal mapping is that it can look inversed from an editor depending on the math used. You can multiply the normal by -1 (GIMP Normal Map plugin -> Filter: Normalize -> -1) or set HlmsPbsDatablock::mNormalMapWeight to -1.0 to do it in the shader at runtime (slightly slower shader of course); or modify the math (probably the problem is in the TBN matrix, being normal binormal tangent instead of normal tangent binormal, or something like that)
U8V8 is signed normalized uncompressed lossless. In your photoshop plugin it's 8.8 VU 16 bpp | signed. In GIMP the option isn't there.
BC5S is signed normalized compressed lossy. The option is in neither of your plugins; they're exposing BC5U which is the unsigned variant.
I use Visual Studio 2013 (non-express edition) to convert it from RGBA to BC5_SNORM. Alternatively you can use texconv to batch convert your files with the following command:
Code: Select all
texconv.exe -f BC5_SNORM C:\PathToFile\MyFile.png -o C:\PathToOutput\MyFile.dds
Last but not least, the most common issue with normal mapping is that it can look inversed from an editor depending on the math used. You can multiply the normal by -1 (GIMP Normal Map plugin -> Filter: Normalize -> -1) or set HlmsPbsDatablock::mNormalMapWeight to -1.0 to do it in the shader at runtime (slightly slower shader of course); or modify the math (probably the problem is in the TBN matrix, being normal binormal tangent instead of normal tangent binormal, or something like that)
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
thank you very much, =( but it wont load:
using "texconv.exe -f BC5_SNORM":
I am in Lubuntu 14.10, but I did the conversions on windows. Maybe I am missing a plugin? library? to be able to load those formats?
Thanks!
using "texconv.exe -f BC5_SNORM":
using photoshop's "8.8 VU 16 bpp | signed":OGRE EXCEPTION(9:UnimplementedException): Signed format origins for normal maps is not tested in PixelUtil::convertForNormalMapping at /home/sergio/ogre/OgreMain/src/OgrePixelFormat.cpp (line 1067)
terminate called after throwing an instance of 'Ogre::Exception'
what(): OGRE EXCEPTION(9:UnimplementedException): Signed format origins for normal maps is not tested in PixelUtil::convertForNormalMapping at /home/sergio/ogre/OgreMain/src/OgrePixelFormat.cpp (line 1067)
The program has unexpectedly finished.
Code: Select all
OGRE EXCEPTION(5:ItemIdentityException): Cannot determine pixel format in DDSCodec::convertPixelFormat at /home/sergio/ogre/OgreMain/src/OgreDDSCodec.cpp (line 531)
terminate called after throwing an instance of 'Ogre::Exception'
what(): OGRE EXCEPTION(5:ItemIdentityException): Cannot determine pixel format in DDSCodec::convertPixelFormat at /home/sergio/ogre/OgreMain/src/OgreDDSCodec.cpp (line 531)
The program has unexpectedly finished.
Thanks!
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
Regarding the BC5S problem: This is a bit of duct tape, but I think the problem is that you should go to OgreHlmsTextureManager.cpp line 116:
And set both to PF_BC5_SNORM by hand.
Regarding you U8V8 problem: The Linux hint was a good one. I think when using the D3D RenderSystem it lets D3D to load the dds, whereas the software DDSCodec routine wasn't tested against a dds file formats with U8V8 format; thus doesn't know how to translate the format found in the header to one of our PF_ formats (it should be PF_R8G8_SNORM).
Btw, if you encode it as a regular PNG file, Ogre will automatically convert them to U8V8 when loading it via the HlmsTextureManager (as long as you don't write the fix from the first parragraph). If you do that though, it may occupy more space in the HDD.
Code: Select all
PixelFormat pf = caps->hasCapability( RSC_TEXTURE_SIGNED_INT ) ? PF_R8G8_SNORM :
PF_BYTE_LA;
mDefaultTextureParameters[TEXTURE_TYPE_NORMALS].pixelFormat = pf;
mDefaultTextureParameters[TEXTURE_TYPE_DETAIL_NORMAL_MAP].pixelFormat = pf;
Regarding you U8V8 problem: The Linux hint was a good one. I think when using the D3D RenderSystem it lets D3D to load the dds, whereas the software DDSCodec routine wasn't tested against a dds file formats with U8V8 format; thus doesn't know how to translate the format found in the header to one of our PF_ formats (it should be PF_R8G8_SNORM).
Btw, if you encode it as a regular PNG file, Ogre will automatically convert them to U8V8 when loading it via the HlmsTextureManager (as long as you don't write the fix from the first parragraph). If you do that though, it may occupy more space in the HDD.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
Thank you very much!! regarding the loading/format issue I will use png for now.
But even if I use png my normals looks strange, I think I found the problem (but not how to solve it yet)
I came back to the problem because we modeled a traffic cone, and it looked awesome in blender, ddo, marmoset, etc... but in Ogre when the normal map was active it looked really weird and it was worst at the normal map seams. I though the problem was the same as the cube mentioned in the original post. but it was not!!
the cube problem I can't figured out yet, but its not that important for me now... but the problem with my traffic cone I know now where is it!! but not how to solve it yet:
Our engine loads blender files by code alla gamekit, using our blender loader the traffic cone looks bad... But using the .mesh exported from blender using the exported it looks good!!, so obviously there is a problem with our loader.
So I save the mesh generated by our loader (the bad one) to an XML and compare it to the one generated by the blender exporter (the good one) and noticed that the "good one" had binormals="true" and for every vertex it has a binormal entry (like: <binormal x="0.756973" y="-0.159393" z="0.633652"/>). So I replaced the "true" by a "false" and now the "good one" looks exactly as the "bad one".
So the problem seems to be the missing binormals on the generated mesh, but the strange thing is that binormals are suppose to be generated in the shader. why is this happening?
But even if I use png my normals looks strange, I think I found the problem (but not how to solve it yet)
I came back to the problem because we modeled a traffic cone, and it looked awesome in blender, ddo, marmoset, etc... but in Ogre when the normal map was active it looked really weird and it was worst at the normal map seams. I though the problem was the same as the cube mentioned in the original post. but it was not!!
the cube problem I can't figured out yet, but its not that important for me now... but the problem with my traffic cone I know now where is it!! but not how to solve it yet:
Our engine loads blender files by code alla gamekit, using our blender loader the traffic cone looks bad... But using the .mesh exported from blender using the exported it looks good!!, so obviously there is a problem with our loader.
So I save the mesh generated by our loader (the bad one) to an XML and compare it to the one generated by the blender exporter (the good one) and noticed that the "good one" had binormals="true" and for every vertex it has a binormal entry (like: <binormal x="0.756973" y="-0.159393" z="0.633652"/>). So I replaced the "true" by a "false" and now the "good one" looks exactly as the "bad one".
So the problem seems to be the missing binormals on the generated mesh, but the strange thing is that binormals are suppose to be generated in the shader. why is this happening?
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
When binormals aren't present, the shader will generate one, but there are two possible binormals (each in opposite directions).
Generating them beforehand eliminates this problem but takes more mesh space. The import process from v1 to v2 defaults to compressing into QTangent for smallest possible (high quality) memory footprint.
Generating them beforehand eliminates this problem but takes more mesh space. The import process from v1 to v2 defaults to compressing into QTangent for smallest possible (high quality) memory footprint.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
Indeed that was the problem, noticed that inverting the cross product in the shader solved the problem, but it braked other things that were looking good, so the final solution was to invert the green channel on my normal map, now looks good. In the future maybe I will construct the binormals in the mesh to avoid this problems.dark_sylinc wrote:but there are two possible binormals (each in opposite directions).
Thank you very much for your help =)
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
Hello again!
Now regarding the texture format... I think...
Why is none of my Normals and Rough/Gloss maps are packed together?
Here is my dump
and total texture capacity is 10. Why they are not being packed?
Maybe it has something to do with the format, I am saving it as "Compression None" in gimp, and "R8G8B8" in photoshop, because the recommended formats crashes Ogre with the exception mentioned before. But anyways the texture manager saves it as L8 and R8G8_SNORM so I dont know =(
Thanks in advance!
Now regarding the texture format... I think...
Why is none of my Normals and Rough/Gloss maps are packed together?
Here is my dump
there are textures that are the same type, size and format, for example:================================Start dump of HlmsTextureManager================================
|#|Type|Width|Height|Depth|Format|HW Gamma|Mipmaps|Size in bytes|Num. active textures|Total texture capacity|Texture Names
|0|DIFFUSE|256|256|40|PF_DXT1|Yes|8|1748160|9|40|CrossHair.dds|Moon.dds|Path.dds|Path_0.dds|Path_1.dds|Path_2.dds|Path_3.dds|Free.dds|menuSelect_D.dds
|1|DIFFUSE|2048|2048|10|PF_DXT1|Yes|11|27962160|10|10|metalBeams_A.dds|metalBeams_S.dds|metalWallInside_A.dds|metalWallInside_S.dds|metalWallOutside_A.dds|metalWallOutside_S.dds|metalWallInside.001_A.dds|metalWallInside.001_S.dds|MetalWallTriangleTop_A.dds|MetalWallTriangleTop_S.dds
|2|DIFFUSE|2048|1024|20|PF_DXT1|Yes|11|27962400|5|20|gate_A.dds|gate_S.dds|windowCeiling_S.dds|containerDoor_A.dds|containerDoor_S.dds
|3|DIFFUSE|1024|1024|40|PF_DXT1|Yes|10|27962560|5|40|endRoof_A.dds|endRoof_S.dds|bricks_D.dds|concrete2_D.dds|Starfield.dds
|4|DIFFUSE|2048|1024|10|PF_DXT5|Yes|11|27962400|1|10|windowCeiling_A.dds
|5|DIFFUSE|2048|2048|10|PF_DXT1|Yes|11|27962160|5|10|metalCeiling_A.dds|metalCeiling_S.dds|concrete1_D.dds|pallet_D.dds|bigBox_D.dds
|6|DIFFUSE|4096|4096|2|PF_DXT1|Yes|12|22369648|2|2|Table_D.dds|Table_S.dds
|7|DIFFUSE|4096|4096|2|PF_DXT1|Yes|12|22369648|1|2|Forklift_D.dds
|8|DIFFUSE|2048|2048|2|PF_A8R8G8B8|Yes|11|44739240|2|2|Forklift_S.dds|bigBox_S.dds
|9|DIFFUSE|512|513|1|PF_DXT5|Yes|9|351600|1|1|clientLogo.dds
|10|DIFFUSE|3840|3840|1|PF_DXT1|Yes|11|9830488|1|1|Clouds.dds
|11|DIFFUSE|128|128|40|PF_DXT1|Yes|7|437440|1|40|Sun.dds
|12|DIFFUSE|512|512|40|PF_DXT5|Yes|9|13982080|1|40|Circle.dds
|13|DIFFUSE|256|256|40|PF_DXT5|Yes|8|3496320|1|40|Arrow.dds
|0|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|metalBeams_G.dds
|1|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|metalWallInside_G.dds
|2|MONOCHROME|2048|1024|10|PF_L8|No|11|27962030|1|10|gate_G.dds
|3|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|metalWallOutside_G.dds
|4|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|metalWallInside.001_G.dds
|5|MONOCHROME|1024|1024|20|PF_L8|No|10|27962020|1|20|endRoof_G.dds
|6|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|MetalWallTriangleTop_G.dds
|7|MONOCHROME|2048|1024|10|PF_L8|No|11|27962030|1|10|windowCeiling_G.dds
|8|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|metalCeiling_G.dds
|9|MONOCHROME|2048|1024|10|PF_L8|No|11|27962030|1|10|containerDoor_G.dds
|10|MONOCHROME|4096|4096|2|PF_L8|No|12|44739242|1|2|Table_G.dds
|11|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|Forklift_R.dds
|0|NORMALS|2048|2048|2|PF_R8G8_SNORM|No|11|22369620|1|2|metalBeams_N.dds
|1|NORMALS|2048|2048|2|PF_R8G8_SNORM|No|11|22369620|1|2|metalWallInside_N.dds
|2|NORMALS|2048|1024|10|PF_R8G8_SNORM|No|11|55924060|1|10|gate_N.dds
|3|NORMALS|2048|2048|2|PF_R8G8_SNORM|No|11|22369620|1|2|metalWallOutside_N.dds
|4|NORMALS|2048|2048|2|PF_R8G8_SNORM|No|11|22369620|1|2|metalWallInside.001_N.dds
|5|NORMALS|1024|1024|10|PF_R8G8_SNORM|No|10|27962020|1|10|endRoof_N.dds
|6|NORMALS|2048|2048|2|PF_R8G8_SNORM|No|11|22369620|1|2|MetalWallTriangleTop_N.dds
|7|NORMALS|2048|1024|10|PF_R8G8_SNORM|No|11|55924060|1|10|windowCeiling_N.dds
|8|NORMALS|2048|2048|2|PF_R8G8_SNORM|No|11|22369620|1|2|metalCeiling_N.dds
|9|NORMALS|2048|1024|10|PF_R8G8_SNORM|No|11|55924060|1|10|containerDoor_N.dds
|10|NORMALS|1024|1024|10|PF_R8G8_SNORM|No|10|27962020|1|10|bricks_N.dds
|11|NORMALS|2048|2048|2|PF_R8G8_SNORM|No|11|22369620|1|2|concrete1_N.dds
|12|NORMALS|1024|1024|10|PF_R8G8_SNORM|No|10|27962020|1|10|concrete2_N.dds
|13|NORMALS|4096|4096|1|PF_R8G8_SNORM|No|12|44739242|1|1|Table_N.dds
|14|NORMALS|4096|4096|1|PF_R8G8_SNORM|No|12|44739242|1|1|Forklift_N.dds
|15|NORMALS|1024|1024|10|PF_R8G8_SNORM|No|10|27962020|1|10|pallet_N.dds
|16|NORMALS|2048|2048|2|PF_R8G8_SNORM|No|11|22369620|1|2|bigBox_N.dds
|0|ENV_MAP|1024|1024|1|PF_DXT1|Yes|10|4194384|1|1|cubemap1.dds
|Size in MBs per category:
|DIFFUSE|247.132
|MONOCHROME|522.667
|NORMALS|522.667
|ENV_MAP|4.00008
|DETAIL|0
|DETAIL_NORMAL_MAP|0
|Total MBs used:|1296.46
================================End dump of HlmsTextureManager================================
|0|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|metalBeams_G.dds
|1|MONOCHROME|2048|2048|10|PF_L8|No|11|55924050|1|10|metalWallInside_G.dds
and total texture capacity is 10. Why they are not being packed?
Maybe it has something to do with the format, I am saving it as "Compression None" in gimp, and "R8G8B8" in photoshop, because the recommended formats crashes Ogre with the exception mentioned before. But anyways the texture manager saves it as L8 and R8G8_SNORM so I dont know =(
Thanks in advance!
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
I was going to take a look at it today, but I wasn't feeling too well.
Whenever I can again I'll take a look. The logic that determines the packing is inside createOrRetrieveTexture, when it calls "findSuitableArray".
Probably for some reason it's not returning an existing iterator and that is what's causing the textures to not get packed together.
Whenever I can again I'll take a look. The logic that determines the packing is inside createOrRetrieveTexture, when it calls "findSuitableArray".
Probably for some reason it's not returning an existing iterator and that is what's causing the textures to not get packed together.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
Thank you very much, hope you feel well soon
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
I was doing some tests and apparently its not finding array because of this part of the if "textureArray.texture->getFormat() == format".
I am saving those textures as "Compression None / Default" in gimp, and "R8G8B8" in photoshop, I understand that then internally they are converted to L8 and R8G8_SNORM, but maybe when checking the format the texture is still "R8G8B8" so it wont fit in the array.
I'll keep digging in case I find another clue
I am saving those textures as "Compression None / Default" in gimp, and "R8G8B8" in photoshop, I understand that then internally they are converted to L8 and R8G8_SNORM, but maybe when checking the format the texture is still "R8G8B8" so it wont fit in the array.
I'll keep digging in case I find another clue
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
I can confirm that's the problem, for example the normals... they are not beeing converted to PF_R8G8_SNORM before looking for array so in the if, PF_R8G8_SNORM != PF_R8G8B8, so it wont packet itxrgo wrote:I was doing some tests and apparently its not finding array because of this part of the if "textureArray.texture->getFormat() == format".
I am saving those textures as "Compression None / Default" in gimp, and "R8G8B8" in photoshop, I understand that then internally they are converted to L8 and R8G8_SNORM, but maybe when checking the format the texture is still "R8G8B8" so it wont fit in the array.
I'll keep digging in case I find another clue
I would love to find a way to convert them before hand, so I can also have smaller size files, but I don't know how yet... other formats than "Compression None / Default" in gimp, and "R8G8B8" in photoshop, just crash my app in Ubuntu.
With a recent commit https://bitbucket.org/sinbad/ogre/commi ... 9a643ad8f2 I can now load UV88 format as normal but they look very wrong
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: [2.1] Hlms Normal Map question
Not sure if was that commit or I was doing something worng but...
Now L8 format in photoshop is working =)!!!! and is packing all monochrome textures fine!!! yay!!
no I just need to solve the normal maps =)
Now L8 format in photoshop is working =)!!!! and is packing all monochrome textures fine!!! yay!!
no I just need to solve the normal maps =)
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [2.1] Hlms Normal Map question
That gave me enough to think about. It's fixed.xrgo wrote:I was doing some tests and apparently its not finding array because of this part of the if "textureArray.texture->getFormat() == format".
I am saving those textures as "Compression None / Default" in gimp, and "R8G8B8" in photoshop, I understand that then internally they are converted to L8 and R8G8_SNORM, but maybe when checking the format the texture is still "R8G8B8" so it wont fit in the array.
I'll keep digging in case I find another clue
I've found the problem: When you load an RGBA8888 texture, it looks for an array with that format, and tries to cram it there. But later the manager sees we need to force R8G8_SNORM, so it creates a new texture and performs the conversion.
Solution is to check we need to force the texture format before looking for an existing array.