Project Blender Mesh Tools add-on

[Blake]

Update:

2.0.7
- Fix annoying bug importing meshes for Orbiter installations where the base Orbiter folder was named something other than 'Orbiter'.

Also tested with Blender 2.82 and I cannot see any issues using that version of Blender.

 

[Jordan]

It would be useful to keep the group names instead of renaming them to Group_1 Group_2 etc.

It would also be useful to only export the selected groups instead of exporting them all together. The reason for this is that I duplicate some groups to have a backup of them and can use them later if necessary. I used this very often with vlads export addon, I only select those that are important for the mesh and leave the others unselected as backup.

 

[Blake]

It would be useful to keep the group names instead of renaming them to Group_1 Group_2 etc.

Glad you mentioned that. That is an oversight I had forgotten, it will pick up the LABEL if specified and us that for the group, and mesh name.

It would also be useful to only export the selected groups instead of exporting them all together. The reason for this is that I duplicate some groups to have a backup of them and can use them later if necessary. I used this very often with vlads export addon, I only select those that are important for the mesh and leave the others unselected as backup.

That should not be hard to implement, but I will probably make it an option. I often have objects selected yet want to export the entire mesh, so I don't want to change that workflow.

IF Enabled:
- and selected objects in context, then only those objects are exported.
- and no objects selected in context, the everything exports (current behavior)

IF NOT Enabled:
- everything exports (current behavior)

 

[Jordan]

IF Enabled:
- and selected objects in context, then only those objects are exported.
- and no objects selected in context, the everything exports (current behavior)

IF NOT Enabled:
- everything exports (current behavior)

This is acceptable :thumbup:

 

[Blake]

Ok, 2.0.8 is up with those changes. Try them out and let me know how they work.

 

[llarian]

Blake, is the "Orbiter takes only the first material" an Orbiter issue or is it an issue with addon? Would the ability to use multiple materials be more useful?

 

[Blake]

Blake, is the "Orbiter takes only the first material" an Orbiter issue or is it an issue with addon? Would the ability to use multiple materials be more useful?

That is an Orbiter issue. The Orbiter mesh file format allows you to assign one texture and one material to a mesh group.

So, the basic workflow is to create your .DDS texture (which both Blender and Orbiter support) and use that to texture your model in Blender. Then adjust both as needed while working on your model.

I use Gimp to create the texture file, which now has the DDS exporter built in to it.

 

[Jordan]

Ok, 2.0.8 is up with those changes. Try them out and let me know how they work.

I tested it and found some problems.

1. I am currently working on the ProjectApollo Mobile launcher and the textures are stored in a subfolder called ProjectApollo in Orbiters Textures folder. When I build the mesh, this subfolder is not saved in the mesh, only the texture name is saved and orbiter searches for the textures in the Textures folder and not in the ProjectApollo folder.


2. When I open my 2.79 blend file in Blender 2.8+ and I Build the mesh, it seems like more geometry is being created than Vlad's exporter and Orbiter can't handle it and the mesh doesn't look the way it should. It looks partly scrambled as if I'm trying to import the meshes from AMSO.

The same thing happens when I import the Orbiter mesh and export it again without modification.

I also have this problem with Vlad's exporter and therefore I have split the mesh in more groups.

It seems that Orbiter get problems from a certain amount of geometry. Or there is a limit for each group.




3. I have numbered the mesh groups from 0 upwards, for example. 000_groupname, 001_groupname etc. When I open the 2.79 blend file, this order is not retained when exporting and I am forced to edit the Sort Order by hand. The order of the groups is important for the transparent textures and animations.

4. I also have to rotate the mesh 180 degrees when I open the 2.79 blend file.


All these problems only exist when I open my blend 2.79 file into 2.8+. Except this when importing and exporting the mesh file without modification.


I have not yet started to model something directly in 2.8+ and therefore I do not know if the problems exist there.

 

[Blake]

I tested it and found some problems.

