Python api for exporting tangent space normals through script. #29335

New Issue

Eugene Minov · 2011-11-19T18:08:28+01:00

Eugene Minov commented

2011-11-19 18:08:28 +01:00

%%%This patch provides a posibility to export indexed tangents
and normals from blender using the python api.

The normals exporting provided too, because the python API
only gives access to the unconditionally averaged/smooth normals.

To install:
After patching, copy the 'weldmesh' folder from archive into '//blender/intern'.
The weldmesh is a free welding library, provided by Morten Mikkelsen. Much thanks to him!

Sample exporting script for writing tangents, normals and tangent's indices per face to file
is providing as "tangent_stace_test_export.py".
There also a sample blend file with simple model and generated normal map.

The patch is adding new python collections and classes.
For more info, look to 'readme.txt' file in archive.%%%

%%%This patch provides a posibility to export indexed tangents and normals from blender using the python api. The normals exporting provided too, because the python API only gives access to the unconditionally averaged/smooth normals. To install: After patching, copy the 'weldmesh' folder from archive into '//blender/intern'. The weldmesh is a free welding library, provided by Morten Mikkelsen. Much thanks to him! Sample exporting script for writing tangents, normals and tangent's indices per face to file is providing as "tangent_stace_test_export.py". There also a sample blend file with simple model and generated normal map. The patch is adding new python collections and classes. For more info, look to 'readme.txt' file in archive.%%%

Eugene Minov commented

2011-11-19 18:08:28 +01:00

Changed status to: 'Open'

Morten Mikkelsen commented

2011-12-06 15:46:08 +01:00

%%%Your patch has all white space stripped. No one is going to be able to review this patch.%%%

Eugene Minov commented

2011-12-06 19:13:11 +01:00

%%%Hi!
Oops, I'm really sorry for that. Maybe it's because I've created this patch in linux system where line endings
is coded in different way.
However, I've re-upload the patch with right line endings. Hope that now it must be correct.

Many thanks for hint!%%%

%%%Hi! Oops, I'm really sorry for that. Maybe it's because I've created this patch in linux system where line endings is coded in different way. However, I've re-upload the patch with right line endings. Hope that now it must be correct. Many thanks for hint!%%%

Eugene Minov commented

2011-12-06 19:16:46 +01:00

%%%Hmm interesting, how to remove the old one from attachments?
The right one is: 'export_tangents_from_python_patch.patch'%%%

%%%Hmm interesting, how to remove the old one from attachments? The right one is: 'export_tangents_from_python_patch.patch'%%%

Campbell Barton commented

2011-12-06 19:24:09 +01:00

%%%note, please dont configure your editor to strip whitespace

http://wiki.blender.org/index.php/User:Ideasman42/Reply_Id_Like_To_Develop_Blender#Note_on_configuration%%%

%%%note, please dont configure your editor to strip whitespace http://wiki.blender.org/index.php/User:Ideasman42/Reply_Id_Like_To_Develop_Blender#Note_on_configuration%%%

Campbell Barton commented

2011-12-06 19:30:04 +01:00

%%%Hi, sorry to keep on about details but I cant apply this patch, could you re-make it without white space edits please?

attached errors, failing that you could say the revision you diffed against. a developer can update to that revision - apply patch, remove whitespace edits, update to recent revision - but this is not nice to have to do ontop of patch review.%%%

%%%Hi, sorry to keep on about details but I cant apply this patch, could you re-make it without white space edits please? attached errors, failing that you could say the revision you diffed against. a developer can update to that revision - apply patch, remove whitespace edits, update to recent revision - but this is not nice to have to do ontop of patch review.%%%

Eugene Minov commented

2011-12-06 21:24:13 +01:00

%%%Okay. So now I've updated latest blender sources. Seems that revision 42468.
And I've fixed white spaces (I think) in files according to 'FILED' places in 'err.txt' you're sent.

I edited blender sources using CodeBlocks IDE and compiles it with cmake from console
and I didn't knew that it may be those problems with this IDE. Sorry for the inconvenience.

Now I uploaded a patch and archive with other stuff.
Can you please try to patch this one. Hope this'll go.

Thanks.%%%

%%%Okay. So now I've updated latest blender sources. Seems that revision 42468. And I've fixed white spaces (I think) in files according to 'FILED' places in 'err.txt' you're sent. I edited blender sources using CodeBlocks IDE and compiles it with cmake from console and I didn't knew that it may be those problems with this IDE. Sorry for the inconvenience. Now I uploaded a patch and archive with other stuff. Can you please try to patch this one. Hope this'll go. Thanks.%%%

Jean Ayer commented

2012-01-09 07:36:01 +01:00

%%%As an artist who has never complied a C program before, I have been trying all day to get Blender to compile so I can test out this patch. If I can get Blender to actually build, I would love to experiment with the exposed tangent and binormal information. This seems vital in exporting the correct data for a game engine that uses entirely precomputed vertex data. If not from this patch, access to the tangent information via the Python API would add significant strength to Blender when it comes to synchronizing tangent space normal maps between the art application and an external game engine. I hope something for this is added to trunk soon.%%%

Jean Ayer commented

2012-01-09 11:07:29 +01:00

%%%Okay, I eventually did get Blender compiling and managed to clean up the files damaged during patching. Uploaded a txt file containing information about what I had to fix manually, and what I then an error during actual compiling - within rna_mesh.c.%%%

