Lisias
Space Traveller Wanna-be
(put on Project, as it is becoming a new baby itself)
Hi.
Due some issues while hacking and animating meshes, I ended up writing a Mesh Lint tool in order to easily detect some common mistakes that happens while development that impairs performance.
Features:
DOWNLOAD: here. The current version is 0.4.1.2 Alpha.
SCREENSHOTS: Google Photos
mesh copy:
It is capable of saving meshes from memory, so it's now possible to fix problems, and not just detect them. A command to test the parser and the save feature is provided (mesh copy) - this will help me to detect any incompatible mesh (and write code to read it). The written meshes are formatted for easy human reading (for double checking), not to optimize size (future versions will handle this better).
mesh normalize:
The tool has also a quick and dirty mesh normalizing (mesh normalize) that, before copying the mesh, do the following actions:
Unused Materials and Textures are kept to avoid messing with modules that address them. For the same reason, the Groups are declared in the same order from the source mesh, as also Materials and Textures.
mesh rc:
A (still work in progress) Resource Compiler is currently available. The RC will compile a C++ header file on the OrbiterSDK subdir in the OUTOUT_DIR (or in the directory specified by the target option).
The RC can spit headers (and futurelly C++ source) in the following formats:
The OT header format has the option to generate headers using "#define" as in meshc, or by using "const" as in ssumeshc. Additionally, it's possible to use constexpr (still in tests) for who is willing to limit themselves to C++11 in exchange of somewhat better object code.
Also, a "split file format" is being cooked for the ssumeshc and OT code generation "const" styles, with the header holding only the externs declarations and a counterpart C++ source file with the constants definitions made external. The ssumeshc style file pair aims to be a drop-in replacement for the headers generated by the ssumeshc tool.
The OT header format generate symbols for all named groups, textures and materials using a prefixed format:
GRP_<meshname>_<grouplabel>
MAT_<meshname>_<materialname>
TEX_<meshname>_<texfilename>
For all file formats, the names are normalized to allow only alphanumeric characters and the "_" - all the rest is stripped out, with the exception of the " " that is converted to "_". Repeated symbols are appended by "_" following an incremental counter to avoid name collisions.
Also, if the LABEL tag is not found, the remark on the GEOM tag is used (i.e., everything after the ";", space trimmed, if present). Groups without labels and without remarks on the GEOM tag will be ignored.
The ssumeshc and the meshc formats follows their respective naming conventions, but adds name collision handling. Only groups are named.
Options for customizing the file format and content are currently being planned, but not sure if will be that useful.
As usual, the tool don't overwrite files. If a file already exists, a ".new" appended one is created. If it exists too, the tool aborts the current mesh in error.
mesh clean:
A extra command to delete the meshes from the --output dir is provided (mesh clean). Useful to safely substitute meshes processed by the tool in Test Beds. The clean command only works on the --output dir.
For example, the command sequence:
will delete all SR71*.msh and SR71*.msh.new files on the --output dir (and only these files), then will make normalized copies from these meshes from the root Orbiter into the --output one, and then will make a plain copy from the same files into .msh.new files so you can pinpoint failures if (or better, when) the normalizing breaks something.
mesh lint:
Here, a report summary for the full lint scan of my current Orbiter setup:
The full report is human friendly - but is also 50 Megabyte size on my machine, so I'm posting just the summary. Follows a sample from the full report:
And now also in XML format:
<...> was used to signal where I abbreviate the report.
The issues my lint currently catches are:
At least for me, "normalizing" the Texture filename is interesting because I'm "living" on a UNIX style box, running Orbiter inside WINE, and case matters here. People willing to run Orbiter on Linux machines would not need to run Orbiter from a loopback block device using a non-case sensitive filesystem. I'm pretty sure that a good portion of that TEX_NOT_FOUND issues is related to this on my box.
Since most of the issues I'm detecting don't necessarily bother Orbiter, I'm calling such issues... "Issues" and not errors.
Duplicated vertices, however, impairs performance and orphaned vertices wastes memory. I don't know if Orbiters sanitizes the laters, but if don't, they also waste CPU/GPU time as unused vertices gets animated for nothing.
In some cases, I manually found "double sided" surfaces on boxes or something like that, and half of that surfaces are never rendered no matter what (as they are inside the box). Such surfaces are also a waste of CPU/GPU time. I don't have a clue how to detect such cases, but it would be interesting to do so.
About surfaces, in some meshes I found surfaces where not all three vertices are different. Surfaces with 2 equal vertices degenerates to a line, and surfaces with 3 equal vertices degenerates to a point. Such surfaces are deleted when normalizing.
The lint also detects when the Texture/Material grouping is not optimal, as explained on 4.4 Performance Optimisation section, page 9 of 3dModel.pdf manual.
Final Considerations
But I still need some help here. If you can, please:
Both CLI and GUI interfaces are provided on the same package/executable.
A extensive help (but work in progress) is available by using the --help command line option. You also need to provide the Orbiter's root dir by using the command --root C:\Orbiter (or whatever your orbiter installation is). The help explains how to setup environment variables to make easier using the tool.
A good way for testing this tool is using a clone installation of Orbiter, setting the source one using the --root option and setting the target one using the --output option (the output is not checked). It's not advisable to use the same Orbiter installation for output, as this tool is in Alpha phase and will probably corrupt a mesh sooner or later. Anyway, the tool refuses to overwrite a existing mesh for the sake of safety - if a mesh with the same name already exists, it appends ".new" to the pathname. If a .new file already exists, the tool raises an exception for that mesh and process the next one.
Useful commands:
The "cli" specifier can be omitted. Currently its absence prints a message before processing in stdout, but other than that, the previous version's behaviourship is preserved. The "gui" specifier ignores the rest of the command line.
The --verbose <n> option can be omitted for a silent run.
One can use --verbose 3 for a more detailed debugging log, and --verbose 4 for a suicidal one (even I/O is logged).
Currently, the tool don't travel subdirectories recursively on Windows. I'll fix this soon (not sure when, I need to update my Windows box first).
KNOWN ISSUES:
HISTORY:
Hi.
Due some issues while hacking and animating meshes, I ended up writing a Mesh Lint tool in order to easily detect some common mistakes that happens while development that impairs performance.
Features:
- Tools for handling meshes, textures, scenarios (WIP) and configuration files (WIP).
- Lint : checking for errors and inconsistencies
- copy : convenient copying of artifacts between different Orbiter installations
- normalize : same than copy, but normalize (see below) the artifact on the process.
- clean : convenient clean out of artifacts. Nice for test beds.
- orphan : detects orphaned artifacts
- rc : Resource Compiler with multiple output formats.
- Powerful command line interface for automating tasks.
- Comprehensive reports in text (file and console) and XML (file only) formats
- Simple but effective Graphical User Interface.
DOWNLOAD: here. The current version is 0.4.1.2 Alpha.
SCREENSHOTS: Google Photos
mesh copy:
It is capable of saving meshes from memory, so it's now possible to fix problems, and not just detect them. A command to test the parser and the save feature is provided (mesh copy) - this will help me to detect any incompatible mesh (and write code to read it). The written meshes are formatted for easy human reading (for double checking), not to optimize size (future versions will handle this better).
mesh normalize:
The tool has also a quick and dirty mesh normalizing (mesh normalize) that, before copying the mesh, do the following actions:
- Rebuild each Group's geometry:
- Eliminate duplicated and orphaned vertices
- Eliminate duplicated and invalid Surfaces
- Reorder each surface vertex indices ascending or descending (depending of the clockwiseness). This turn surpreendly easy to identify the clockwiseness of the surface, as the indices will be ordered all ascending or all descending. And no, this doesn't changes the clockwiseness of the surface.
- Fix the GEOM vertices and surfaces counts
- Fix the Materials count
- Fix the Materials names section
- Fix the Textures count
- Normalize the Texture pathname
Unused Materials and Textures are kept to avoid messing with modules that address them. For the same reason, the Groups are declared in the same order from the source mesh, as also Materials and Textures.
mesh rc:
A (still work in progress) Resource Compiler is currently available. The RC will compile a C++ header file on the OrbiterSDK subdir in the OUTOUT_DIR (or in the directory specified by the target option).
The RC can spit headers (and futurelly C++ source) in the following formats:
- Orbiter Tool's header format : mesh rc format=header <mask>
- using #define (default) : mesh rc format=header type=define <mask>
- using const : mesh rc format=header type=const <mask>
- using constexpr : mesh rc format=header type=constexpr <mask>
- Orbiter standard meshc format.
- using #define (only and default option) : mesh rc format=header [type=define] <mask>
- SSU enhanced ssumeshc format
- using const (default) : mesh rc format=header type=const <mask>
- using constexpr : mesh rc format=header type=constexpr <mask>
The OT header format has the option to generate headers using "#define" as in meshc, or by using "const" as in ssumeshc. Additionally, it's possible to use constexpr (still in tests) for who is willing to limit themselves to C++11 in exchange of somewhat better object code.
Also, a "split file format" is being cooked for the ssumeshc and OT code generation "const" styles, with the header holding only the externs declarations and a counterpart C++ source file with the constants definitions made external. The ssumeshc style file pair aims to be a drop-in replacement for the headers generated by the ssumeshc tool.
The OT header format generate symbols for all named groups, textures and materials using a prefixed format:
GRP_<meshname>_<grouplabel>
MAT_<meshname>_<materialname>
TEX_<meshname>_<texfilename>
For all file formats, the names are normalized to allow only alphanumeric characters and the "_" - all the rest is stripped out, with the exception of the " " that is converted to "_". Repeated symbols are appended by "_" following an incremental counter to avoid name collisions.
Also, if the LABEL tag is not found, the remark on the GEOM tag is used (i.e., everything after the ";", space trimmed, if present). Groups without labels and without remarks on the GEOM tag will be ignored.
The ssumeshc and the meshc formats follows their respective naming conventions, but adds name collision handling. Only groups are named.
Options for customizing the file format and content are currently being planned, but not sure if will be that useful.
As usual, the tool don't overwrite files. If a file already exists, a ".new" appended one is created. If it exists too, the tool aborts the current mesh in error.
mesh clean:
A extra command to delete the meshes from the --output dir is provided (mesh clean). Useful to safely substitute meshes processed by the tool in Test Beds. The clean command only works on the --output dir.
For example, the command sequence:
Code:
orbitertools --root c:\Orbiter\2010p1 --output c:\Orbiter\2010p1.test mesh clean SR71* SR71*.new
orbitertools --root c:\Orbiter\2010p1 --output c:\Orbiter\2010p1.test mesh normalize SR71*
orbitertools --root c:\Orbiter\2010p1 --output c:\Orbiter\2010p1.test mesh copy SR71*
will delete all SR71*.msh and SR71*.msh.new files on the --output dir (and only these files), then will make normalized copies from these meshes from the root Orbiter into the --output one, and then will make a plain copy from the same files into .msh.new files so you can pinpoint failures if (or better, when) the normalizing breaks something.
mesh lint:
Here, a report summary for the full lint scan of my current Orbiter setup:
Code:
MESHES SUMMARY
Counted 23 issues for TEX_HEADER_ABSENT.
Counted 1,509 issues for MAT_NOT_USED.
Counted 545 issues for TEX_NOT_USED.
Counted 996 issues for GRP_VTX_MATH_ERR.
Counted 820 issues for GRP_DUP_LABEL.
Counted 1 issues for MAT_EXTRA_DEF_FOUND.
Counted 5,994 issues for GRP_MAT_OUT_ORDER.
Counted 1,220,362 issues for GRP_DUP_VTX.
Counted 288 issues for GRP_DEPRECATED.
Counted 5 issues for GRP_EXTRA_FOUND.
Counted 12,589 issues for GRP_DUP_SRF.
Counted 6,527 issues for GRP_VTX_ORPHAN.
Counted 4 issues for MAT_LESS_NAMES.
Counted 4 issues for MSH_DEPRECATED.
Counted 5,214 issues for GRP_TEX_OUT_ORDER.
Counted 21 issues for GRP_NO_VTX.
Counted 6 issues for MSH_NO_MATERIALS.
Counted 6 issues for FATAL_PARSE.
Counted 3 issues for GRP_MAT_NDX_ERR.
Counted 2,402 issues for TEX_FN_NONORMAL.
Counted 12 issues for MSH_1STGRP_NO_TEX.
Counted 1,485 issues for TEX_NOT_FOUND.
Counted 8 issues for FATAL.
Counted 1 issues for MSH_NO_GROUPS.
Counted 21 issues for GRP_NO_SRF.
2,231 meshes processed, 1,993 of them with 1,258,846 issues.
MESH STATISTICS
Total meshes : 2,223
Total groups : 74,227
Total vertices : 17,340,724
Total surfaces : 14,520,440
Total materials : 14,613
Total textures : 7,101
Time elapsed : 1:17:03.426993 H:mm:ss.mmm
The full report is human friendly - but is also 50 Megabyte size on my machine, so I'm posting just the summary. Follows a sample from the full report:
Code:
Mesh:XRPayload/TankD2 has 296 issues:
Material name mismatch! Material Mat:#7(issItalian)@L:2,479, is named "issusaf" but "issItalian" is found at 6th position of the names structure.
Found 1 duplicated vertices on Group Grp:#1
1 duplicated vertices for Vtx#31@Line:37 [V#33@L:39]
Found 200 duplicated vertices on Group Grp:#2
2 duplicated vertices for Vtx#527@Line:600 [V#532@L:605, V#612@L:685]
1 duplicated vertices for Vtx#825@Line:898 [V#826@L:899]
1 duplicated vertices for Vtx#108@Line:181 [V#114@L:187]
2 duplicated vertices for Vtx#528@Line:601 [V#533@L:606, V#538@L:611]
<..........>
<..........>
Mesh:Mir2_Builder has 2 issues:
Group Grp:#11(Cylinder142) texture definition is out of optimum order. Regroup by Texture for better performance.
Texture Tex:#1(mir2_airhatch.dds)@Line:3,071 not found!
Mesh:UniversalCars/CargExploSat44Box has 2 issues:
Texture filename Tex:#1(UniversalCars\explosat44_Box.dds)@Line:199 is not normalized!
Texture Tex:#1(UniversalCars\explosat44_Box.dds)@Line:199 not found!
And now also in XML format:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<REPORT source="Orbiter Tools" version="0.3.1b alpha">
<ARTIFACT type="Mesh" name="Velcro/GEM60">
<ISSUE type="GRP_DUP_HDR" item="Grp:#1" index="1" >Found 20 duplicated vertices on Group Grp:#1</ISSUE>
<ISSUE type="GRP_DUP_VTX" item="Vtx#21@Line:26" index="21" line="26"> 1 duplicated vertices for Vtx#21@Line:26 [V#24@L:29]</ISSUE>
<ISSUE type="GRP_DUP_VTX" item="Vtx#9@Line:14" index="9" line="14"> 1 duplicated vertices for Vtx#9@Line:14 [V#12@L:17]</ISSUE>
<ISSUE type="GRP_DUP_VTX" item="Vtx#45@Line:50" index="45" line="50"> 1 duplicated vertices for Vtx#45@Line:50 [V#49@L:54]</ISSUE>
<.......>
</ARTIFACT>
</REPORT>
<...> was used to signal where I abbreviate the report.
The issues my lint currently catches are:
- Runtime problems
- FATAL_PARSER : Something serious that prevents the Parser to even try to read the mesh
- FATAL : I screwed up. Please report so I can fix the mess.
- Syntactically invalid meshes
- MAT_NAME_MISMATCH : The name of the Material on the name list does not match the name on the Material definition
- MAT_HEADER_ABSENT : MATERIALS tag not found - perhaps there are too much or too many data on the last group definition?
- MAT_EXTRA_NAME_FOUND : More Material names found than specified on the MATERIALS header
- MAT_EXTRA_DEF_FOUND : More Material definitions than specified on the MATERIALS header
- MAT_LESS_NAMES : There are fewer material names than specified on the MATERIALS header
- TAG_ALREADY_PARSED : Repeating structure on the Group definition (more than one LABEL, etc)
- VTX_EXTRA_IGNORED : More numbers on a vertex definition than expected
- CLR_EXTRA_IGNORED : More numbers on a color definition than expected
- TEX_HEADER_ABSENT : TEXTURES tag no found - perhaps there are too much materials?
- EMPTY_LINE_IGNORED : Nuff said. Empty lines as ignored, but since the specification don't mention them, a warning is issued.
- GRP_EXTRA_FOUND : More groups found than specified on the GROUPS header.
- GRP_LESS_FOUND : Less groups were found than specified on the GROUPS header.
- FILE_EXTRA_COMMENTS_IGNORED : Comments on the end of the file are discarded (as there's no syntactic structure to hook them).
- Mesh issues:
- MSH_DEPRECATED : Mesh uses a deprecated tag. It is preserved, but a warning is issued.
- MSH_NO_GROUPS : There're no groups on the mesh!
- MSH_NO_MATERIALS : There're no materials on the mesh!
- MSH_1STGRP_NO_MAT : The first group of the mesh don't define a Material.
- MSH_1STGRP_NO_TEX : The first group of the mesh don't define a Texture.
- Group issues:
- GRP_DEPRECATED : Group use a deprecated tag. It is preserved, but a warning is issued.
- GRP_NO_VTX : No vertices found for this group!
- GRP_NO_SRF : No surfaces found for this group!
- GRP_DUP_HDR : There're duplicated data on the group:
- GRP_DUP_VTX : Duplicated vertices
- GRP_DUP_SRF : Duplicated surfaces
- GRP_DUP_EQUIV_SRF : Equivalent surface are surfaces that are defined differently, but draws the same surface as a previously defined one, i.e. 1 2 3 and 2 3 1.
- GRP_DUP_LABEL : Group reuses a label from another Group.
- GRP_INVALID_SRF : A surface is invalid (two or more Vertices are equal - such surfaces degenerate to a line or point and are not visible)
- GRP_VTX_MATH_ERR : Presence of 1.#QNAN and +/- 1.#INF invalid iEEE float numbers
- QNANs and INFINITies are detected and a Issue emitted.
- Orbiter handles them, but values being divided by zero (positive and negative INF), and zero being divided by zero (NaN) is something that should not happens on a modelling tool, I'm right?
- GRP_VTX_ORPHAN : Group has orphans vertices, i.e., vertices are defined but not used by any surface.
- GRP_MAT_NDX_ERR : Group uses a material that is not defined on the Materiais section.
- GRP_MAT_OUT_ORDER : The group is not ordered by Material (inside a Texture series) in the mesh, leading to performance issues.
- GRP_TEX_NDX_ERR : Group uses a texture that is not defined on the Texture section.
- GRP_TEX_OUT_ORDER : The group is not ordered by Texture in the mesh, leading to performance issues.
- Material issues:
- MAT_MATH_ERR : Materials with invalid float values (NAN or INF).
- MAT_NOT_USED : Material defined but not used.
- Texture issues:
- TEX_FN_NONORMAL : Texture pathname cam be normalized (see below)
- TEX_FN_ABSOLUTE : A texture pathname is absolute, and not relative to the Orbiter's texture dir
- TEX_NOT_USED : Texture defined but not used
- TEX_NOT_FOUND : Texture file not found on the file system
- TEX_PATH_INVALID : Texture filename is invalid under the current OS. It's mutually exclusive with TEX_NOT_FOUND, but if a filename is invalid, it's obvious it is impossible to be on the file system.
At least for me, "normalizing" the Texture filename is interesting because I'm "living" on a UNIX style box, running Orbiter inside WINE, and case matters here. People willing to run Orbiter on Linux machines would not need to run Orbiter from a loopback block device using a non-case sensitive filesystem. I'm pretty sure that a good portion of that TEX_NOT_FOUND issues is related to this on my box.
Since most of the issues I'm detecting don't necessarily bother Orbiter, I'm calling such issues... "Issues" and not errors.
Duplicated vertices, however, impairs performance and orphaned vertices wastes memory. I don't know if Orbiters sanitizes the laters, but if don't, they also waste CPU/GPU time as unused vertices gets animated for nothing.
In some cases, I manually found "double sided" surfaces on boxes or something like that, and half of that surfaces are never rendered no matter what (as they are inside the box). Such surfaces are also a waste of CPU/GPU time. I don't have a clue how to detect such cases, but it would be interesting to do so.
About surfaces, in some meshes I found surfaces where not all three vertices are different. Surfaces with 2 equal vertices degenerates to a line, and surfaces with 3 equal vertices degenerates to a point. Such surfaces are deleted when normalizing.
The lint also detects when the Texture/Material grouping is not optimal, as explained on 4.4 Performance Optimisation section, page 9 of 3dModel.pdf manual.
Final Considerations
But I still need some help here. If you can, please:
- Suggest about further static analysis (or useful statistics) to be performed (calculated) by the tool.
- Suggest about faster algorithms to do the analysis (I'm going brute force)
- Suggest about further mesh optimizations that can be automated
- Large and/or potentially problematic meshes to be used on the tool as a test case
- Teach me how to embedded these tools into Blender, complementing the Orbiter Exporter.
- Suggest new features
Both CLI and GUI interfaces are provided on the same package/executable.
A extensive help (but work in progress) is available by using the --help command line option. You also need to provide the Orbiter's root dir by using the command --root C:\Orbiter (or whatever your orbiter installation is). The help explains how to setup environment variables to make easier using the tool.
A good way for testing this tool is using a clone installation of Orbiter, setting the source one using the --root option and setting the target one using the --output option (the output is not checked). It's not advisable to use the same Orbiter installation for output, as this tool is in Alpha phase and will probably corrupt a mesh sooner or later. Anyway, the tool refuses to overwrite a existing mesh for the sake of safety - if a mesh with the same name already exists, it appends ".new" to the pathname. If a .new file already exists, the tool raises an exception for that mesh and process the next one.
Useful commands:
Code:
orbitertools gui
orbitertools cli --root c:\orbiter --report .\lint_report.txt --verbose 1 mesh lint *.msh
orbitertools cli --root c:\orbiter --report .\lint_report.txt --verbose 2 mesh lint DG/*
orbitertools cli --root c:\orbiter --verbose 1 mesh copy *
orbitertools cli --root c:\orbiter --verbose 1 mesh copy DG/*
orbitertools cli --root c:\orbiter --verbose 1 mesh normalize *
orbitertools cli --root c:\orbiter --verbose 1 mesh clean DG/*
orbitertools cli --root c:\orbiter mesh rc format=header type=define output=c:/my/project/source 2001/*
orbitertools cli --root c:\orbiter mesh rc format=ssumeshc 2001/*
orbitertools cli --root c:\orbiter mesh rc format=meshc 2001/*
orbitertools cli --version
orbitertools cli --help
orbitertools cli --license
The "cli" specifier can be omitted. Currently its absence prints a message before processing in stdout, but other than that, the previous version's behaviourship is preserved. The "gui" specifier ignores the rest of the command line.
The --verbose <n> option can be omitted for a silent run.
One can use --verbose 3 for a more detailed debugging log, and --verbose 4 for a suicidal one (even I/O is logged).
Currently, the tool don't travel subdirectories recursively on Windows. I'll fix this soon (not sure when, I need to update my Windows box first).
KNOWN ISSUES:
- Resource Compiler for meshes:
- Some formats are not implemented yet.
- The End-Of-Line format is locked for Windows (\r\n). Not sure if this will be ever changed
- The header content and format cannot be customized.
- Not sure if the #define label naming approach on the OT's header format will be useful (or even usable) for all the cases. You can always use the meshc or the ssumeshc file formats however.
- This tool is wat slower than ssumeshc and meshc. The reason is not exactly the interpreted nature of the language used, Python, but because the meshes are effectively parsed one by one before processing instead of looking for the "LABEL" keywords on the file. It's slower but more flexible, as it allows me to implement new approaches (as using the remarks as source of meta-data).
- copy command for meshes:
- The copied meshes are formatted for easy reading for humans, not space saving. Other than that, the mesh contents are 100% preserved on the copy (except by comments that could not be semantically attached to an mesh artifact).
- normalize command for meshes:
- Some meshes are encrypted. The normalize will corrupt these files. XR2 Ravenstar's vessel mesh is a confirmed hit, the ANSO ones are reported to be crypted and will probably fail too.
- For reasons currently being investigated, some Virtual Cockpit meshes get some textures corrupted after normalized. It's confirmed that the problem is on the UV coordinates for texture painting in runtime. It appears to be not exactly a problem with the tool, as the issue can be replicated manually by duplicating or deleting vertices from a group. This issue don't affects 3D modellers.
- GUI:
- While multi threading is supported, there's no GUI provisioning for that. Please don't (yet) start one command without finishing the previous first. Both commands will be executed allright, but the Message text widget will be cluttered by two process outputs at the same time (at best - concurrency is not being dealt yet)
- The Scroolbars on the readonly text areas appears to be disabled, but they are working. Ignore the visual clue and use them normally. It's some kludge on the TK, working on it.
- The text widget crashes the application when large enough reports are emitted. It's a Tk Text widget issue, still looking for a work around. In the mean time, avoid firing large tasks on the GUI.
- The Orbiter PATH and the OUTPUT PATH are not persisted - a Preferences dialog is WIP. But the environment variables, when existent, are parsed.
- The verbosity is currently hardcoded to level 3 for debugging purposes.
HISTORY:
- 0.4.1.2 alpha - 2016-03-15 :
- Sorting the symbols alphabetically on Resource Compiler.
- Fixing bug on LINT while checking for materials out of order (with groups using default material from last group).
- Ditto for textures.
- Fixing a really dumb mistake on indexing groups (note to myself: groups and vertices starts at 0, textures and materials at 1). Sorry. :facepalm:
- 0.4.1.1 alpha - 2016-02-20 :
- More file formats for the Resource Compiler.
- GUI for the RC.
- 0.4.1 alpha - 2016-02-18 : Resource Compiler for Meshes.
- 0.4 alpha - 2015-12-28 : Graphical User Interface using Tk.
- 0.3.2 alpha - 2015-12-24 :
- Line numbers on Reports (when applicable).
- mesh normalize.
- mesh clean.
- Fixing environment variable names (sorry).
- 0.3.1b alpha - 2015-12-21 :
- GRP_DUP_LABEL
- TEX_PATH_INVALID
- Memory saving reports (when needed)
- XML output reports that works
- 0.3.1 alpha - 2015-12-20 : I screwed up again. =P
- 0.3 alpha - 2015-12-20 : Fixes on saving meshes, more linting.
- 0.2.1 alpha - 2015-11-18 : Better parsing, saving meshes (preserving commentaries), more linting
- 0.2 alpha - 2015-12-17 : I screwed up. Forget about this. =P
- 0.1 alpha - 2015-11-18 : First version going through the door.
Last edited: