Question So, what's a good blender workflow for exporting things to orbiter in 2021?

Played around a bit, unfortunately no such "luck" as just a sloppy mesh. There isn't a single loose vertex in the whole thing... before export. If I run it "remove loose vertices" from shipEdit on the exported mesh, it finds thousands. So definitely something wonky with the export there.

The suggestion from MaxBuzz seems to help, though: If I export each object, which would previously form a mesh group, into their own meshes instead, all but the most complex ones load fine in orbiter. Looks like I have to split up the more complex one some more, which means fooling around with selection modifiers some. And then of course there's the process of selecting each object individually and starting its export and renaming the output file. It appears to be a workable solution, but as mentioned kills any semblance of efficiency. Oh well, I guess I shouldn't complain about that as long as it works...
 
There isn't a single loose vertex in the whole thing
Forgot to say, but those commands act on the selected vertices, so you should select every thing in the group before running it.
 
@jedidia I just converted an old Viking lander model from NASA (3DS » Blender » MSH) with no problems.
I had to run an edge split modifier to get sharp edges, and of course apply transformations.
But this for the entire mesh, no more than 3 or 4 clicks in total.

I'm using Blender 2.78 because I like the Orbiter import/export tools on that version:

Test your workflow with this model, it should convert with no problems:
 
I'm using Blender 2.78 because I like the Orbiter import/export tools on that version:
So using an older blender version to use the older exporter is a thing people are doing. What's the maximum version supported there? The models I have were created with blender 2.79, I have no idea how far backwards compatible they are...
 
Seems to have the exact same issue with large meshes as the other one. Maybe it's an orbiter problem...? Will have to split things up a lot any way you turn it, but I'm interested to see if this exporter does the materials any better.
 
AFAIK, the only "issue" with large meshes is the Orbiter limit of 65k vertices and/or triangles per mesh group.
 
I have 2.78 because of Orbiter. It works fine and supports the GSLS shader. With that I get good material export.

Current Blender versions are better to work with (better UI).
Blender files aren't backwards compatible. But you can export to an intermediate format and then import on an older version.

Again, if your model has correct geometry import/export works. If not, your model has problems that must be fixed.
Don't blame the tool ;-)
 
AFAIK, the only "issue" with large meshes is the Orbiter limit of 65k vertices and/or triangles per mesh group.
We have a specific number! Thank you soooo much! :cheers:
That would definitely be my problem, then, because there are objects that have more than that amount of vertices. You're saying it's per mesh group? That means I can split stuff within the same export. Saves me some efficiency!
 
We have a specific number! Thank you soooo much! :cheers:
That would definitely be my problem, then, because there are objects that have more than that amount of vertices. You're saying it's per mesh group? That means I can split stuff within the same export. Saves me some efficiency!
Mesh parts with different materials and/or textures, or that are animated, have to be in individual groups. In addition to that, each group cannot be above the 65K limit (65535 actually).
Other than that, you want as little groups as possible to reduce the texture and material swapping during rendering.
The basics of the Orbiter mesh format are in the 3DModel.pdf file in Orbitersdk/doc folder.
 
What we should do is to build a knowledge base where all those 3D modeling facts and tips are put together, it would really help. (y)
 
Mesh parts with different materials and/or textures, or that are animated, have to be in individual groups.
I am quite familiar with how the .msh format is structured, what with having written an animation framework at some point in the past. What I didn't know is that it uses a short int to index vertices inside a meshgroup, so that information is quite valuable.
 
Yup, much better with no overflowing mesh groups:
1614385377978.png
I am however not decided about which export tool is really better. Now that I figured out this kink, they both work pretty decently, but also have their own weaknesses. The one from vlad calculates an ambience color based on some esoteric input, which is nice. Blakes exporter, on the other hand, allows configuring the material manually in blender and saves it with the project, which is a pretty neat feature, and it works in blender 2.8+, which is also significant. Haven't played around with them enough yet to come to a definite conclusion, though...
 
Blake's exporter is up-to-date, and for me that's enough. It works fine. We have to move forward and use up-to-date tools.

Cool model ! Could replace stock Lunar OB1 station ?
 
Blake's exporter is up-to-date, and for me that's enough. It works fine. We have to move forward and use up-to-date tools.
Read a bit of documentation and saw that vlads script just makes the ambient color equal to the defuse color. The big plus would be texture export, though it appears that my meshes lost textures in their retro-conversion to 1.78, so I think I'll go with Blender 2.8 and Blakes script.

Cool model ! Could replace stock Lunar OB1 station
It's not from me. It's from this royalty-free scifi mesh pack that I'm playing around with right now: https://www.cgtrader.com/free-3d-models/space/other/space-768e8b7f-9741-4868-9bde-28d3f927b946
Of course you can't get stuff to look quite as cool as in the images in orbiter because shaders, and I'm realising that it might be a bit of work to get the kinks out of the meshes to make them hold up to closer scrutiny, and they're pretty high-poly, so it's not ideal. Still, for no-strings-attached royalty-free meshes, they're really good. Anybody interested can grab them and see if they can make something cool for orbiter out of it.
 
Read a bit of documentation and saw that vlads script just makes the ambient color equal to the defuse color. The big plus would be texture export, though it appears that my meshes lost textures in their retro-conversion to 1.78, so I think I'll go with Blender 2.8 and Blakes script.

Blake's tools add an "Orbiter Materials Panel" in Blender's material properties. Its basic D3D7-compatible, but that's a start. Also it exports correctly the UV wrapping work you do in Blender, so texturing is quite straightforward.
 
I have a weird effect here... In orbiter native, the specular highlights appear on the wrong side of the mesh, i.e. the side facing away from the sun (normals are ok, otherwise you'd see right through the thing. No backfaces.). In D3D9 client, I see no specular highlights at all.

1614467069272.png
Anybody got an idea what that might be about?
 
Yes, this is a "classic" one. Load your mesh in Shipedit, use "General Normals", don't forget to save and that should do it.

Or, in Blender, press Ctrl-A and select "Apply all Transforms" (be sure you have no modifiers like mirrors, else it will get messy).
 
Yes, this is a "classic" one. Load your mesh in Shipedit, use "General Normals", don't forget to save and that should do it.

Or, in Blender, press Ctrl-A and select "Apply all Transforms" (be sure you have no modifiers like mirrors, else it will get messy).

You should apply all transforms prior to export, but modifiers like 'mirror' should not be a problem unless you have other issues with geometry. The mirror modifier is especially useful in modeling vessels.
 
Maybe normals? Try Shipedit.
Nah. As mentioned, that mesh has no backfaces. If the normals were facing the wrong way, you'd only see them from the inside. Also, I did try shipedit just to be on the save side, didn't change anything.

Load your mesh in Shipedit, use "General Normals", don't forget to save and that should do it.
Wait, you actually have to save in shipedit? Uhm... huh... kinda thought it applied its transformations to the file directly. Ok, I'll try it again, then. Still don't see why the faces would be rendered at all if they'd be facing the wrong way, though...
 
Back
Top