Jean Ayer commented

2012-01-09 11:20:55 +01:00

%%%If anyone wishes to investigate the errors in rna_mesh.c, I have included a new patch based on the cleanup I made to the originally patched files (export_tangents_from_python_patch2.patch). The .patch file itself still appears quite messy, and this is my first time creating such a file, but it at least applies to a clean blender source quickly and without the errors I was getting before. I am using TortoiseSVN however, so results may vary for more advanced users...?

I will probably prod at this a bit more but am afraid the actual code is beyond my skill level and understanding.%%%

%%%If anyone wishes to investigate the errors in rna_mesh.c, I have included a new patch based on the cleanup I made to the originally patched files (export_tangents_from_python_patch2.patch). The .patch file itself still appears quite messy, and this is my first time creating such a file, but it at least applies to a clean blender source quickly and without the errors I was getting before. I am using TortoiseSVN however, so results may vary for more advanced users...? I will probably prod at this a bit more but am afraid the actual code is beyond my skill level and understanding.%%%

Eugene Minov commented

2012-01-09 11:47:59 +01:00

%%%Hi!

I'm glad that you've found idea of my patch useful.
I've looked into txt file with errors, and to help you review the patch I recreated it with latest svn revision (43228)
Try reverse all changes in TortoiseSvn and to apply new patch then.

Hope it helps.%%%

%%%Hi! I'm glad that you've found idea of my patch useful. I've looked into txt file with errors, and to help you review the patch I recreated it with latest svn revision (43228) Try reverse all changes in TortoiseSvn and to apply new patch then. Hope it helps.%%%

Eugene Minov commented

2012-01-09 12:11:31 +01:00

%%%I've compiled and tested patch in 'gcc 4.6.1' only.
So tell me please if compiling errors appears.%%%

%%%I've compiled and tested patch in 'gcc 4.6.1' only. So tell me please if compiling errors appears.%%%

Eugene Minov commented

2012-01-09 12:33:33 +01:00

%%%Oh, sorry.
Does those errors still appears after last patch?
And which compiler did you use?

However, I will try to build patch with Visual C++%%%

%%%Oh, sorry. Does those errors still appears after last patch? And which compiler did you use? However, I will try to build patch with Visual C++%%%

Jean Ayer commented

2012-01-09 18:34:32 +01:00

%%%Thanks - I was able to patch the source at revision 43228 with your new .patch file without any problems, which is good. However, the errors when compiling with scons+msvc2008express commandline are still the same as before (rna_mesh.c complaints regarding the use of StructRNA).

Tried using cmake+msvc2008express solution file, and the build fails here also:

111>Linking...
111>LINK : fatal error LNK1104: cannot open file '....\lib\Debug\bf_rna.lib'

With similar warnings as scons earlier in the build log: http://www.pasteall.org/28035/text

I'm building 32bit on a 64bit OS, since msvc2008express does not allow 64bit builds as far as I know. Base Blender does build fine, but the changes this patch makes to rna_mesh.c are causing problems. Since you say you can get it to compile, I wonder if this is an issue related to the Visual C++ compiler?%%%

%%%Thanks - I was able to patch the source at revision 43228 with your new .patch file without any problems, which is good. However, the errors when compiling with scons+msvc2008express commandline are still the same as before (rna_mesh.c complaints regarding the use of StructRNA). Tried using cmake+msvc2008express solution file, and the build fails here also: 111>Linking... 111>LINK : fatal error LNK1104: cannot open file '..\..\lib\Debug\bf_rna.lib' With similar warnings as scons earlier in the build log: http://www.pasteall.org/28035/text I'm building 32bit on a 64bit OS, since msvc2008express does not allow 64bit builds as far as I know. Base Blender does build fine, but the changes this patch makes to rna_mesh.c are causing problems. Since you say you can get it to compile, I wonder if this is an issue related to the Visual C++ compiler?%%%

Eugene Minov commented

2012-01-10 12:37:07 +01:00

%%%I've installed VisualStudioExpress and compiled rna_mesh.c with cmake+VC9 and seems I've resolved the errors.
Problem was in the variables declaration syntax between pure C and C++ standards, which seems didn't critical in gcc compiler.
So I made a new patch, please try this one.

For some strange reasons I failed to build all blender trunk with VC.
I hope there's no more errors but let me know if you have any.
Thanks.%%%

%%%I've installed VisualStudioExpress and compiled rna_mesh.c with cmake+VC9 and seems I've resolved the errors. Problem was in the variables declaration syntax between pure C and C++ standards, which seems didn't critical in gcc compiler. So I made a new patch, please try this one. For some strange reasons I failed to build all blender trunk with VC. I hope there's no more errors but let me know if you have any. Thanks.%%%

Morten Mikkelsen commented

2012-01-10 19:58:29 +01:00

%%%Can you make sure this also works with the bmesh branch?
Campbell is "considering" putting this in but doesn't have time to adapt it to bmesh himself.%%%

%%%Can you make sure this also works with the bmesh branch? Campbell is "considering" putting this in but doesn't have time to adapt it to bmesh himself.%%%

Eugene Minov commented

2012-01-11 11:36:21 +01:00

%%%Hi!
Okay, I will try to adopt it. Now, I have started downloading bmesh branch from svn.

