[2.1] Hlms Normal Map question

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

[2.1] Hlms Normal Map question

Post by xrgo »

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:
Image
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!
Image

lastly this is my normal map:
Image

and the cube, I just made a simple cube then applied smart uv project

Any ideas? thank you very much in advance!!
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

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?
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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

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!
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

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.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

1. the material is generated by code:

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

Image

Image
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

Is it too much if I ask for the blend files? (for both pictures)
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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!
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

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').
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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

Image

Tried inverting the normals too but looks bad anyways

at least the edges look sharp =D
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

Actually looks pretty close if I replicate the conditions: 1 single directional light, invert the normal map.
Image
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.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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:
Image
Gimp:
Image
Image

Shader says:
//Normal texture must be in U8V8 or BC5 format!
...
//Normal texture must be in LA format!
But I tried both and the app crash with this error (in this case, saved in Gimp using "BC5 / ATI2 3Dc"):
OGRE 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.
and I am loading the texture as TEXTURE_TYPE_NORMALS

Code: Select all

Ogre::HlmsTextureManager::TextureLocation texLocation = hlmsTextureManager->createOrRetrieveTexture( fileName, Ogre::HlmsTextureManager::TEXTURE_TYPE_NORMALS);
Thank you very much in advance!
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

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:

Code: Select all

texconv.exe -f BC5_SNORM C:\PathToFile\MyFile.png -o C:\PathToOutput\MyFile.dds
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)
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

thank you very much, =( but it wont load:

using "texconv.exe -f BC5_SNORM":
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.
using photoshop's "8.8 VU 16 bpp | signed":

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.
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!
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

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:

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;
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.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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?
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

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.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

dark_sylinc wrote:but there are two possible binormals (each in opposite directions).
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.

Thank you very much for your help =)
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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
================================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================================
there are textures that are the same type, size and format, for example:
|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!
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

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.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

Thank you very much, hope you feel well soon :mrgreen:
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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

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
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Hlms Normal Map question

Post by xrgo »

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 =)
User avatar
dark_sylinc
OGRE Team Member
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

Post by dark_sylinc »

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
That gave me enough to think about. It's fixed.
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.
Post Reply