-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
3 changed files
with
161 additions
and
149 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,19 +1,19 @@ | ||
# Develop Help | ||
# Developer Help | ||
|
||
## Encoding System | ||
|
||
The core of this dumper, `obj_export.cpp` use different encoding processing strategy with the operating system due to some feature implementations. There are the detail of this core's mechanism. | ||
## Basic Steps | ||
|
||
Virtools use multibyte encoding system related to current system. Stored CKObject name is rely on document's author's encoding(code page). | ||
1. First we create an instance of `ExportSettingDialog`, open a dialog and order user input export settings. Dialog read config manager settings when loading, and save settings to config manager after user click OK and input has been validated. | ||
1. Fetch `ExportSetting` from dialog, create `ExportLayoutWeaver` instance and send into it. `ExportLayoutWeaver` will collect all 3D objects, meshes, materials and textures exported and give them an unique name according to `ExportSetting`. | ||
1. Create `ObjExport` instance and fetch collected infomations in `ExportLayoutWeaver` to do read export. `ObjExport` will create essential files and write `ExportLayoutWeaver` collected infomations into it. | ||
|
||
For model name, we call `CKObject.GetName()` first, then do some operations(name prefix and eliminating non-ASCII char) without considering this name's encoding(`obj_export::GenCKObjectName` done). Then, processed value will be delivered to `obj_export::GenObjMtlName` to generate the name which will be written in file with proper encoding. Also, this value will be transported to `obj_export::OpenObjMtlFile` which convert value into `wchar_t` type and opening corresponding model files via `_wfopen`. | ||
## Encoding System | ||
|
||
For texture file path, `obj_export::GenCKTextureName` generated the filename of texture file with `wchar_t` type first. Then `GenCKTextureName4File` generated filename used in model files. `CopyTextureFile` also use returned value to saving texture file. The detail is that call `CKTexture.SaveImage()` first and save texture file with proper file suffix(due to Virtools use file extension name to recognize the format of saved files) into temp folder. Then call `MoveFileW` and use `wchar_t` path value to move it into correct path. The reason why use this non-straight method is that `CKTexture.SaveImage()` do not support UTF8 encoding and also do not support `wchar_t` path. So we need a pure ASCII path to prevent any encoding problem. | ||
The object name encoding convertion is located in `ExportLayoutWeaver`. Virtools use multibyte encoding system related to current system. Stored CKObject name is rely on document's author's encoding (code page). However, the whole program use UTF8 as default encoding. Thus `ExportLayoutWeaver` will try to convert CKObject name encoded by multibyte encoding system, to UTF8 according to user given encoding strategy. | ||
|
||
Custom Encoding configuration only provide a chance to user that allow exporter to read multibyte string with correct encoding, otherwise exporter will assume this multibyte string is based on current Windows code page and process it directly. If Virtools composition contain character which can not be decoded in current Windows code page, exporter will throw unhandled exception. This is the problem of user, not the exporter, because user do not select correct encoding. In code, we assume that user know what they are doing. | ||
For texture file path, it is done in both `ExportLayoutWeaver` and `ObjExport`. First `ExportLayoutWeaver` will try get texture slot file name and convert it to UTF8 according to user given encoding. Then it is passed to `ObjExport`. In `ObjExport`, we firstly generate a ASCII-only name first (keep the same extension format). And use `CKTexture.SaveImage()` to save it in Windows Temp directory. The use Win32 function `MoveFileW` to move it from Windows Temp folder to destination directory and rename it to the actual texture name at the same time. The reason why use this non-straight method is that `CKTexture.SaveImage()` do not support UTF8 encoding and also do not support `wchar_t` path. So we need a pure ASCII path to prevent any encoding problem. | ||
|
||
## Bump version | ||
## Bump Version | ||
|
||
* Dialog left-bottom corner version string | ||
* About dialog in `vt_menu.cpp` | ||
* Macro `APP_VERSION` in `config_manager.cpp` if config file structure has been changed when bumping version. | ||
* Dialog left-bottom corner version string (all languages, current is English and Simplified Chinese). | ||
* About dialog string in string table (also for all languages). | ||
* Version indentifier passed to `YYCC::ConfigManager::CoreManager` constructor in `ConfigManager.cpp` if config file structure has been changed when bumping version. |
Oops, something went wrong.