But.
By the way. Although I'm tested the patch and I think it exports tangents from a CD_TANGENT layer in correct way, there's one
problem I've found some time ago, maybe you can help me understand it.

If, before exporting mesh, I perform the "Minimize Stretch" procedure (Ctrl+V in the UV/Image editor), then in my
game I get a little crumpled-looking faces (those ones which edges is too long relative to other edges).
But in the blender render and in the GLSL view, all faces is looks good no matter how much I Minimized stretch on those faces.

If I do not performing the "Minimize Stretch" procedure, all seems looks correct.

I've not mentioned this before, because I thought that maybe the shader in my game is doing some wrong TBN transformation or something else,
and I waited for somebody tested this patch too.

So what do you think, maybe there something else I might to do with the CD_TANGENT layer's data before or after welding it?%%%

%%%Hi! Okay, I will try to adopt it. Now, I have started downloading bmesh branch from svn. But. By the way. Although I'm tested the patch and I think it exports tangents from a CD_TANGENT layer in correct way, there's one problem I've found some time ago, maybe you can help me understand it. If, before exporting mesh, I perform the "Minimize Stretch" procedure (Ctrl+V in the UV/Image editor), then in my game I get a little crumpled-looking faces (those ones which edges is too long relative to other edges). But in the blender render and in the GLSL view, all faces is looks good no matter how much I Minimized stretch on those faces. If I do not performing the "Minimize Stretch" procedure, all seems looks correct. I've not mentioned this before, because I thought that maybe the shader in my game is doing some wrong TBN transformation or something else, and I waited for somebody tested this patch too. So what do you think, maybe there something else I might to do with the CD_TANGENT layer's data before or after welding it?%%%

Morten Mikkelsen commented

2012-01-11 15:05:54 +01:00

%%%ok. any existing issues will obviously have to be solved before this can be checked in.
Did you follow the pixel shader implementation? --> http://wiki.blender.org/index.php/Dev:Shading/Tangent_Space_Normal_Maps#Pixel_Shader_Transformation%%%

%%%ok. any existing issues will obviously have to be solved before this can be checked in. Did you follow the pixel shader implementation? --> http://wiki.blender.org/index.php/Dev:Shading/Tangent_Space_Normal_Maps#Pixel_Shader_Transformation%%%

Eugene Minov commented

2012-01-11 15:42:30 +01:00

%%%No, I didn't. I just calculated TBN matrix and transformed light and eye vectors by TBN matrix in the vertex shader.
And then used interpolated and normalized tangent space light and eye vectors in the pixel shader.

Yep, that might be my problem.
Instead of this I should transform light and eye normals directly in the pixel shader, with corresponding
with "the pixel shader implementation".

Thanks, I'll try to do in that way.%%%

%%%No, I didn't. I just calculated TBN matrix and transformed light and eye vectors by TBN matrix in the vertex shader. And then used interpolated and normalized tangent space light and eye vectors in the pixel shader. Yep, that might be my problem. Instead of this I should transform light and eye normals directly in the pixel shader, with corresponding with "the pixel shader implementation". Thanks, I'll try to do in that way.%%%

Morten Mikkelsen commented

2012-01-11 15:51:42 +01:00

%%%no you should not transform light and eye vector at all. Transform the normal out of tangent space to the light and view vector. Don't transform the light and view vector.%%%

Eugene Minov commented

2012-01-11 16:14:24 +01:00

%%%Ok! I think I finally start to understand). I'll try.
Thanks!%%%

%%%Ok! I think I finally start to understand). I'll try. Thanks!%%%

Morten Mikkelsen commented

2012-01-11 16:22:29 +01:00

%%%If you want to keep it simple for the first test do the lighting in object space. Transform the eye position and the light position into object space in C/C++ and pass these to the pixel shader. The pixel shader then makes the light direction and the view direction from these and the surface position.%%%

Eugene Minov commented

2012-01-11 21:50:36 +01:00

%%%I rewrote my shader and now it works absolutely nice!
Thanks, my problem resolved!

Also I adapted the patch to bmesh branch and tested it. All seems correct.
And I made a new patch for it from latest svn revision (43283).%%%

%%%I rewrote my shader and now it works absolutely nice! Thanks, my problem resolved! Also I adapted the patch to bmesh branch and tested it. All seems correct. And I made a new patch for it from latest svn revision (43283).%%%

Jean Ayer commented

2012-01-12 02:15:28 +01:00

%%%Nice work! I managed to get the non-bmesh patch to compile at revision 43228, but the test script failed due to not finding mesh.tangent_space at line 68. Of course, I may have simply missed something during the patching process, since I am still new to this. However, I have gotten the latest bmesh patch (revision 43283) to work fine! Compiled fine and the test export python script works, building 32bit blender on a 64bit Windows7 using cmake+msvc2008.

Right now, I am attempting to revise the export script for the game engine I'm working with to make use of the bmesh data (I have noticed UVs are different). Of course, this has nothing to do with the patch... but after that, I should be able to export correct normal, tangent and bitangent data to file, matching the calculations used in blender's baking and viewport. :D%%%