1. I am currently working on the ProjectApollo Mobile launcher and the textures are stored in a subfolder called ProjectApollo in Orbiters Textures folder. When I build the mesh, this subfolder is not saved in the mesh, only the texture name is saved and orbiter searches for the textures in the Textures folder and not in the ProjectApollo folder.


2. When I open my 2.79 blend file in Blender 2.8+ and I Build the mesh, it seems like more geometry is being created than Vlad's exporter and Orbiter can't handle it and the mesh doesn't look the way it should. It looks partly scrambled as if I'm trying to import the meshes from AMSO.

The same thing happens when I import the Orbiter mesh and export it again without modification.

I also have this problem with Vlad's exporter and therefore I have split the mesh in more groups.

It seems that Orbiter get problems from a certain amount of geometry. Or there is a limit for each group.




3. I have numbered the mesh groups from 0 upwards, for example. 000_groupname, 001_groupname etc. When I open the 2.79 blend file, this order is not retained when exporting and I am forced to edit the Sort Order by hand. The order of the groups is important for the transparent textures and animations.

4. I also have to rotate the mesh 180 degrees when I open the 2.79 blend file.


All these problems only exist when I open my blend 2.79 file into 2.8+. Except this when importing and exporting the mesh file without modification.


I have not yet started to model something directly in 2.8+ and therefore I do not know if the problems exist there.

If you can send me the 2.79 blend file I'll take a look.

1. is easy to fix, the exporter does not take into account sub-folders under 'textures', but it can.

2. I'll take a look at this with the file. I'm not aware of any limitation on mesh size in Orbiter, but something may be causing issues.

3. Export sorts the mesh objects based on the 'Sort Order' object property (a custom property the add on uses). This allows you to control transparency. Imported meshes will not know of that, so I'll need to think about how to handle that, but that is why the export messes up your order.

4. This is probably the y - z axis values getting swapped. The export should swap them back. To me the swap makes Blender more intuitive when working with a model. A flag could avoid that swap if preferred.

 

[llarian]

The importer handles subdirectories in Textures just fine, so one would think the exporter should to.

 

[Blake]

The importer handles subdirectories in Textures just fine, so one would think the exporter should to.

Yes it should. I'm adding that.

 

[Jordan]

If you can send me the 2.79 blend file I'll take a look.

It's not because of my mesh. It is easy to reproduce. If you have installed ProjectApollo then import the mesh Saturn5ML.msh. See the vertex and face counters in a group. Now export the mesh and reimport the newly created one. You will notice that the face number has not changed but the vertex counter is much higher. That shouldn't be.

My mesh has a large number of faces and vertex. I cannot increase the number of faces and vertex without problems. These additionally generated vertex causes me problems.

For numbers 3 and 4 this does not cause any major problems. Once I have entered the sort order by hand and rotated the mesh by 180 degrees, it is ok.

Vertex count is limited to 65536, see post from Jarmonik.
https://www.orbiter-forum.com/showthread.php?p=576483&postcount=6
But that's not a big problem, splitting the groups into several parts solves the problem.

Another problem I found is that if only the selected groups are exported, the textures of the unselected groups will still be exported. Only the textures of the selected groups should be exported since the others are not needed.

And another suggestion for improvement. The LABEL names sometimes contain spaces, it would be better to recognize these spaces and replace them with underscores, for example. otherwise the name will be cut off.

I am very satisfied with your exporter. It takes big steps to be perfect. :thumbup:

 

[Blake]

I have code for the LABEL name with spaces, and the texture path issue (Textures sub folder) that I will put up in the next few days.

I'm looking at the vertices 'inflation' issue. The Orbiter mesh format only allows one UV setting per vertex, so that is why most meshes end up larger when you export. In your case, we are importing from an Orbiter mesh file, so you would think you could at least retain that format. I'm not sure why it is not doing that, but I am taking a look.

---------- Post added 03-06-20 at 06:49 PM ---------- Previous post was 03-05-20 at 07:15 PM ----------

2.0.9 is up.

