基本上又是一个周六,为了保存kmz这么“简单“的问题,竟然耗费了好几天的时间
达到下面的功能:
1,绝对路径转为相对路径链接,并保存资源
2,数据可以保存在kmz文件中
3,不同模型引用的文件名可以避免重命名
为什么模型引用的纹理复杂,因为要考虑到以下几个方面:
1,路径的utf-8编码问题
经过测试google earth 输出的kmz模型里的编码都是utf-8字符串,如果有中文文件名,就会出现乱码,所以必须把utf-8字符串转为GB2312的。但是open collada的3dmax插件输出的dae模型中,文件路径使用的是utf-8字符串,但是把中文字符都变成%+字符的16进制。上一篇也提到,这里先要把这种转换后的字符串转为utf8字符串,最后再转换为gb2312字符串。
2,绝对路径和相对路径问题
这个问题是异常复杂,需要注意,纹理的相对路径是性对于模型位置的。
需要注意文件路径的 “file:”开头
注意路径分隔符 "/" 和 "/"
这次最后放弃了windows api的路径转换,完全自己实现了一些路径转换函数,也许效率不是很高的,但是能保证算法正确
而且自己的实现能够处理,一个文件相对另一个文件的路径,如c:/1.txt 相对 c:/2.txt s而windows api对于这种调用会失败。
3,模型中纹理引用和kml中模型的resourcemap
resourcemap里的target属性内的路径,实际上也是相对于模型文件来说的。
所以不仅仅要输出数据,而且要保存正确的resourcemap,否则下次打开依然出错。
4,文件重名问题,比如有两个模型分别引用了不同路径下的 1.jpg,当把这两个模型保存到一个kml中,那就必须处理1.jpg问题,幸好
有resourcemap,我的处理方式很简单,当发现冲突的时候会把第二个文件名修改为 _1.jpg