%%%Nice work! I managed to get the non-bmesh patch to compile at revision 43228, but the test script failed due to not finding mesh.tangent_space at line 68. Of course, I may have simply missed something during the patching process, since I am still new to this. However, I have gotten the latest bmesh patch (revision 43283) to work fine! Compiled fine and the test export python script works, building 32bit blender on a 64bit Windows7 using cmake+msvc2008. Right now, I am attempting to revise the export script for the game engine I'm working with to make use of the bmesh data (I have noticed UVs are different). Of course, this has nothing to do with the patch... but after that, I should be able to export correct normal, tangent and bitangent data to file, matching the calculations used in blender's baking and viewport. :D%%%

Eugene Minov commented

2012-01-12 14:16:27 +01:00

%%%Great!

Yes, I've noticed different UVs too.
And in case you did't found how to get them yet,
they accessed in same way, but through "mesh.tessface_uv_textures"
instead of "mesh.uv_textures".%%%

%%%Great! Yes, I've noticed different UVs too. And in case you did't found how to get them yet, they accessed in same way, but through "mesh.tessface_uv_textures" instead of "mesh.uv_textures".%%%

Jean Ayer commented

2012-01-13 06:01:11 +01:00

%%%Unfortunately, I can't find the data in tessface_uv_textures. uv_loop_layers has it, uv coords accessible via uv_loop_layers.active.data- [x].uv, with three values for each triangle indexed in the order of faces. So if you had an n-sided polygon in bmesh, the sequence in the uv loop would be of length n.

The problem I'm having right now is trying to get my export script to write this data accurately. I should state again that I'm not really a programmer at all, I simply have some python knowledge, and have not done much scripting in Blender before. I have found out that tangent_space.faces are indexed differently than a mesh's faces normally are, which I assume is a necessary part of the mikktspace calculation.

What is the difference between the ordering in tangent_space.vertices and the index values accessible via tangent_space.faces- [x].vertices- [x]? At the moment, this export script I'm attempting to modify for bmesh and MeshTangentSpace info is exporting normal faces and uv loop info, while applying tangent information from the data added by this patch. I've realized this is wrong, and that I probably need to export the faces from MeshTSFaces data as well as the vertex info.

So here's my question: since the faces in MeshTSFaces are ordered differently, how am I supposed to synchronize this to the uv loop information in the regular mesh data? Sorry if there is an obvious answer to this, I'm really not the best person for the job of testing this. I simply care very much about getting the correct data exported, and am determined to get it right if possible with the additional data your patch provides.%%%

%%%Unfortunately, I can't find the data in tessface_uv_textures. uv_loop_layers has it, uv coords accessible via uv_loop_layers.active.data- [x].uv, with three values for each triangle indexed in the order of faces. So if you had an n-sided polygon in bmesh, the sequence in the uv loop would be of length n. The problem I'm having right now is trying to get my export script to write this data accurately. I should state again that I'm not really a programmer at all, I simply have some python knowledge, and have not done much scripting in Blender before. I have found out that tangent_space.faces are indexed differently than a mesh's faces normally are, which I assume is a necessary part of the mikktspace calculation. What is the difference between the ordering in tangent_space.vertices and the index values accessible via tangent_space.faces- [x].vertices- [x]? At the moment, this export script I'm attempting to modify for bmesh and MeshTangentSpace info is exporting normal faces and uv loop info, while applying tangent information from the data added by this patch. I've realized this is wrong, and that I probably need to export the faces from MeshTSFaces data as well as the vertex info. So here's my question: since the faces in MeshTSFaces are ordered differently, how am I supposed to synchronize this to the uv loop information in the regular mesh data? Sorry if there is an obvious answer to this, I'm really not the best person for the job of testing this. I simply care very much about getting the correct data exported, and am determined to get it right if possible with the additional data your patch provides.%%%

Eugene Minov commented

2012-01-13 08:25:18 +01:00

%%%Hmm, uv coords via 'uv_loop_layers.active.data- [x].uv' is not work in my case :)
Maybe thing is that we are gets our mesh data in the different ways.

I gets my vertices positions from 'mesh.vertices' witch is an array of unique mesh vertices,
and 'mesh.faces' is an array with face obj, that have 3 or 4 (triangle or quad) indexes for unique vertices from 'mesh.vertices'.

The unique vertices 'mesh.tangent_space.faces- [x].vertices- [x]' is can not be indexed in same order with 'mesh.vertices- [x]', because
there might be more than one tangent and normal vectors per each of the face's vertex.

So, all what is matter is that number of faces: 'len(mesh.faces)' and number of tangent faces 'len(mesh.tangent_space.faces)' are
the same.

Then for each face we can get 3 (or 4 in case of quads) actual unique vertex positions from 'mesh.vertices- [x]' and actual
unique vertex normal and tangent vectors from 'mesh.tangent_space.vertices[n]'.

If, for example, we want to get unindexed vertex data for drawing or else, we do
Like that:

currFace = 0
currVert = 0
while currFace < len(mesh.faces):

  while currVert < len(mesh.faces[currFace].vertices):

      vertUV = mesh.tessface_uv_textures.active.data[currFace].uv[ currVert ]
      vertNormal = mesh.tangent_space.vertices[  mesh.tangent_space.face[currFace].vertices[currVert]  ].normal
      vertTangent = mesh.tangent_space.vertices[  mesh.tangent_space.face[currFace].vertices[currVert]  ].tangent
      vertPos = mesh.vertices[ mesh.face[currFace].vertices[currVert] ].co

      currVert += 1

  currFace += 1

