tag:blogger.com,1999:blog-37021975898270034082017-07-20T04:08:44.670-07:00DiffeomorphicThomas Larssonnoreply@blogger.comBlogger11125tag:blogger.com,1999:blog-3702197589827003408.post-53468406047087999412017-07-13T10:34:00.000-07:002017-07-13T10:36:01.187-07:00JSON fittingIt turned out that the <a href="http://diffeomorphic.blogspot.se/2017/06/fbx-fitting.html">FBX fitting method</a> had flaws as well. However, since then I have come up with yet another way to extract the information about mesh and bone locations, and this time it seems to work, at least for all files that I have tried.<br /><br />The idea is simply to write an export script for Daz Studio, that exports exactly the necessary information to a custom file. There were some initial hurdles, because I have not written scripts for Daz Studio before. The scripting language is not Python but something similar to Java or QT, which is not terribly difficult although something I have little experience with. What was tricky was that the API is poorly documented, but I managed to find some examples on the Internet that were sufficient for my simple script.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-pvqZDMs9420/WWemAhd4pdI/AAAAAAAAAeA/x84OKH3mfeQFhJa6RaU9-lHOzbKnqAcAgCK4BGAYYCw/s1600/000-script.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="137" src="https://4.bp.blogspot.com/-pvqZDMs9420/WWemAhd4pdI/AAAAAAAAAeA/x84OKH3mfeQFhJa6RaU9-lHOzbKnqAcAgCK4BGAYYCw/s640/000-script.png" width="640" /></a></div><br />The script is located in the folder to_daz_studio and is called export_basic_data.dsa. Before we can use it, we need to tell Daz Studio about it. This is done as follows.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-K8Zpmrm4KzY/WWemU6IakhI/AAAAAAAAAeI/r491Q109udcZutbxehj-a-SNRvSRW0uKgCK4BGAYYCw/s1600/100-customize.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://3.bp.blogspot.com/-K8Zpmrm4KzY/WWemU6IakhI/AAAAAAAAAeI/r491Q109udcZutbxehj-a-SNRvSRW0uKgCK4BGAYYCw/s400/100-customize.png" width="400" /></a></div><br />In Daz Studio, select Window > Workspace > Customize.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-z9cNLmxWXao/WWemh6RmdyI/AAAAAAAAAeQ/x8ys5T0f7lcjGJzlPqkjq5OCoh96uJVkwCK4BGAYYCw/s1600/110-right-click.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="202" src="https://3.bp.blogspot.com/-z9cNLmxWXao/WWemh6RmdyI/AAAAAAAAAeQ/x8ys5T0f7lcjGJzlPqkjq5OCoh96uJVkwCK4BGAYYCw/s400/110-right-click.png" width="400" /></a></div><br />In the customize windows that opens, right-click on Custom and select Create New Custom Action.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-xYcs9opgGEE/WWem8mm_S0I/AAAAAAAAAeY/wJgih4tv1PIKAv-1O_5Wn22yyfwSoimagCK4BGAYYCw/s1600/120-edit-custom-action.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="167" src="https://3.bp.blogspot.com/-xYcs9opgGEE/WWem8mm_S0I/AAAAAAAAAeY/wJgih4tv1PIKAv-1O_5Wn22yyfwSoimagCK4BGAYYCw/s400/120-edit-custom-action.png" width="400" /></a></div>Change the Menu Text to Export Basic Data (or whatever you want to scripts name to be). Make sure that DAZ Script File is selected and press the ... button to the right.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-cRrArYyM4ig/WWenl11GmSI/AAAAAAAAAeg/Dx3t5sjWGtwiyd-HUHcIXNqlbUf2IeVnwCK4BGAYYCw/s1600/130-select-file.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="https://3.bp.blogspot.com/-cRrArYyM4ig/WWenl11GmSI/AAAAAAAAAeg/Dx3t5sjWGtwiyd-HUHcIXNqlbUf2IeVnwCK4BGAYYCw/s320/130-select-file.png" width="320" /></a></div>A file selector opens. Navigate to the .dsa file and Open it.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-NFd-IarSmc0/WWeoJTO5XZI/AAAAAAAAAeo/9PElLCMDgws_J3oyAcsq-lxtwI2mGpWSQCK4BGAYYCw/s1600/140-accept.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="190" src="https://4.bp.blogspot.com/-NFd-IarSmc0/WWeoJTO5XZI/AAAAAAAAAeo/9PElLCMDgws_J3oyAcsq-lxtwI2mGpWSQCK4BGAYYCw/s320/140-accept.png" width="320" /></a></div>The file name now appears in File field. Press Accept to close the dialog window.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-w9-QdUp-tVo/WWeoaEms_XI/AAAAAAAAAew/LBz4dbchgXQbNVofOpCekV_ZxxKxd3cOACK4BGAYYCw/s1600/150-menus.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://2.bp.blogspot.com/-w9-QdUp-tVo/WWeoaEms_XI/AAAAAAAAAew/LBz4dbchgXQbNVofOpCekV_ZxxKxd3cOACK4BGAYYCw/s320/150-menus.png" width="308" /></a></div>The script now appears as a subitem under Custom. In the pane to the right, choose the Menus tab, and drag the script to the place you want it to appear. Since it is an export script, I find it natural to group it with the Import and Export menu items. Press Apply to make the changes take place, and then press Accept to close the dialog.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-RSiRWJBmI-8/WWepFunEWDI/AAAAAAAAAe4/ziWov_JxnzcnLy2nLwtQKrfroD9Etfv6gCK4BGAYYCw/s1600/160-export-basic.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://4.bp.blogspot.com/-RSiRWJBmI-8/WWepFunEWDI/AAAAAAAAAe4/ziWov_JxnzcnLy2nLwtQKrfroD9Etfv6gCK4BGAYYCw/s320/160-export-basic.png" width="205" /></a></div><br />The new export script now appears in the File menu. Select it to export the basic data for the current scene.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-BaTU4t_Gkuw/WWep5k86UfI/AAAAAAAAAfA/ar5CnnFlIEY0mUeDhHiI7rYmvCH4S46fgCK4BGAYYCw/s1600/170-save-json.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="235" src="https://2.bp.blogspot.com/-BaTU4t_Gkuw/WWep5k86UfI/AAAAAAAAAfA/ar5CnnFlIEY0mUeDhHiI7rYmvCH4S46fgCK4BGAYYCw/s320/170-save-json.png" width="320" /></a></div>Export the scene with the same name as the .duf file, but with the extension .json instead. My scene was unimaginably called test.duf, so the file name must be test.json. The script actually ignores the extension, so if you just call the file test it will still get the right extension automatically.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-a8lBK7CWVLU/WWeqx0tw-WI/AAAAAAAAAfI/k4NC7fkqoxkynWQ2W7QQJAyE2lizQ8GrwCK4BGAYYCw/s1600/180-saved.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="86" src="https://1.bp.blogspot.com/-a8lBK7CWVLU/WWeqx0tw-WI/AAAAAAAAAfI/k4NC7fkqoxkynWQ2W7QQJAyE2lizQ8GrwCK4BGAYYCw/s400/180-saved.png" width="400" /></a></div><br />A dialog informs when the file has been exported. I don't know what happens if the script fails for some reason, because it has actually never happened so far.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-EqOWSGskSx8/WWer8WjVo7I/AAAAAAAAAfQ/J363CTzRYv8yPwEaxXePnbxxyzw1ehVjgCK4BGAYYCw/s1600/190-import-json.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://4.bp.blogspot.com/-EqOWSGskSx8/WWer8WjVo7I/AAAAAAAAAfQ/J363CTzRYv8yPwEaxXePnbxxyzw1ehVjgCK4BGAYYCw/s200/190-import-json.png" width="150" /></a></div><br />Finally in Blender, select Json File for Mesh Fitting. The scene should now be imported, and the meshes and bones should look as they do in Daz Studio.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-OHqdJBwkGzc/WWesRoVfHsI/AAAAAAAAAfY/zko9G1EE9SIPEFCkq1ReJ0DGF9cL2VHVgCK4BGAYYCw/s1600/200-json.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="305" src="https://3.bp.blogspot.com/-OHqdJBwkGzc/WWesRoVfHsI/AAAAAAAAAfY/zko9G1EE9SIPEFCkq1ReJ0DGF9cL2VHVgCK4BGAYYCw/s320/200-json.png" width="320" /></a></div><br />Here is the same character that we imported with Obj, Collada, and Fbx fitting in the<a href="http://diffeomorphic.blogspot.se/2017/06/fbx-fitting.html"> previous post</a>. There are, as far as I can tell, no obvious glitches. In particular, the feet fit correctly into the high-heeled boots, something that always required manual tweaking with the other fitting methods.<br /><br />With this addition, I think that the Daz Importer is ready for the next stable release. I have not spent much time improving the code recently, but I have actually used the importer quite a bit myself, and to me the tool set feels rather finished.<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-8087249494876694372017-06-30T19:39:00.003-07:002017-06-30T19:49:32.590-07:00FBX fittingDuring the last few months I felt rather fed up with 3D, but very recently I started to play with the Daz Importer again, and there are a few new things to report.<br /><br />First, Daz has released a new character base, Genesis 8, which is available if you update Daz Studio to the most recent version. I must have been doing something right, because adding this character to the Daz Importer was surprisingly painless, even if there probably are some glitches left. The main problems had to do with the rest pose; Genesis 3 is in T-pose but Genesis 8 is in A-pose.<br /><br />The other news is that character fitting can now be done with fbx files. In some cases this works better than obj or Collada (but in other cases it is worse). In particular, there has been a problem with the skeleton when some body parts are scaled. The Daz Importer uses the preview field in the duf file to determine the bone locations, and whereas this field takes most of the transformations into account, some scale transformations are ignored. However, they are included in the skeleton exported to fbx, so the importer can use this information to deduce the correct bone locations.<br /><br /><a href="http://1.bp.blogspot.com/-yoA3ueJ8kyg/WVb7wZffZAI/AAAAAAAAAcY/p_iCYMv0aWcPTpIFkhv_G4pJtohSRsOfwCK4BGAYYCw/s1600/shu-ds.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-yoA3ueJ8kyg/WVb7wZffZAI/AAAAAAAAAcY/p_iCYMv0aWcPTpIFkhv_G4pJtohSRsOfwCK4BGAYYCw/s320/shu-ds.png" width="291" /></a><br /><br />Here is a character in Daz Studio. The chest, hands and feet have been scaled, transformations that are not stored in the preview field in the duf file. In addition, the leg length and breast size have been increased.<br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><br /><br /><br /><br /><br /><br /><br /><a href="http://2.bp.blogspot.com/-9O5LhrfnBlM/WVb8b7u-I6I/AAAAAAAAAck/hYWnmencpos1UtVW4enHAK1wSm-2bR3CACK4BGAYYCw/s1600/fbx-export.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="400" src="https://2.bp.blogspot.com/-9O5LhrfnBlM/WVb8b7u-I6I/AAAAAAAAAck/hYWnmencpos1UtVW4enHAK1wSm-2bR3CACK4BGAYYCw/s400/fbx-export.png" width="251" /></a><br /><br />Export the character as an fbx file. It is important that you export it as an ascii fbx file; the importer can not read binary fbx and will generate an error if you try. The fbx format seems to change for every year, but it does not seem to matter which fbx version you select, as long as it is ascii. The other settings do not seem to be important, except that Allow Degraded Skinning and Scaling should be selected, because otherwise the exporter complains.<br /><br /><a href="http://4.bp.blogspot.com/-8AOpebrLYTA/WVb9vxhs_rI/AAAAAAAAAcw/KPXpzGBkIKY-wne9_qaazmqRhJGgIY50wCK4BGAYYCw/s1600/shu-obj.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="276" src="https://4.bp.blogspot.com/-8AOpebrLYTA/WVb9vxhs_rI/AAAAAAAAAcw/KPXpzGBkIKY-wne9_qaazmqRhJGgIY50wCK4BGAYYCw/s320/shu-obj.png" width="320" /></a><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /> Here is the character imported with Mesh Fitting set to Obj File (blue clothes). The mesh contains all morphs, but the skeleton does not fit the mesh: the arms and head are to low, because chest scaling is ignored, and the hands and the feet are too small.<br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><a href="http://3.bp.blogspot.com/-bj5zm6vQo9k/WVb-yVl52yI/AAAAAAAAAc8/FNx_Bj9jJAQmqrffKTvHpxcdy0xZc0xOACK4BGAYYCw/s1600/shu-dae.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="301" src="https://3.bp.blogspot.com/-bj5zm6vQo9k/WVb-yVl52yI/AAAAAAAAAc8/FNx_Bj9jJAQmqrffKTvHpxcdy0xZc0xOACK4BGAYYCw/s320/shu-dae.png" width="320" /></a><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><br /><br /><br />If we instead import the character with Mesh Fitting set to Dae file (red clothes), the armature fits the character mesh, but this is only because the scale transformations are ignored for the mesh as well. They are weirdly present in the clothes meshes, however. <br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-dfHrHrlVurU/WVb-0NKdUJI/AAAAAAAAAdE/xkwMCLvIUes2Zg3XJV3p9wq0gLHd0zGzwCK4BGAYYCw/s1600/shu-dae-obj.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="https://2.bp.blogspot.com/-dfHrHrlVurU/WVb-0NKdUJI/AAAAAAAAAdE/xkwMCLvIUes2Zg3XJV3p9wq0gLHd0zGzwCK4BGAYYCw/s320/shu-dae-obj.png" width="292" /></a></div><br /><br /><br />The red Collada character compared to the blue obj character.<br /><br /><br /><br /><br /><br /><br /><br />There are also a problem with the boots. This must be a bug in Daz Studio's Collada exporter, because the boots look equally ugly when the dae file is imported directly with the Collada importer.<br /><br /><a href="http://3.bp.blogspot.com/-G7knprSQED4/WVcBjy2GT_I/AAAAAAAAAdQ/wixn2XBqBtg2WeFVDzzJZwqUWtr0t68AgCK4BGAYYCw/s1600/shu-shoe.png" imageanchor="1"><img border="0" height="170" src="https://3.bp.blogspot.com/-G7knprSQED4/WVcBjy2GT_I/AAAAAAAAAdQ/wixn2XBqBtg2WeFVDzzJZwqUWtr0t68AgCK4BGAYYCw/s400/shu-shoe.png" width="400" /></a><br /><br /><br /><a href="http://2.bp.blogspot.com/-o6K2vqkqCL8/WVcB4WN_JxI/AAAAAAAAAdY/6kdZm6KeQ6ALrnedZaRKk2ADEssaHGD_wCK4BGAYYCw/s1600/shu-fbx.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="272" src="https://2.bp.blogspot.com/-o6K2vqkqCL8/WVcB4WN_JxI/AAAAAAAAAdY/6kdZm6KeQ6ALrnedZaRKk2ADEssaHGD_wCK4BGAYYCw/s320/shu-fbx.png" width="320" /></a><br /><br /><br />Finally, here is the character imported with Mesh Fitting set to Fbx File (green clothes). <br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><a href="http://2.bp.blogspot.com/-Kcf9mGj5EaE/WVcHknay5YI/AAAAAAAAAdo/JTAjAvjuTB0SHOXf0dSzzHN_hb4Am8adgCK4BGAYYCw/s1600/shu-fbx-obj.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="https://2.bp.blogspot.com/-Kcf9mGj5EaE/WVcHknay5YI/AAAAAAAAAdo/JTAjAvjuTB0SHOXf0dSzzHN_hb4Am8adgCK4BGAYYCw/s320/shu-fbx-obj.png" width="283" /></a><br /><br /><br />The mesh is the same as the blue obj mesh, and the skeleton fits the mesh.<br /><br /><br /><br /><br /><a href="http://2.bp.blogspot.com/-RUEtmgRZIUE/WVcHyhqmp8I/AAAAAAAAAdw/6nefMLbpU_g3kigtwGii3rDLnVBjcBWrACK4BGAYYCw/s1600/fbx-boots.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="https://2.bp.blogspot.com/-RUEtmgRZIUE/WVcHyhqmp8I/AAAAAAAAAdw/6nefMLbpU_g3kigtwGii3rDLnVBjcBWrACK4BGAYYCw/s320/fbx-boots.png" width="311" /></a><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />When writing this post, I realize that there still is a problem with the bones. The duf file specifies both the bone head (center_point) and tail (end_point), but the fbx format only contains formation about the bone's head and orientation. For simplicity, I chose to translate the tail the same distance as the head, but for the posed foot this gave the rather strange result show here.<br /><br />This is probably not such a huge problem, and it goes away if you choose to Merge Toes.<br /><br /><br /><br />However, there are other where fbx fitting produces worse results than obj or dae. In some cases the solution might be to import several versions of the character, with different types of Mesh Fitting, and only keep the meshes and rigs that are most faithful to the original.<br /><br /><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br /><span id="goog_789950476"></span><span id="goog_789950477"></span><span id="goog_1447108410"></span><span id="goog_1447108411"></span><br />Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-24064734813696519762017-03-20T19:25:00.002-07:002017-03-20T21:04:53.665-07:00Low-poly versions <br /><a href="https://1.bp.blogspot.com/-DuA6CSTuQFY/WNCRmvthaWI/AAAAAAAAAZw/8ES_nhwnCfAAj8eYwLl5p12ztyxMpHmeACLcB/s1600/panel.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-DuA6CSTuQFY/WNCRmvthaWI/AAAAAAAAAZw/8ES_nhwnCfAAj8eYwLl5p12ztyxMpHmeACLcB/s320/panel.png" width="190" /></a><br />Assets from Daz Studio are usually awesome, but they often have a high polygon count. This can give problems with performance, especially if you like me use an old Win 7 box from 2009 with only six gigs of ram. Often it is possible to reduce the polygon count with little effect on the final renders.<br /><br />This is where the Low-poly Versions section at the bottom of the Setup panel comes in. In the unstable version it looks like this <br /><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-oRle0qf1_k8/WNCRuKgAWOI/AAAAAAAAAZ0/kCyHZRWsw4gex-Rf7vYdxbfyDIPIEV1VwCLcB/s1600/original.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="258" src="https://1.bp.blogspot.com/-oRle0qf1_k8/WNCRuKgAWOI/AAAAAAAAAZ0/kCyHZRWsw4gex-Rf7vYdxbfyDIPIEV1VwCLcB/s320/original.png" width="320" /></a></div><br /> Here is the original character, weighting in<br /><br />Verts: 21556, Edges: 42599, Faces: 21098<br /><br /><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-vkmUCsOVi7U/WNCTJY6lS6I/AAAAAAAAAaA/T-wjk6SxftUKnZyZ9iSO5rNH1fdY-ms7wCLcB/s1600/quick.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="254" src="https://4.bp.blogspot.com/-vkmUCsOVi7U/WNCTJY6lS6I/AAAAAAAAAaA/T-wjk6SxftUKnZyZ9iSO5rNH1fdY-ms7wCLcB/s320/quick.png" width="320" /></a></div>The Make Quick Low-poly button reduces her footprint to<br /><br />Verts: 7554, Edges: 17800, Faces: 10311<br /><br />i.e. the number of vertices is almost reduced to a third.<br /><br />However, there are a number of problems, e.g. the black spots in the should areas. The quick low-poly uses Blender's Decimate modifier, which does not respect UV seams. A decimated face can contain vertices in different UV islands, making the middle of the face stretch over random parts of the texture.<br /><br />Moreover, since the quick low-poly applies a modifier, the mesh must not have any shapekeys. This is not such a big problem for Genesis 3, where facial expressions are implemented with bones, but for Genesis and Genesis 2 this means no face expressions. The Apply Morphs button is duplicated in this section to get rid of any shapekeys before making a quick low-poly.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-ylzaZp_sJjA/WNCVwzLsJgI/AAAAAAAAAaM/NhshROs3FdkcL8uT1YnIdmdHDjkocM2HwCLcB/s1600/faithful.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="243" src="https://4.bp.blogspot.com/-ylzaZp_sJjA/WNCVwzLsJgI/AAAAAAAAAaM/NhshROs3FdkcL8uT1YnIdmdHDjkocM2HwCLcB/s320/faithful.png" width="320" /></a></div>To deal with these problems, a second algorithm has been implemented, the faithful low-poly. It is faithful in the sense that UV seams are respected, so there are no faces stretching over unknown parts of the texture.<br /><br />The footprint of the faithful low-poly is<br /><br />Verts: 11885, Edges: 21136, Faces: 9306<br /><br />This is slightly higher than the quick low-poly, but still a nice reduction.<br /><br /><a href="https://3.bp.blogspot.com/-7GQjizZlY5E/WNCWwXkRPvI/AAAAAAAAAaY/eP5n-N8LISQjtdaCvMxeL6PupwiKQDhRQCLcB/s1600/subsurf.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="234" src="https://3.bp.blogspot.com/-7GQjizZlY5E/WNCWwXkRPvI/AAAAAAAAAaY/eP5n-N8LISQjtdaCvMxeL6PupwiKQDhRQCLcB/s320/subsurf.png" width="320" /></a>There are still some problems. In the illustration the shoulders become very jagged when posed. This can be fixed by adding a Subdivision Surface modifier. If the number of view subdivisions is set to zero, the viewport performance should not suffer too much.<br /><br /><br /><br /><br /><br /><br /><br /><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-H3UgpnGvk0Y/WNCYHCjdeSI/AAAAAAAAAak/SkAPcjGqC2EXL0h5xA27m5mNC0W56VkIwCLcB/s1600/thigh.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="156" src="https://1.bp.blogspot.com/-H3UgpnGvk0Y/WNCYHCjdeSI/AAAAAAAAAak/SkAPcjGqC2EXL0h5xA27m5mNC0W56VkIwCLcB/s320/thigh.png" width="320" /></a></div><a href="https://4.bp.blogspot.com/-pbjViHFI_Ew/WNCYzny6I3I/AAAAAAAAAas/eKkuMEOYqSUwu0dh0PbjrZy1v-IU6UeXwCLcB/s1600/thigh-triangulated.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="157" src="https://4.bp.blogspot.com/-pbjViHFI_Ew/WNCYzny6I3I/AAAAAAAAAas/eKkuMEOYqSUwu0dh0PbjrZy1v-IU6UeXwCLcB/s320/thigh-triangulated.png" width="320" /></a>Another problem is that the algorithm produces n-gons, which sometimes leads to bad results. This can be fixed by the Split n-gons button. <br /><br />After triangulating n-gons the character weighs<br /><br />Verts: 11885, Edges: 31111, Faces: 19281<br /><br />The number of edges and faces has gone up considerably, but I'm not sure that this affects performance, since complicated n-gons have been replaced by simple triangles. The number of vertices stays the same, which is what I think is most important for performance.<br /><br /><br /><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-ROrVa-_bLMA/WNCaAJDhPkI/AAAAAAAAAa4/bQYoYc7irosJ19bHthNzwJq5nUbe14NogCLcB/s1600/hair-original.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="224" src="https://4.bp.blogspot.com/-ROrVa-_bLMA/WNCaAJDhPkI/AAAAAAAAAa4/bQYoYc7irosJ19bHthNzwJq5nUbe14NogCLcB/s320/hair-original.png" width="320" /></a></div>Hair can be particularly problematic for performance. The Aldora hair, which came with some earlier version of Daz Studio, has the impressive footprint<br /><br />Verts: 123506, Edges: 240687, Faces: 117264<br /><br />Reducing the weight of a 21,000 verts character makes little sense if we leave her with 123,000 verts worth of hair.<br /><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-kjQi7ZMuV3M/WNCa06owIyI/AAAAAAAAAbE/x_dzkJkSsvkUVMVAucTt5OWFTW1dRbETwCLcB/s1600/hair-step1.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="218" src="https://1.bp.blogspot.com/-kjQi7ZMuV3M/WNCa06owIyI/AAAAAAAAAbE/x_dzkJkSsvkUVMVAucTt5OWFTW1dRbETwCLcB/s320/hair-step1.png" width="320" /></a></div>Making a faithful low-poly of the hair reduces the footprint to<br /><br />Verts: 32574, Edges: 61862, Faces: 29370<br /><br />without any notable reduction of quality.<br /><br /><br /><br /><br /><br /><br /><a href="https://4.bp.blogspot.com/-rlQLiqewfj4/WNCbjFovuZI/AAAAAAAAAbM/AjboNVD7hIszYv6XdJWMGYICEVIeslrSACLcB/s1600/hair-step2.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="226" src="https://4.bp.blogspot.com/-rlQLiqewfj4/WNCbjFovuZI/AAAAAAAAAbM/AjboNVD7hIszYv6XdJWMGYICEVIeslrSACLcB/s320/hair-step2.png" width="320" /></a>A second iteration of the Faithful Low-poly button reduces the hair further<br /><br />Verts: 9281, Edges: 16743, Faces: 7544<br /><br />Compared to the original 123,000 verts, the footprint has gone down with more than a factor of ten!<br /><br />We now start to see some bald spots on the head, but it should not be too difficult to fix them in edit mode.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-mcecO4vHfek/WNCcIapt0YI/AAAAAAAAAbU/58n2L5enDXIhJcMYg5E4AbGtxbEKLGabgCLcB/s1600/hair-quick2.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="219" src="https://2.bp.blogspot.com/-mcecO4vHfek/WNCcIapt0YI/AAAAAAAAAbU/58n2L5enDXIhJcMYg5E4AbGtxbEKLGabgCLcB/s320/hair-quick2.png" width="320" /></a></div>If we instead made a quick low-poly in the last step, the footprint became<br /><br />Verts: 10081, Edges: 20047, Faces: 10048<br /><br />The baldness problem is perhaps a little less pronounced, but some manual editing is still needed.<br /><br /><br /><br /><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-1fkkrQyKtzs/WNCieia82jI/AAAAAAAAAbw/BRDxD0eEu3UaS2rI7eZuf_6yz1tW9GguwCLcB/s1600/hair2-original.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="139" src="https://3.bp.blogspot.com/-1fkkrQyKtzs/WNCieia82jI/AAAAAAAAAbw/BRDxD0eEu3UaS2rI7eZuf_6yz1tW9GguwCLcB/s320/hair2-original.png" width="320" /></a></div>Another way to reduce the poly-count for some hair types is provided by the Select Random Strands button. Here is another hair with an impressive footprint:<br /><br />Verts: 114074, Edges: 167685, Faces: 55553<br /><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-PdBe0-s0W9o/WNCi6Dwt88I/AAAAAAAAAb0/W4CUKbyruJgLalSJnDGz4H95lbgSqibwgCLcB/s1600/hide-cap.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="147" src="https://2.bp.blogspot.com/-PdBe0-s0W9o/WNCi6Dwt88I/AAAAAAAAAb0/W4CUKbyruJgLalSJnDGz4H95lbgSqibwgCLcB/s320/hide-cap.png" width="320" /></a></div>Not all of the strands are really needed, but it would difficult to select a suitable set manually.<br /><br />We don't want the skull cap to be selected, so we hide it (select one vertex on the skull, use ctrl-L to select connected vertices, and H to hide).<br /><br /><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-6iMD1-ZaLlY/WNCj2-cwBcI/AAAAAAAAAcA/TE_RwGuYotEbjwGTp30GEfBHspdQ8qTIwCLcB/s1600/select-random.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="140" src="https://1.bp.blogspot.com/-6iMD1-ZaLlY/WNCj2-cwBcI/AAAAAAAAAcA/TE_RwGuYotEbjwGTp30GEfBHspdQ8qTIwCLcB/s320/select-random.png" width="320" /></a></div>Select Random Strands to make the selection, and then press X to delete the verts. The Keep Fraction slider was set to the default 50% in this case. There is some tendency to baldness in edit mode, but that is because the skull cap is still hidden. The render looks quite ok but the footprint has been reduced to<br /><br />Verts: 56116, Edges: 82748, Faces: 27574<br /><br /><br /><br /><br /><br /><br /><br /><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div>Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-33642590001987859282017-02-19T00:53:00.000-08:002017-02-22T00:49:49.126-08:00DAZ Importer version 1.1.<div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-n78BmNkStQA/WKlePHXhUYI/AAAAAAAAAXo/qI5T13cfsYQF6AbSXcrFPy5M5Mioyh5JgCK4B/s1600/nomads.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="222" src="https://1.bp.blogspot.com/-n78BmNkStQA/WKlePHXhUYI/AAAAAAAAAXo/qI5T13cfsYQF6AbSXcrFPy5M5Mioyh5JgCK4B/s400/nomads.png" width="400" /></a></div><br />A new version of the DAZ Importer to Blender is finally available. The are many improvements compared to version 1.0, including<br /><ul><li>Multiple instances of the same asset are treated as different objects.</li><li>Object transformations have been improved.</li><li>Roll angles are chosen to make X the main bend axis, necessary for the MHX and Rigify rigs.</li><li>Improved material handling, utilising DAZ Studio materials.</li><li>Experimental import only using information in DAZ files.</li><li>and many, many bug fixes. </li></ul><br /><b>Download link</b>: <a href="https://www.dropbox.com/s/i4aoh578u6ss2hz/import-daz-v1.1-20170222.zip">https://www.dropbox.com/s/i4aoh578u6ss2hz/import-daz-v1.1-20170222.zip</a><br /><br /><b>Instructions</b>:<br /><ol><li>Save the zip file somewhere on your computer.</li><li>In Blender, go to File > User Preferences > Add-ons</li><li>Press Install From File... and select the zip file.</li><li>Enable the DAZ importer.</li></ol>For more information see: <a href="http://diffeomorphic.blogspot.se/p/daz-importer-version-11.html">http://diffeomorphic.blogspot.se/p/daz-importer-version-11.html</a><br /><br /><br /><br /><a href="http://4.bp.blogspot.com/-yPrFMhtQhbw/WKlg5RBbKvI/AAAAAAAAAX0/sks09f2zFtUCmipyfBwrkGJThBXBzmkswCK4B/s1600/aiko-cycles.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://4.bp.blogspot.com/-yPrFMhtQhbw/WKlg5RBbKvI/AAAAAAAAAX0/sks09f2zFtUCmipyfBwrkGJThBXBzmkswCK4B/s200/aiko-cycles.png" width="200" /></a><a href="http://2.bp.blogspot.com/-H0vfuAk9aZ8/WKlkRc9RTyI/AAAAAAAAAYA/nf2UllPEzqwM4XjADfK0XQwKRLmLFYsLgCK4B/s1600/0003.png" imageanchor="1"><img border="0" height="320" src="https://2.bp.blogspot.com/-H0vfuAk9aZ8/WKlkRc9RTyI/AAAAAAAAAYA/nf2UllPEzqwM4XjADfK0XQwKRLmLFYsLgCK4B/s320/0003.png" width="320" /></a><br /><br /><br />And here I added a quick animation with MakeWalk.<br /><br /><iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/le9bFZ_CuAI" width="560"></iframe>Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-14663737993115516422016-09-27T08:11:00.000-07:002016-09-27T08:16:25.371-07:00What's Missing in Quantum Gravity IV: ObjectionsToday I sum up some of the more obvious objections to the arguments presented in the previous posts, and explain why these objections are not relevant.<br /><br /><h4>1. The diffeomorphism algebra in $d$ dimensions has no <u>central</u> extension at all when $d>1$</h4>This is correct, and would appear to be fatal blow to the existence of a multidimensional Virasoro algebra since the the ordinary Virasoro algebra is precisely the central extension of the diffeomorphism algebra on the circle. However, we saw in the <a href="http://diffeomorphic.blogspot.se/2016/09/whats-missing-in-quantum-gravity-iii.html">previous post</a> that the Virasoro extension in higher dimensions is not central, i.e. it does not commute with all diffeomorphisms. The Virasoro algebra in $d$ dimensions is essentially an extension of the diffeomorphism algebra by its module of closed $(d-1)$-forms. When $d=1$, a closed zero-form is a constant function, and the extension is a constant. In higher dimensions, a closed $(d-1)$-form does not commute with diffeomorphisms, but we still have a well-defined Lie algebra extension, not just a central one.<br /><br /><h4>2. <u>In QFT</u>, there are no diff anomalies at all in four dimensions</h4>Again this statement is correct and apparently fatal, because an extension of the diffeomorphism algebra is a diff anomaly by definition. However, the caveat is the phrase "in QFT". Virasoro-like extensions of the diffeomorphism algebra in four dimensions certainly exist, but they cannot arise within the framework of QFT. The reason is simple: as we saw in the<a href="http://diffeomorphic.blogspot.se/2016/09/whats-missing-in-quantum-gravity-iii.html"> previous post</a>, the extension is a functional of the observer's trajectory $q^\mu(t)$, and since the observer does not explicitly appear in QFT, such a functional can not be written down within that framework. To formulate the relevant anomalies, a more general framework which explicitly involves the observer is needed.<br /><br /><h4>3. Diff anomalies are gauge anomalies which are always inconsistent</h4>In contrast to the first two objections, this statement is blatantly wrong. Counterexample: the free subcritical string, which according to the no-ghost theorem can be consistently quantized despite its conformal gauge anomaly. Of course, this does not mean that every kind of gauge anomaly can be rendered consistent; the free supercritical string and the interacting subcritical string are examples where the conformal anomaly leads to negative-norm states in the physical spectrum and hence to inconsistency. But the crucial condition is unitarity rather than triviality.<br /><br />A necessary condition for a gauge anomaly to be consistent is clearly that the algebra of anomalous gauge transformation possesses non-trivial unitary representations. The Mickelsson-Faddeev (MF) algebra, which describes gauge anomalies in Yang-Mills theory, fails this criterion. It was shown by <a href="https://projecteuclid.org/euclid.cmp/1104178985">Pickrell</a> a long time ago that the MF algebra has no "nice" non-trivial unitary representations at all. Therefore, Nature must abhor this kind of gauge anomaly, which of course is in agreement with experiments; gauge anomalies in the Standard Model do cancel. But this argument has no bearing on the situation where the algebra of gauge transformations does possess "nice" unitary representations.<br /><br /><h4>4. Gauge symmetries are redundancies of the description rather than proper symmetries</h4>This is only true classically, and quantum-mechanically in the absense of a gauge anomaly. A gauge anomaly converts a classical gauge symmetry into a ordinary quantum symmetry, which acts on the Hilbert space rather than reducing it. As an example we consider again the free string in $d$ dimensions. Classically, the physical dofs are the $d-2$ transverse modes, and this remains true in the critical case. In the subcritical case, however, there are $d-1$ physical dofs, because in addition to the transverse modes the longitudinal mode has become physical; time-like vibrations remain unphysical.<br /><br /><h4>5. There are no local observables in Quantum Gravity</h4>This is essentially the same objection as the previous one, and it assumes that there are no diff anomalies. There can be no local observables in a theory with proper diffeomorphism symmetry because the centerless Virasoro algebra has no nontrivial unitary representations. If the diffeomorphism algebra acquires a nontrivial extension upon quantization, there is no reason why local observables should not exist.<br /><br />Note that the same argument applies to Conformal Field Theory (CFT). There are no local observables in a theory with infinite conformal symmetry, but that is not a problem in CFT because the relevant symmetry is not infinite conformal but Virasoro; the central charge makes a difference.Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-43926478659062654912016-09-17T07:19:00.001-07:002016-09-17T07:25:10.037-07:00Barefoot dancerSince the latest release of the DAZ-Blender importer I have mainly been tweaking materials. It is pretty important that the importer produces attractive materials automatically, because DAZ meshes contain lots of materials, and modifying all of them manually involves a lot of work. E.g., I think that a human uses some seventeen different materials for different parts of the body. This has some advantages in DAZ Studio, because you can easily add makeup by modifying the lip, eyelash, fingernail or toenail materials, but having so many materials does complicate editing afterwards in Blender<br /><br />As a benchmark I will use the barefoot dancer is a standard product that ships (or used to ship, at least) with DAZ Studio. You can find pictures of her with <a href="https://www.google.se/search?q=daz3d+barefoot+dancer&client=firefox-b&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwic8oWlwpbPAhUhb5oKHTaMAlwQsAQIOg&biw=1920&bih=943">Google</a>, but since I don't know if it is legal to include other people's art on your blog (it is at least impolite), you have to look them up yourself.<br /><br />So here is what I did. First I created to DAZ Studio (.duf) files, one containing the character in rest pose and the other the stage (Shaded haven). Then I created two Blender files. In the first I imported the stage, which required some tweaking because the importer does not always get object transformations right (working on this). Into the other I imported the character and merged the rigs (character, hair and each piece of clothing have separate rigs). Actually, every import was made twice, once with Blender Render being the render engine, in order to get the Blender Internal (BI) materials, and once with Cycles to get Cycles materials.<br /><br />Finally, the set file was linked into the character file and the animation was loaded. I also loaded expression and chose something suitable, and created a simple three-point lighting setup. Here is a render using Blender Internal.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-7zM4TiZNk5I/V91JBUD_v6I/AAAAAAAAAJo/jC_-l4eOrEM16wYaChOkRYu3MEfxLVCbQCLcB/s1600/barefoot-bi.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-7zM4TiZNk5I/V91JBUD_v6I/AAAAAAAAAJo/jC_-l4eOrEM16wYaChOkRYu3MEfxLVCbQCLcB/s320/barefoot-bi.png" width="320" /></a></div>If you change the render engine to Cycles, the importer creates a Cycles material instead. Now, I have never really used Cycles and I don't understand how to control lights in it - it seems like most of the lighting comes from a world surface light whereas the actual lamps play a very marginal role. But even if the lighting is extremely dull, I think the materials look reasonably good.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-VmDTSgeiwSo/V91LOhPawoI/AAAAAAAAAJw/x5D-Nho9JUwrnrBbUjfTejvKCr95BBIKgCLcB/s1600/barefoot-cycles.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://3.bp.blogspot.com/-VmDTSgeiwSo/V91LOhPawoI/AAAAAAAAAJw/x5D-Nho9JUwrnrBbUjfTejvKCr95BBIKgCLcB/s320/barefoot-cycles.png" width="320" /></a></div><br />The renders were made with the unstable version of the DAZ Importer, which can be downloaded from<br /><a href="https://bitbucket.org/Diffeomorphic/import-daz/downloads">https://bitbucket.org/Diffeomorphic/import-daz/downloads</a>.<br /><br /><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"> </div><br />Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-90197032499675955512016-09-14T06:15:00.001-07:002016-09-14T06:27:43.422-07:00What's Missing in Quantum Gravity III: The Connection Between Locality and Observer DependenceIn the two first posts (<a href="http://diffeomorphic.blogspot.se/2016/09/whats-missing-in-quantum-gravity-i.html">1</a>, <a href="http://diffeomorphic.blogspot.se/2016/09/whats-missing-in-quantum-gravity-ii_11.html">2</a>) in this series I argued that the missing ingredients in Quantum Gravity (QG) are locality and observer dependence, respectively. Now it is time to make the connection between these concepts. But before making this connection at the end of this post, we need some rather massive calculations. The main reference is my <a href="http://link.springer.com/article/10.1007/s002200000280">CMP paper</a> (essentially the same as <a href="http://arxiv.org/abs/math-ph/9810003">arXiv:math-ph/9810003</a>). That paper is somewhat difficult to follow, even for myself, so I recently updated it using more standard notation, <a href="http://arxiv.org/abs/1502.07760">arXiv:1502.07760</a>.<br /><br />Local operators in QG are only possible if the spacetime diffeomorphism algebra in $d$ dimensions, also known as the Lie algebra of vector fields $vect(d)$, acquires an extension upon quantization. This turns $vect(d)$ into the Virasoro algebra in $d$ dimensions, $Vir(d)$. In particular, $Vir(1)$ is the ordinary Virasoro algebra, the central extension of the algebra of vector fields on the circle, $vect(1)$. $Vir(1)$ is also a crucial ingredient in Conformal Field Theory (CFT), which successfully describes critical phenomena in two dimensions.<br /><br />There is a simple recipe for constructing off-shell representations of $Vir(1)$:<br />1. Start with classical densities, which in the context of CFT are called primary fields.<br />2. Introduce canonical momenta for all fields.<br />3. Introduce a vacuum state which annihilates all negative-frequency operators, both the fields and their momenta.<br />4. Normal order to remove an infinite vacuum energy.<br /><br />The last step introduces a central charge, turning $vect(1)$ into $Vir(1)$. <br /><br />Intuitively one could try to duplicate these steps in higher dimensions, but that does not work. The reason is that normal ordering introduces an unrestricted sum over transverse directions, which makes the putative central extension infinite and thus meaningless. Instead we introduce a new step after the first one. The recipe now reads:<br /><br />1. Start with classical tensor densities.<br />2. Expand all fields in a Taylor series around a privileged curve in $d$-dimensional spacetime, and truncate the Taylor series at order $p$.<br />3. Introduce canonical momenta for the Taylor data, which include both the Taylor coefficients and the points on the selected curve.<br />4. Introduce a vacuum state which annihiles negative frequency states.<br />5. Normal order to remove an infinite vacuum energy.<br /><br />A $p$-jet is locally the same thing as a Taylor series truncated at order $p$, and we will use the two terms synonymously. Since the space of $p$-jets is finite-dimensional, the space of trajectories therein is spanned by finitely many functions of a single variable, which is precisely the situation where normal ordering can be done without introducing infinities coming from transverse directions.<br /><br />Locally, a vector field is of the form $\xi^\mu(x) \partial_\mu$, where $x = (x^\mu)$ is a point in $d$-dimensional space and $\partial_\mu = \partial/\partial x^\mu$ the corresponding partial derivative. The bracket of two vectors fields reads<br />\[<br />[\xi, \eta] = \xi^\mu \partial_\mu \eta^\nu \partial_\nu -<br />\eta^\nu \partial_\nu \xi^\mu \partial_\mu.<br />\]<br />$vect(d)$ is defined by the brackets<br />\[<br />[{\cal L}_\xi, {\cal L}_\eta] = {\cal L}_{[\xi,\eta]}.<br />\]<br />The extension $Vir(d)$ depends on two parameters $c_1$ and $c_2$, both of which reduce to the central charge in one dimension:<br />\[<br />[{\cal L}_\xi, {\cal L}_\eta] = {\cal L}_{[\xi,\eta]} +<br />\frac{1}{2\pi i} \oint dt\ \dot q^\rho(t) \Big(<br />c_1 \partial_\rho \partial_\nu \xi^\mu(q(t)) \partial_\mu \eta^\nu(q(t)) \\<br />\qquad\qquad + c_2 \partial_\rho \partial_\mu \xi^\mu(q(t)) \partial_\nu \eta^\nu(q(t)) \Big), \\<br />{[}{\cal L}_\xi, q^\mu(t)] = \xi^\mu(q(t)), \\<br />{[}q^\mu(t), q^\nu(t')] = 0.<br />\]<br />In particular when $d=1$, vectors only have a single component and we can ignore the spacetime indices. The extension then reduces to<br />\[<br />\frac{1}{2\pi i} \oint dt\ \dot q(t) \xi^{\prime\prime}(q(t)) \eta^\prime(q(t)) <br />= \frac{1}{2\pi i} \oint dq\ \xi^{\prime\prime}(q) \eta^\prime(q),<br />\]<br />which has the ordinary Virasoro form. The terms proportional to $c_1$ and $c_2$ where first written down by <a href="https://projecteuclid.org/download/pdf_1/euclid.cmp/1104254598">Rao and Moody</a> and myself, respectively.<br /><br />To carry out the construction explicitly for tensor-valued $p$-jets is quite cumbersome, but in the special case that we deal with $-1$-jets (which depend only on the expansion point, and not on any Taylor coefficients at all), formulas become manageable. Consider the Heisenberg algebra defined by the brackets<br />\[<br />[q^\mu, p_\nu] = i\delta^\mu_\nu, \qquad<br />[q^\mu, q^\nu] = [p_\mu, p_\nu] = 0.<br />\]<br />Clearly we can embed $vect(d)$ into the universal enveloping algebra of this Heisenberg algebra as follows:<br />\[<br />{\cal L}_\xi = i\xi^\mu(q) p_\mu.<br />\]<br />This embedding immediately yields a representation of $vect(d)$ on $C^\infty(q)$, the space of smooth functions of $q$, and also on the dual space $C^\infty(p)$. However, neither of the representations are particularly interesting because they do not exhibit any extension. However, with a slight modification of the construction, we immedately obtain something interesting. Consider the infinite-dimensional Heisenberg algebra where everything also depends on an extra variable $t$, which lives on the circle. It is defined by the brackets<br />\[<br />[q^\mu(t), p_\nu(t')] = i\delta^\mu_\nu \delta(t-t'), \qquad<br />[q^\mu(t), q^\nu(t')] = [p_\mu(t), p_\nu(t')] = 0.<br />\]<br />The new embedding of $vect(d)$ reads<br />\[<br />{\cal L}_\xi = i \oint dt\ \xi^\mu(q(t)) p_\mu(t).<br />\]<br />This operator acts on the space $C^\infty[q(t)]$ of smooth functionals of $q(t)$, and, after moving the momentum operator to the left, on the dual space $C^\infty[p(t)]$. Neither of these representations yields any extension. <br /><br />However, there is a more physical way to split the Heisenberg algebra into creation and annihilation operators. Since the oscillators depend on a circle parameter $t$, they can be expanded in a Fourier series, and we postulate that the components of negative frequency annihilate the vacuum state. If $p^>_\mu(t)$ and $p^<_\mu(t)$ denote the positive and negative frequency parts of $p_\mu(t)$, respectively, and analogously for $q^\mu(t)$, the state space can be identified with $C^\infty[q_>(t), p^>(t)]$. We still have a problem with a infinite vacuum energy, but this can be taken care of by normal ordering. Hence we replace the expression for ${\cal L}_\xi$ by<br />\[<br />{\cal L}_\xi = i \oint dt\ :\xi^\mu(q(t)) p_\mu(t): \\<br />\equiv i \oint dt\ \Big(\xi^\mu(q(t)) p^<_\mu(t) + p^>_\mu(t) \xi^\mu(q(t)) \Big).<br />\]<br />This expression satisfies $Vir(d)$ with parameters $c_1 = 1$, $c_2 = 0$.<br /><br />Finally, we can make the connection between locality and observer dependence. The off-shell representations of $Vir(1)$ act on quantized fields on the circle, and may therefore be viewed as one-dimensional Quantum Field Theory (QFT). In higher dimensions $Vir(d)$ act on quantized $p$-jet trajectories instead, so the theory deserves the name Quantum Jet Theory (QJT). $p$-jets (Taylor series) do not only depend on the function being expanded but also on the choice of expansion point, i.e. the observer's position.<br /><br />The following diagram summarizes the argument:<br /><br />Locality => Virasoro extension => $p$-jets => observer dependence.Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-15236259547275263042016-09-11T22:52:00.000-07:002016-09-17T06:24:18.192-07:00What's Missing in Quantum Gravity II: Observer DependenceIn the <a href="http://diffeomorphic.blogspot.se/2016/09/whats-missing-in-quantum-gravity-i.html">previous post</a> I explained why locality in Quantum Gravity (QG) requires that the spacetime diffeomorphism group acquires an extension upon quantization. Now I will turn to a more physical viewpoint and argue that what also is missing in all approaches to QG is a physical observer. At first sight it may not be obvious that the two concepts have anything to do with each other, but they are in fact closely related which I will discuss in a later post. However, for the time being I will content myself with the following trivial observation:<br /><br /><i>Every real experiment is an interaction between a system and an observer, and the outcome depends on the physical properties of both. In particular, the result depends on the observer's mass.</i><br /><br />This may seem as an innocuous observation, until you realize that neither General Relativity (GR) nor Quantum Field Theory (QFT) make predictions that depend on the observer's mass. So clearly there must be a more general, observer-dependent, theory that reduces to GR and QFT in the appropriate limits. A little thought reveals that these limits are:<br /><ul><li>In GR, the observer's heavy mass is assumed to be zero, so the observer does not disturb the fields.</li><li>In QFT, the observer's inert mass is assumed to be infinite, so the observer knows where he is at all times. In particular, the observer's position and velocity at equal times commute.</li></ul>Since the equivalence principle states that the heavy and inert masses are always the same, we see that GR and QFT tacitly make incompatible assumptions about the observer's mass. It then comes as no surprise that the theories cannot be combined.<br /><br />The assumption about the small heavy mass is very intuitive: if the observer had a large heavy mass, he would immediately collapse into a black hole, which is not what happens in a typical experiment. However, the assumption about the infinite inert mass requires some more explanation. Here my philosophy is completely operational: in order to know something, you must measure it. In particular, in order to know where he is, the observer must measure his position, e.g. with a GPS receiver. In theory, that can be done with arbitrary accuracy. However, in order to know where he will be in the future, the observer must also be able to measure his velocity at the same time, but Heisenberg's uncertainty principle tells us that there is a limit to the precision with which the position and the momentum can be simultaneously known.<br /><br />More precisely, let $\Delta x$ and $\Delta v$ denote the uncertainties in the observer's position and velocity, and assume that momentum and velocity are related by $p = Mv$, where $M$ is the observer's mass. Then<br />\[<br />\Delta x \cdot \Delta v \sim \hbar/M,<br />\]<br />where $\hbar$ is Planck's constant. Hence there are only two situations in which both the observer's position and velocity can be known arbitrarily well:<br /><ul><li>If $\hbar = 0$, i.e. in classical physics including GR. In this limit we can assume $M = 0$.</li><li>If $M = \infty$, which only makes sense if gravity is turned off. In this limit we have QFT in flat space.</li></ul>In these two limits we can use field theory. In the general situation where $\hbar/M \neq 0$, field theory breaks down and QG must be a more general type of theory which incorporates a physical observer explicitly.<br /><br />An analogous statement can be made about other interactions than gravity: field theory assumes that the observer's charge is zero and his inert mass is infinite. However, this double limit does not pose a problem for non-gravitational interactions, because charge and mass are unrelated. So even if non-gravitational physics depends on the observer's charge in principle, this dependence is merely an experimental nuisance that can be eliminated. In gravity, where charge and mass are the same, this nuisance becomes a conceptual problem.<br /><br /><a href="http://arxiv.org/abs/gr-qc/0110035">Rovelli </a>makes the distinction between two types of observables: partial observables, which can be measured but not predicted, and complete observables, whose time evolution can be predicted by the theory and which are subject to quantum fluctuations. In Quantum Mechanics, there are two types of partial observables: $A$, the reading of the detector, and $t$, time measured by a clock, which combine into the complete observable $A(t)$. In QFT, there is a third type of partial observable: $x$, the position measured e.g. by a GPS receiver, and the complete observables are of the form $A(x,t)$. However, beneath this expression lies an unphysical assumption: that the pair $(x,t)$ is a partial observable that can only be measured but not predicted. A real observer obeys his own set of equations of motion, so his position at later times $x(t)$ can be predicted. Let us now change notation and call this observable $q(t)$ instead, because $x$ will be reused below.<br /><br />In a physically correct treatment, we combine the three partial observables of QFT into two complete observables: $A(t)$ and $q(t)$, the readings of the detector and GPS receiver at a certain tick of the clock. However, we immediately notice that a lot of information is gone: we no longer sample data throughout spacetime but only along the observer's trajectory. Fortunately, this is not as disastrous at it might seem at first glance, because the available local data includes not only the values of the fields A but also their derivatives $d^m A/dx^m$ up to arbitrary order. We can assemble the local complete observables into a Taylor series,<br />\[<br />A(x,t) = \sum_m \frac{1}{m!} \frac{d^m A}{dx^m}(t) (x-q(t))^m<br />\]<br />This formula looks one-dimensional, but with multi-index notation it makes sense in higher dimensions as well. To the extent that we can identify an infinite Taylor series with the field itself, the original field has been recovered entirely, but with a twist: the Taylor series does not only depend on the field, but also on the expansion point $q(t)$, an operator which we identify with the observer's position.<br /><br />In <a href="http://diffeomorphic.blogspot.se/2016/09/whats-missing-in-quantum-gravity-iii.html">the next installment</a> in this series this expression will be used to make the connection to locality and the multi-dimensional Virasoro algebra from <a href="http://diffeomorphic.blogspot.se/2016/09/whats-missing-in-quantum-gravity-i.html">the previous post</a>.Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com3tag:blogger.com,1999:blog-3702197589827003408.post-32134760448292872652016-09-09T07:50:00.000-07:002016-09-14T06:25:12.372-07:00What's missing in Quantum Gravity I: LocalityI'm planning to put up some pretty nice renders of characters imported from DAZ studio into Blender, but before doing that I will write about something that I have thought about for a long time and think that I have some rather unique insights about (and something that motivates the name of this blog): how to construct a quantum theory of gravity. For a more exhaustive discussion of the topic in this and <a href="http://diffeomorphic.blogspot.se/2016/09/whats-missing-in-quantum-gravity-ii_11.html">the next post</a>, see <a href="http://arxiv.org/abs/1407.6378">arXiv:1407.6378 [gr-qc]</a>.<br /><br />In the beginning of the previous century, two great theories were found that describe all of physics: Einstein's General Relativity (GR), which describes gravity, and Quantum Theory (including Quantum Mechanics and Quantum Field Theory (QFT)), which describes everything else. The problem is that these theories seem to be mutually incompatible. But we know that Nature exists and hence cannot be inconsistent, so a consistent theory of Quantum Gravity (QG) has to exist, and it must reduce to GR and QFT in appropriate limits.<br /><br />For almost a century many great minds have tried to solve this conundrum. The most popular approaches in recent decades have been string theory and, to a lesser extent, loop quantum gravity. However, these and other approaches all have problems of their own, especially since the LHC recently has ruled out supersymmetry beyond reasonable doubt (which, incidentally, is not the same thing as beyond every doubt).<br /><br />My own proposal is to go back to basics, and simple postulate that QG combines the main properties of GR and QFT: gravity, quantum theory, and locality.<br /><br />Now, this may seem as a very natural and innocent assumption, but it is in fact very controversial. The reason is that there is a well-known theorem stating that there are no local observables at all in QG, <i><b>unless </b></i>classical and quantum gravity have different sets of gauge symmetries. Actually, if you have seen this statement before, it was certainly without the caveat, but it must be mentioned because it is the weak spot of the no-go theorem. In order to prove this, one assumes that the group of all spacetime diffeomorphisms, which is the gauge symmetry of classical GR, remains a gauge symmetry after quantization.<br /><br />So, we need something that converts spacetime diffeomorphisms from a classical gauge symmetry to an ordinary quantum symmetry, which acts on the Hilbert space rather than reducing it. This something is called an extension. It is well known that the diffeomorphism algebra (the infinitesimal version of the diffeomorphism group) on the circle admits a central extension called the Virasoro algebra. This is a celebrated part of modern theoretical physics. It first appeared in string theory, but later found an experimentally successful application in condensed matter, in the theory of two-dimensional phase transition.<br /><br />So the diffeomorphism algebra in one dimension has an extension, but we know that spacetime has four dimensions (at least). So we need a multi-dimensional Virasoro algebra, which is a nontrivial extension of the diffeomorphism algebra in higher (and in particular four) dimensions. There are several arguments why such an extension cannot exist, and I will address those in a later post, but exists it does. In fact, there are even two of them, that were discovered 25 years ago by Rao and Moody and myself, respectively.Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-42060973637384119212016-08-20T18:28:00.002-07:002016-09-09T09:18:16.230-07:00DAZ Importer<div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-Q8pnOyeQeu4/V7kE271pC1I/AAAAAAAAAJY/AkhmmF6IyBkPZFEd9x43K18CW0On_ZTKQCLcB/s1600/Daz%2Bimporter.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="256" src="https://4.bp.blogspot.com/-Q8pnOyeQeu4/V7kE271pC1I/AAAAAAAAAJY/AkhmmF6IyBkPZFEd9x43K18CW0On_ZTKQCLcB/s320/Daz%2Bimporter.png" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"></div><br />My 3D app is <a href="https://www.blender.org/">Blender</a>, but I have played with <a href="https://www.daz3d.com/">DAZ Studio</a> for quite some time, and found that it is a quite capable character creator. Since I have previously done something similar for the <a href="http://www.makehuman.org/">MakeHuman</a> project, I wrote a Python script that imports native DAZ files (with file extensions .duf or .dsf) into Blender. In fact, the script is quite old and I have been using it privately for a long time, but recently I decided that it was time to complete it. The primary reason for writing this script is that I want to use it myself, but if somebody is interested it is now available for download.<br /><br />The script repository is located at <a href="https://bitbucket.org/Diffeomorphic/import-daz">https://bitbucket.org/Diffeomorphic/import-daz</a><br /><br />To download a zip file with the development version, go to <a href="https://bitbucket.org/Diffeomorphic/import-daz/downloads">https://bitbucket.org/Diffeomorphic/import-daz/downloads.</a><br /><br />There is also some documentation about the intended use at <a href="http://diffeomorphic.blogspot.se/p/daz-importer.html">http://diffeomorphic.blogspot.se/p/daz-importer.html</a>.<br /><br />All assets needed to make the picture above were imported from DAZ Studio: the characters, the clothes, the poses, and the environment. The only manual intervention was to set up the lighting and make some minor tweaks to the woman's pose.<br /><br /><br />Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0tag:blogger.com,1999:blog-3702197589827003408.post-73587877134920304772016-08-14T09:51:00.001-07:002016-09-09T09:17:58.833-07:00Hello WorldDiffeomorphic is my new blog where I will collect my thoughts on physics, 3D graphics, history, languages, and other stuff that might interest me. Mostly but not exclusively in English.Thomas Larssonhttps://plus.google.com/105279750273931817218noreply@blogger.com0