Import: Groups will be named using the mesh group LABEL tag. Spaces will convert to _.

Export: Textures referenced in sub-folders under Orbiter\Textures will include the proper sub-folder in the mesh file.

Export: Fixed a bug causing too many vertices (duplicates) to be created. The comparison for 'sameness' was not using a tolerance. See the 'set_normal' method in orbiter_tools.py if you feel you need to adjust that tolerance. I can make this a parameter if needed, but it seems the default is working.

 

[Jordan]

I had some problems that I have now solved manually. When opening the 2.79 blend file in 2.8 and rotating it 180 degrees did not work, all animations in orbiter were not rotated around the correct axis. But I found a solution for that.

Your exporter still produces too many vertices compared to vlads and my mesh was above the 65536 limit. I have now cleaned my mesh a bit and deleted some faces that were not necessary. Now i can work with your exporter.

There is still a problem. The export of textures and materials from unselected objects. This creates too many materials and textures in the mesh file that are not used. I can delete all these textures and materials in Blender, but that's a lot of manual work.

Another problem that I have but has nothing to do with your exporter is this.

I use this script to calculate the vectors of the axes of rotation of the animations.

https://www.orbiter-forum.com/showthread.php?t=36375

But that doesn't seem to work in blender 2.8. Do you have a tip how I can get it to work in 2.8?

 

[Felix24]

Hi,

I'm unable to import anything. Here's what I'm using/trying:

Most recent version of orbiter-blender plugin (as of March 7)
Blender 2.82 on Mac (my Windows machine is too old to run Blender 2.8)
Copied my whole Orbiter installation folder to my Mac, renamed folder to "Orbiter"
Have tried importing Atlantis_SRB.msh, Carina.msh, and ShuttlePB.msh.

Here is the error message:

Traceback (most recent call last):
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/__init__.py", line 175, in execute
    with import_tools.OrbiterImportSettings(verbose=self.orbitertools_import_verbose) as config:
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/import_tools.py", line 32, in __init__
    orbiter_tools.get_log_folder(), "BlenderTools", ".log")
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/orbiter_tools.py", line 413, in get_log_folder
    return bpy.path.abspath("//") if bpy.data.is_saved else os.environ['TEMP']
  File "/Applications/Blender.app/Contents/Resources/2.82/python/lib/python3.7/os.py", line 678, in __getitem__
    raise KeyError(key) from None
KeyError: 'TEMP'

location: <unknown location>:-1

I suspect it has something to do with trying to import into Blender on a Mac, but I'm not sure. What should I try next?

Thanks!

 

[Blake]

Hi,

I'm unable to import anything. Here's what I'm using/trying:

Most recent version of orbiter-blender plugin (as of March 7)
Blender 2.82 on Mac (my Windows machine is too old to run Blender 2.8)
Copied my whole Orbiter installation folder to my Mac, renamed folder to "Orbiter"
Have tried importing Atlantis_SRB.msh, Carina.msh, and ShuttlePB.msh.

Here is the error message:

Traceback (most recent call last):
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/__init__.py", line 175, in execute
    with import_tools.OrbiterImportSettings(verbose=self.orbitertools_import_verbose) as config:
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/import_tools.py", line 32, in __init__
    orbiter_tools.get_log_folder(), "BlenderTools", ".log")
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/orbiter_tools.py", line 413, in get_log_folder
    return bpy.path.abspath("//") if bpy.data.is_saved else os.environ['TEMP']
  File "/Applications/Blender.app/Contents/Resources/2.82/python/lib/python3.7/os.py", line 678, in __getitem__
    raise KeyError(key) from None
KeyError: 'TEMP'

location: <unknown location>:-1

I suspect it has something to do with trying to import into Blender on a Mac, but I'm not sure. What should I try next?

Thanks!

The script is assuming you have a 'TEMP' environment variable set. I guess a Mac does not have that. To avoid that specific error, create an empty .blend file in Blender and save it. What its really trying to do is find someplace to put the log file, which it will try to put in the same folder as your blend file. If the current Blender environment has not been saved, it will look for the TEMP folder.