And, don't forget to check if mesh.tessface_uv_textures.active.data is not None before.

But to export mesh data properly, we should export indexed unique data either from 'mesh.vertices- [x]' and from 'mesh.tangent_space.vertices- [x]' (2 arrays), and
also to export indexes for each face's 'vertex from mesh.face- [x].vertices- [x]' and 'mesh.tangent_space.face- [x].vertices[n]'.

We need to export unique vertices and indexes to them separately because in that way we save a lot of memory.

This is the way I do my exporting, sorry if my explanation is not very straight :)
%%%

%%%Hmm, uv coords via 'uv_loop_layers.active.data- [x].uv' is not work in my case :) Maybe thing is that we are gets our mesh data in the different ways. I gets my vertices positions from 'mesh.vertices' witch is an array of unique mesh vertices, and 'mesh.faces' is an array with face obj, that have 3 or 4 (triangle or quad) indexes for unique vertices from 'mesh.vertices'. The unique vertices 'mesh.tangent_space.faces- [x].vertices- [x]' is can not be indexed in same order with 'mesh.vertices- [x]', because there might be more than one tangent and normal vectors per each of the face's vertex. So, all what is matter is that number of faces: 'len(mesh.faces)' and number of tangent faces 'len(mesh.tangent_space.faces)' are the same. Then for each face we can get 3 (or 4 in case of quads) actual unique vertex positions from 'mesh.vertices- [x]' and actual unique vertex normal and tangent vectors from 'mesh.tangent_space.vertices[n]'. If, for example, we want to get unindexed vertex data for drawing or else, we do Like that: currFace = 0 currVert = 0 while currFace < len(mesh.faces): ``` while currVert < len(mesh.faces[currFace].vertices): ``` ``` vertUV = mesh.tessface_uv_textures.active.data[currFace].uv[ currVert ] vertNormal = mesh.tangent_space.vertices[ mesh.tangent_space.face[currFace].vertices[currVert] ].normal vertTangent = mesh.tangent_space.vertices[ mesh.tangent_space.face[currFace].vertices[currVert] ].tangent vertPos = mesh.vertices[ mesh.face[currFace].vertices[currVert] ].co ``` ``` currVert += 1 ``` ``` currFace += 1 ``` And, don't forget to check if mesh.tessface_uv_textures.active.data is not None before. But to export mesh data properly, we should export indexed unique data either from 'mesh.vertices- [x]' and from 'mesh.tangent_space.vertices- [x]' (2 arrays), and also to export indexes for each face's 'vertex from mesh.face- [x].vertices- [x]' and 'mesh.tangent_space.face- [x].vertices[n]'. We need to export unique vertices and indexes to them separately because in that way we save a lot of memory. This is the way I do my exporting, sorry if my explanation is not very straight :) %%%

Tobias Bayer commented

2012-02-18 01:45:22 +01:00

%%%This is really great and a much needed addition to the blender python API, especially for game development with proprietary mesh file types!

Revision 43228 compiled right away with your patch using MinGW and Scons for me.
I'd love to have it in the just released 2.62 stable version, would it be possible to get an updated patch for that if it's not too much of a hassle?%%%

%%%This is really great and a much needed addition to the blender python API, especially for game development with proprietary mesh file types! Revision 43228 compiled right away with your patch using MinGW and Scons for me. I'd love to have it in the just released 2.62 stable version, would it be possible to get an updated patch for that if it's not too much of a hassle?%%%

Eugene Minov commented

2012-02-18 20:47:27 +01:00

%%%No problem!
I made a new patch for blender revision (44231)
Thanks for testing it!%%%

%%%No problem! I made a new patch for blender revision (44231) Thanks for testing it!%%%

Eugene Minov commented

2012-03-13 18:54:24 +01:00

%%%In case anyone need a patch for the latest revision after bmesh branch was merged.
I made a new patch for blender revision (44851)%%%

%%%In case anyone need a patch for the latest revision after bmesh branch was merged. I made a new patch for blender revision (44851)%%%

Morten Mikkelsen commented

2012-04-28 20:13:18 +02:00

%%%Is there an updated patch for the merged trunk?

Cheers,

%%%

%%%Is there an updated patch for the merged trunk? Cheers, %%%

Eugene Minov commented

2012-04-29 00:06:10 +02:00

%%%Hi,
Not yet, but I think the last created r44851 patch may work fine for latest revision.
At least, I used it for r45704 without a conflicts in files.

However I will check today if it works correctly and create a patch for latest revision.%%%

%%%Hi, Not yet, but I think the last created r44851 patch may work fine for latest revision. At least, I used it for r45704 without a conflicts in files. However I will check today if it works correctly and create a patch for latest revision.%%%

Eugene Minov commented

2012-04-29 13:51:15 +02:00

%%%I've checked the patch, it seems works correctly.
But I've noticed that in the python API, accessing mesh's faces syntax was changed from "mesh.faces- [ ]" to "mesh.tessfaces[]".

So I changed the syntax for my part of the api in the similar way.
I.e. from "mesh.tangent_space.faces- [ ]" to "mesh.tangent_space.tessfaces[]".

I made a new patch for blender revision (46064)
Also I re-uploaded a sample exporting script that works with "tess" prefix.

Regards.%%%

%%%I've checked the patch, it seems works correctly. But I've noticed that in the python API, accessing mesh's faces syntax was changed from "mesh.faces- [ ]" to "mesh.tessfaces[]". So I changed the syntax for my part of the api in the similar way. I.e. from "mesh.tangent_space.faces- [ ]" to "mesh.tangent_space.tessfaces[]". I made a new patch for blender revision (46064) Also I re-uploaded a sample exporting script that works with "tess" prefix. Regards.%%%

Sebastian Ullrich commented

2012-05-14 10:56:03 +02:00

%%%Hi there, thanks for the great work! Just one note: I had to manually merge the changes for source/blender/blenkernel/intern/mesh.c with the latest patch 46064 to get it to compile with blender-2.63a-release version. I have created a patch for this too, tried to upload this (did not seem to work). Should I send the file to someone or do i need to wait until i can upload files?

For me the patch seems to work well, although I only tested it with a few examples so far.

Any estimate when the patch will be merged into the trunk or when it will show up in release version? I think it would be very helpful for many people in the community. Keep up the good work and thanks again!

Cheers%%%

%%%Hi there, thanks for the great work! Just one note: I had to manually merge the changes for source/blender/blenkernel/intern/mesh.c with the latest patch 46064 to get it to compile with blender-2.63a-release version. I have created a patch for this too, tried to upload this (did not seem to work). Should I send the file to someone or do i need to wait until i can upload files? For me the patch seems to work well, although I only tested it with a few examples so far. Any estimate when the patch will be merged into the trunk or when it will show up in release version? I think it would be very helpful for many people in the community. Keep up the good work and thanks again! Cheers%%%

Eugene Minov commented

2012-05-14 18:43:50 +02:00

%%%Hi, Sebastian!
I glad that it work and useful for you. And thank you for reviewing it and for the updated patch!
I don't really know is there a possibility to upload files with a comments to a patch tracker, but you can
send your patch on my email (see in Personal Information) and I'll upload it for you from my account.
Or I can try to compile blender-2.63a-release in this days by myself and will also make updated patch.

I'm not sure when the patch will be merged into the trunk, lets hope the developers will found a time for it soon :)

Regards%%%

%%%Hi, Sebastian! I glad that it work and useful for you. And thank you for reviewing it and for the updated patch! I don't really know is there a possibility to upload files with a comments to a patch tracker, but you can send your patch on my email (see in Personal Information) and I'll upload it for you from my account. Or I can try to compile blender-2.63a-release in this days by myself and will also make updated patch. I'm not sure when the patch will be merged into the trunk, lets hope the developers will found a time for it soon :) Regards%%%

Eugene Minov commented

2012-05-15 02:14:38 +02:00

%%%I've uploaded a patch for blender-2.63a-release version (r46548) updated by Sebastian.
It seems work correctly also with latest svn revision (r46644).

Regards.%%%

%%%I've uploaded a patch for blender-2.63a-release version (r46548) updated by Sebastian. It seems work correctly also with latest svn revision (r46644). Regards.%%%

Eugene Minov commented

2012-07-04 21:17:28 +02:00

%%%Have updated a patch.%%%

Eugene Minov commented

2012-11-08 00:59:47 +01:00

%%%I've uploaded a patch for blender-2.64a-release version (r51232).%%%

David Conway commented

2012-11-08 05:26:23 +01:00

%%%I have tested the patches for r46548 and r51232. They work.%%%

Morten Mikkelsen commented

2012-11-10 17:37:43 +01:00

%%%Eugene I really think you should contact Campbell and get this patch included.
If you get the dialogue going I am certain that will lead to getting your work included.
I have seen others bitch about blender not allowing you to get the tangent spaces via the python api
so you're not the only one.
%%%

%%%Eugene I really think you should contact Campbell and get this patch included. If you get the dialogue going I am certain that will lead to getting your work included. I have seen others bitch about blender not allowing you to get the tangent spaces via the python api so you're not the only one. %%%

Eugene Minov commented

2012-11-10 19:11:49 +01:00

%%%Hi Morten, ok, I will contact Cambell about it.%%%

Campbell Barton commented

2012-11-13 16:40:58 +01:00

%%%
I had a look over the patch, while there is nothing especially wrong with the patch, Im not so happy to have all this data added into blenders meshes, but maybe we just accept it, its not that bad.
It just seems like the change has to be done in an intrusive way, but this is really a limit in how we are currently using RNA/DNA, and that RNA doesnt make so much sense for this functionality.

Some things to consider.

Is this for python or C? --- who uses this? (Im assuming python but we have C++ rna API now too)
... C devs can use mikktspace.c directly, or the tangents from the derived mesh if the headers are included.
If this is for python only - we could have some function that lets python get the tangents as python lists/tuples/floats/ints - so there is no need to use RNA for access.

... you could treat this a bit different then adding data into DNA - bypass RNA and just allocate a block of tangents which python can access - like we do for bmesh_py_api.c gets freed when python frees.

The current implementation assumes youll have a mesh - Cycles does this and other areas of blender too, its not so bad but means accessing tangents on derived-mesh-final isnt so simple, it needs converting into a mesh first.
me->tangent_space can easily get out of sync with the real mesh and is only freed on freeing when freeing the mesh, this means an exporter can allocate a bunch of tangents and theres no obvious way to remove them. (a rna function call may be enough here. though I dont especially like this), this is another advantage of doing this with python data structure - this way the script author needs to make sure the data isnt out of sync, but at least they wont get stale data from another script.
%%%

%%% I had a look over the patch, while there is nothing especially wrong with the patch, Im not so happy to have all this data added into blenders meshes, but maybe we just accept it, its not _that_ bad. It just seems like the change has to be done in an intrusive way, but this is really a limit in how we are currently using RNA/DNA, and that RNA doesnt make so much sense for this functionality. Some things to consider. - Is this for python or C? --- who uses this? (Im assuming python but we have C++ rna API now too) ... C devs can use mikktspace.c directly, or the tangents from the derived mesh if the headers are included. - If this is for python only - we could have some function that lets python get the tangents as python lists/tuples/floats/ints - so there is no need to use RNA for access. ... you could treat this a bit different then adding data into DNA - bypass RNA and just allocate a block of tangents which python can access - like we do for bmesh_py_api.c gets freed when python frees. - The current implementation assumes youll have a mesh - Cycles does this and other areas of blender too, its not so bad but means accessing tangents on derived-mesh-final isnt so simple, it needs converting into a mesh first. - me->tangent_space can easily get out of sync with the real mesh and is only freed on freeing when freeing the mesh, this means an exporter can allocate a bunch of tangents and theres no obvious way to remove them. (a rna function call may be enough here. though I dont especially like this), this is another advantage of doing this with python data structure - this way the script author needs to make sure the data isnt out of sync, but at least they wont get stale data from another script. %%%

Morten Mikkelsen commented

2012-11-13 17:13:14 +01:00

%%%I just have a quick comment regarding the mesh part. The purpose of this patch is to allow people who write python plugins to get hold of the
tangent spaces that were used to bake the normal map. These tangent spaces are always calculated on the DM inside of blender.
So the fact that his patch requires a mesh isn't a problem since the objective is to pass the internal spaces to python.

As for your other comments about design I don't have anything to add. Makes sense.
%%%

%%%I just have a quick comment regarding the mesh part. The purpose of this patch is to allow people who write python plugins to get hold of the tangent spaces that were used to bake the normal map. These tangent spaces are always calculated on the DM inside of blender. So the fact that his patch requires a mesh isn't a problem since the objective is to pass the internal spaces to python. As for your other comments about design I don't have anything to add. Makes sense. %%%

Eugene Minov commented

2012-11-13 17:57:05 +01:00

%%%+Campbell

Yes I think this is for python only.
As an additional goal of this patch was to give access not only to tangents but also for vertex normals in a way as they calculated when rendering.
Because it seem, the python api only gave access to the unconditionally averaged/smooth normals or for faces only.

About accessing tangents on derived-mesh-final, are you meant that not from every mesh object we can create an derived mesh object?
If so, then yes it is a problem. If no, then I think that anyway any developer who writes an exporting script will do converting mesh anyway (for example to apply the modifiers stack)
I did freeing tangent_space when freeing the mesh because it seemed most simple way to do. But yes I absolutely agree that there must be a way to clear and refresh it.
How about then to add a couple of methods to it. For example 'tangent_space.refresh()' and 'tangent_space.clear()' (or clean)? Is this will be ok?

I did this through RNA because it the only place in the blender sources where I've found Python data definitions.
Maybe you're right and better to do this functionality through python code. I did not know that it is even possible before. In that case I need to investigate more about it.
But I hope it will be as user friendly as RNA variant.
And also I don't know how difficult it will be to do welding in that case.

Thanks.%%%

%%%+Campbell Yes I think this is for python only. As an additional goal of this patch was to give access not only to tangents but also for vertex normals in a way as they calculated when rendering. Because it seem, the python api only gave access to the unconditionally averaged/smooth normals or for faces only. - About accessing tangents on derived-mesh-final, are you meant that not from every mesh object we can create an derived mesh object? If so, then yes it is a problem. If no, then I think that anyway any developer who writes an exporting script will do converting mesh anyway (for example to apply the modifiers stack) - I did freeing tangent_space when freeing the mesh because it seemed most simple way to do. But yes I absolutely agree that there must be a way to clear and refresh it. How about then to add a couple of methods to it. For example 'tangent_space.refresh()' and 'tangent_space.clear()' (or clean)? Is this will be ok? I did this through RNA because it the only place in the blender sources where I've found Python data definitions. Maybe you're right and better to do this functionality through python code. I did not know that it is even possible before. In that case I need to investigate more about it. But I hope it will be as user friendly as RNA variant. And also I don't know how difficult it will be to do welding in that case. Thanks.%%%

Morten Mikkelsen commented

2012-11-13 19:08:36 +01:00

%%%All I meant was that tangent space is calculated always in:

DM_add_tangent_layer() inside of DerivedMesh.c

So it's done on a DM.%%%

%%%All I meant was that tangent space is calculated always in: DM_add_tangent_layer() inside of DerivedMesh.c So it's done on a DM.%%%

Sebastian Ullrich commented

2013-06-13 10:18:44 +02:00

%%%Hello again.

It's been a while but today I successfully compiled Blender 2.67b (r57415) with the latest version of the attached patch file (export_tangents_patch_blender264a_release(51232).patch).

Are there any updates on integration of the patch into the trunk? The last discussion about this was already half a year ago and the patch already exists since 2011. I would be very happy if I don't need to manually patch each new release of Blender anymore ;)

