Project Orbiter::Tools::Mesh::Lint
- Thread starter Lisias
- Start date
Lisias
Space Traveller Wanna-be
I'm guessing the problem is on the export tool. I think that such an obvious error would had been already detected and fixed if it would be on the AC3D itself.
What I think it's happening is that the export code is downsizing the numbers from doubles to floats earlier than advisable and then very small numbers that would be successfully used as divisors became rounded to zero, and you got a +/- INF number instead.
Lisias
Space Traveller Wanna-be
I finished the implementation of the three main formats for the Resource Compiler.
Such formats are: "header", "meshc" and "ssumeshc". Header and ssumeshc has subtypes : "define", "const" and "constexpr". Define is available only on header and meshc (this last has only this type, by the way).
Basically, meshc and ssumeshc aims to be a drop-in replacement for the original tools, adding the following enhancements:
The "native" header format uses the Mesh name as a infix on the symbol name, what allows you to include many meshres.h files on your project without collisions. It also defines symbols for the textures and materials (useful when you use dynamic textures or any other runtime tricks).
No customizations options for the symbols naming are implemented (yet).
In time, I added a Dialog Box for the RC command to allow proper setting options for the run. It's crude, but it works. Empty options will select the default ones.
Download links on the first post, or here.
I'm cooking some fancy formats that I think can be useful, but the the previous ones are the canonical ones.
Have fun!
Such formats are: "header", "meshc" and "ssumeshc". Header and ssumeshc has subtypes : "define", "const" and "constexpr". Define is available only on header and meshc (this last has only this type, by the way).
Basically, meshc and ssumeshc aims to be a drop-in replacement for the original tools, adding the following enhancements:
- Handling duplicated labels (by adding a increasing counter as suffix on the duplicates)
- Using, when available, the remark on the GEOM tag as label when a LABEL is missing.
The "native" header format uses the Mesh name as a infix on the symbol name, what allows you to include many meshres.h files on your project without collisions. It also defines symbols for the textures and materials (useful when you use dynamic textures or any other runtime tricks).
No customizations options for the symbols naming are implemented (yet).
In time, I added a Dialog Box for the RC command to allow proper setting options for the run. It's crude, but it works. Empty options will select the default ones.
Download links on the first post, or here.
I'm cooking some fancy formats that I think can be useful, but the the previous ones are the canonical ones.
Have fun!
Last edited:
Lisias
Space Traveller Wanna-be
Minor Revision 0.4.1.2 alpha - Bug fixes
Hi.
This is a maintenance release.
Change Log for 0.4.1.2 alpha:
Download links on the first post, or here.
Hi.
This is a maintenance release.
Change Log for 0.4.1.2 alpha:
- 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:
Download links on the first post, or here.
Last edited:
Lisias
Space Traveller Wanna-be
Performance Issues on Python 3
Request for Comments.
TL;DR : Someone can suggest some integer math accelerating package (if existent)?
FULL HISTORY: besides never expecting bleeding edge performance, I'm somewhat concerned about the performance of the tool.
I already knew from my past experiences with Python2 that this is not made for speed, and frankly, speed is not the most important requirement for this tool. But Python3 introduced some changes that made my core business even slower - INTEGER math is almost 3 times slower than Python2 at worst case.
Changing languages is not an option for two reasons:
1) Java (or any other language running on the JRE, as JPython or Haskell, Scala or Groove) is a no go. Installing a runtime for Python is way less problematic (and controversy) than a JRE, and I have the option of using PyInstaller and save the user of doing that.
2) I don't want to introduce yet another language on the ecosystem. Hell, I was planning to use LUA to do the job (as it is used on Orbiter), but adopted Python due Blender. And since Python is also used on some other 3D packages, using anything else for this tool would be foolish.
So Python it is, and Python will be.
But my problem remains: I'm taking more than 90 minutes to LINT all my meshes on my Orbiter installation, and LINTing bigger meshes using the GUI can take more than a minute sometimes.
My first move was to give a try on numpy package - something that I dismissed at first to avoid "yet another dependency" (tm) on the project, and since the data structures are more complex than just vectors and matrices (and most of the current operations are accelerated by caching hashes), and profiling tells me that this is not (yet) the worst bottleneck (but it will be soon, as matricial math will be used later), I think I can deal with this in a second pass.
Garbage Collecting is under control - the tool is nothing more than batch jobs embedded into a GUI or TUI, there're clear points where we can free references and ask the GC to collect some memory (and yes, I profiled the solution - it's best to make micro GC at the end of a "job" than make a HUGE GC when memory became scarce - and this keeps memory usage under reasonable levels, I have scenarios where more than 1GB of RAM is needed).
So now I'm looking into you, INTEGER MATH. Profiling some mockups on Python2, Python3 and Python3+numpy I found that doing math with Python2 is far the best option. But not a viable one, as Blender and so O.T. uses Python3. =/
Using numpy.int32 and numpy.int64 appears to present the worst results, it's the slower of all options (they converted them into native Python format on the fly?).
Someone can suggest some integer math accelerating package (if existent)? My intensive use of hashes suggests me that my current bottleneck is integer math.
Request for Comments.
TL;DR : Someone can suggest some integer math accelerating package (if existent)?
FULL HISTORY: besides never expecting bleeding edge performance, I'm somewhat concerned about the performance of the tool.
I already knew from my past experiences with Python2 that this is not made for speed, and frankly, speed is not the most important requirement for this tool. But Python3 introduced some changes that made my core business even slower - INTEGER math is almost 3 times slower than Python2 at worst case.
Changing languages is not an option for two reasons:
1) Java (or any other language running on the JRE, as JPython or Haskell, Scala or Groove) is a no go. Installing a runtime for Python is way less problematic (and controversy) than a JRE, and I have the option of using PyInstaller and save the user of doing that.
2) I don't want to introduce yet another language on the ecosystem. Hell, I was planning to use LUA to do the job (as it is used on Orbiter), but adopted Python due Blender. And since Python is also used on some other 3D packages, using anything else for this tool would be foolish.
So Python it is, and Python will be.
But my problem remains: I'm taking more than 90 minutes to LINT all my meshes on my Orbiter installation, and LINTing bigger meshes using the GUI can take more than a minute sometimes.
My first move was to give a try on numpy package - something that I dismissed at first to avoid "yet another dependency" (tm) on the project, and since the data structures are more complex than just vectors and matrices (and most of the current operations are accelerated by caching hashes), and profiling tells me that this is not (yet) the worst bottleneck (but it will be soon, as matricial math will be used later), I think I can deal with this in a second pass.
Garbage Collecting is under control - the tool is nothing more than batch jobs embedded into a GUI or TUI, there're clear points where we can free references and ask the GC to collect some memory (and yes, I profiled the solution - it's best to make micro GC at the end of a "job" than make a HUGE GC when memory became scarce - and this keeps memory usage under reasonable levels, I have scenarios where more than 1GB of RAM is needed).
So now I'm looking into you, INTEGER MATH. Profiling some mockups on Python2, Python3 and Python3+numpy I found that doing math with Python2 is far the best option. But not a viable one, as Blender and so O.T. uses Python3. =/
Using numpy.int32 and numpy.int64 appears to present the worst results, it's the slower of all options (they converted them into native Python format on the fly?).
Someone can suggest some integer math accelerating package (if existent)? My intensive use of hashes suggests me that my current bottleneck is integer math.
Last edited:
Similar threads