The Import will create a new scene, so really you can have any file open and then run Import. It should work.

 

[Felix24]

Thanks, that did the trick temporarily. However, I still have to save an dummy .blend file after every time I restart Blender, otherwise it goes back to not being able to import anything.

That being said, after I save a dummy .blend file, I am able to open things like Atlantis_SRB.msh, Carina.msh, and ShuttlePB.msh. But I am still unable to open Atlantis.msh, and here is the error message I get:

Traceback (most recent call last):
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/__init__.py", line 183, in execute
    import_tools.import_mesh(config, path)
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/import_tools.py", line 424, in import_mesh
    textures)
  File "/Users/colin/Library/Application Support/Blender/2.82/scripts/addons/orbiter-blender-master/import_tools.py", line 369, in build_mat_textures
    texImage.image = bpy.data.images.load(src_tex_file)
RuntimeError: Error: Cannot read '': No such file or directory
location: <unknown location>:-1

Thanks for your help!

 

[Blake]

2.0.10 is up.

This version adds the option to disable the Y-Z axis swap, and instead 'mirror' the X axis to match that of Orbiter. I've tested this with a number of different add-ons and seems to be behaving as expected, but please give it a try and see if it is working for you as expected.

Jordan:
This should fix your animation/rotation issue as there should be no need to rotate the mesh.

How I handle animation location is to place two 'empties' into the mesh and mark them to be include in the resulting '#include' file. My code can then pick those up and build the appropriate animation code.

I'll look at the export materials issue when I get a chance.

Felix24:
You error is probably another 'python 'os' lib difference' issue. Atlantis appears to pull textures from both Textures and Textures2 and it appears under MAC we are not finding the right textures folder. I'll see if there is a non-os dependent way to deal with that, but I don't have a MAC to test on, so I cannot promise much.

 

[Jordan]

This version adds the option to disable the Y-Z axis swap, and instead 'mirror' the X axis to match that of Orbiter. I've tested this with a number of different add-ons and seems to be behaving as expected, but please give it a try and see if it is working for you as expected.

This is no longer necessary since I have already migrated my mesh to 2.8+. The animations also work as they should be.

I tried it anyway and it doesn't work. In Blender, I have to rotate the mesh in the Z axis, not in the X axis. With the V2.0.10 my mesh is no longer vertical, it "lies" on the side.

I don't need it anymore, but that will be necessary in the future for others who want to migrate their Vlad's 2.7 mesh to Blake's 2.8.


What causes me problems is that your exporter and Vlad's exporter also generate more vertices than Blender shows me.
And the problem with the materials and textures that do not belong to the selected groups are also exported.

What is also important to me would be that the sorting order is based on the outliner and not on the sorting order in the "Orbiter Output Panel", since I have numbered all groups in the outliner and the order is much clearer there. e.g. 001_Group 002_Group etc. You can see that immediately. In the Orbiter Panel you have to select each group individually to see the order.

How I handle animation location is to place two 'empties' into the mesh and mark them to be include in the resulting '#include' file. My code can then pick those up and build the appropriate animation code.

Animation location is not the problem. The axis of rotation is the problem and only if this axis is not exactly in the X, Y or Z axis and deviates from it.

 

[Blake]

What causes me problems is that your exporter and Vlad's exporter also generate more vertices than Blender shows me.

This is unavoidable and has to do with the way Orbiter and Blender handle vertices, normals and UVs differently. In Blender, normal data is stored with the triangle (roughly speaking) where Orbiter associates it with the vert. Everyplace in Blender where a vert is shared with multiple triangles, Orbiter will need that vert to be duplicated to account for the unique normal data.

In short, don't rely on the Blender vert/faces/tri data to determine how big your Oribter mesh will be. That depends on a lot of factors such as sharp edges etc.

The sorting by group order and materials issues should be easy to implement so I will add those.