Thanks.%%%

%%%Hello again. It's been a while but today I successfully compiled Blender 2.67b (r57415) with the latest version of the attached patch file (export_tangents_patch_blender264a_release(51232).patch). Are there any updates on integration of the patch into the trunk? The last discussion about this was already half a year ago and the patch already exists since 2011. I would be very happy if I don't need to manually patch each new release of Blender anymore ;) Thanks.%%%

Morten Mikkelsen commented

2013-06-13 16:05:57 +02:00

%%%Like I told you you need to get hold of campbell. Also known as ideasman on irc in #blendercoders.
I don't think anyone with authority is keep track of this tracker and since a lot of people want the tspace export I think it would be a great idea.

Cheers,%%%

%%%Like I told you you need to get hold of campbell. Also known as ideasman on irc in #blendercoders. I don't think anyone with authority is keep track of this tracker and since a lot of people want the tspace export I think it would be a great idea. Cheers,%%%

Eugene Minov commented

2013-08-18 22:46:55 +02:00

%%%Hi all.
I'm sorry for not updating the patch for long period of time. Have almost no time for this now.
Best what I changed in the patch so far is added two functions: 'mesh.tangent_space.clear()' and 'mesh.tangent_space.refresh()'.
Didn't came up with something better than this yet... At least now, user have a way to clear and refresh tangents when mesh is changed.

I've uploaded a patch for blender-2.68a-release version (r59244) (lattest trunk revision).%%%

%%%Hi all. I'm sorry for not updating the patch for long period of time. Have almost no time for this now. Best what I changed in the patch so far is added two functions: 'mesh.tangent_space.clear()' and 'mesh.tangent_space.refresh()'. Didn't came up with something better than this yet... At least now, user have a way to clear and refresh tangents when mesh is changed. I've uploaded a patch for blender-2.68a-release version (r59244) (lattest trunk revision).%%%

Sebastian Ullrich commented

2013-11-11 17:29:57 +01:00

%%%Hi, I made some minor changes for the patch to work with Blender-2.69 release. Trying to upload to attachments...%%%

Sebastian Brachi commented

2014-01-06 03:24:55 +01:00

Added subscriber: @Brachi

Anders Christiansson commented

2014-02-15 00:55:01 +01:00

Added subscriber: @drakfluga

Anders Christiansson commented

2014-02-15 01:11:47 +01:00

Hi there!
Still no progress on getting tangent export Blender it seems. I wanted to say that I did get hold of Campbell (ideasman_42) on IRC in September last year. He told me the patch was "too intrusive" and that they would implement it another way. He said he'd forwarded the request to a guy called Bastien, who apparently was working on game pipeline features at the time. I haven't checked back after that so I'm not sure if any work has been done or what the status is right now. If anyone knows who this Bastien is, I'd be extremely grateful to have some sort of news either way.
I hope there's some progress on this soon. I've been following the discussion for two or three years now, it's a crucial feature for game developers and it's sad that this rather important functionality is still missing from what is otherwise a competent package.

Cheers!

Andy

Hi there! Still no progress on getting tangent export Blender it seems. I wanted to say that I did get hold of Campbell (ideasman_42) on IRC in September last year. He told me the patch was "too intrusive" and that they would implement it another way. He said he'd forwarded the request to a guy called Bastien, who apparently was working on game pipeline features at the time. I haven't checked back after that so I'm not sure if any work has been done or what the status is right now. If anyone knows who this Bastien is, I'd be extremely grateful to have some sort of news either way. I hope there's some progress on this soon. I've been following the discussion for two or three years now, it's a crucial feature for game developers and it's sad that this rather important functionality is still missing from what is otherwise a competent package. Cheers! - Andy

Brecht Van Lommel commented

2014-02-15 01:22:49 +01:00

Added subscribers: @mont29, @brecht

Brecht Van Lommel commented

2014-02-15 01:22:49 +01:00

Bastien is @mont29, and he implemented support for this which will be in 2.70, see the API docs here:

http://www.blender.org/documentation/blender_python_api_2_69_10/bpy.types.Mesh.html?highlight=calc_tangents#bpy.types.Mesh.calc_tangents
http://www.blender.org/documentation/blender_python_api_2_69_10/bpy.types.MeshLoop.html?highlight=tangent#bpy.types.MeshLoop.tangent

Bastien is @mont29, and he implemented support for this which will be in 2.70, see the API docs here: http://www.blender.org/documentation/blender_python_api_2_69_10/bpy.types.Mesh.html?highlight=calc_tangents#bpy.types.Mesh.calc_tangents http://www.blender.org/documentation/blender_python_api_2_69_10/bpy.types.MeshLoop.html?highlight=tangent#bpy.types.MeshLoop.tangent

Anders Christiansson commented

2014-02-15 01:30:49 +01:00

This makes me incredibly happy!
Thank you very much! If it's in the trunk I'll build the latest rev and start looking into it right away. :)

This makes me incredibly happy! Thank you very much! If it's in the trunk I'll build the latest rev and start looking into it right away. :)

Campbell Barton commented

2014-02-19 04:41:43 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2014-02-19 04:41:43 +01:00

Campbell Barton commented

2014-02-19 04:41:43 +01:00

Closing since this has been made possible via an alternative patch.