road-hog123 / blender-omsi-exporter Goto Github PK

A little suggestion: In exporting, get the blender name of the selected 3D object placed on filename textbox. It's a little feature that agilize the workflow exporting many objects in sequence.

The problem

I installed that plug-in on the current blender version (4.0.0.), but, Wehen I try to export something I always get a script error

The current workflow

I need to copy my work to an older blender version and export it from there

The solution

Support of the newer blender versions

Traceback (most recent call last):
  File "C:\Program Files\Blender Foundation\Blender 2.79b\2.79\scripts\modules\addon_utils.py", line 331, in enable
    mod = __import__(module_name)
  File "C:\Users\Ho Wai\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons\io_export_o3d\__init__.py", line 67
    filepath: StringProperty(subtype='FILE_PATH')
            ^
SyntaxError: invalid syntax

Blender:2.79

Bug Description

After exporting and then cheking the model file itself, each material slot became a "." rather than the texture filename itself. It happens for 99% of my files when I export, but it fine for some other models. When the model is loaded into the game it becomes white (as there is no texture named ".") Had tried this even with Blender v2.93 LTS and 3.00, still same problem. Currently running on Blender 3.2.

Steps to Reproduce

I had just exported my models with the default setiings, I did not tweak any of the options. Even I changed some options, the result is still the same.

Version Information

• Blender: v3.2
• Exporter: v3.0.1

I use Blender 3.6
I downloaded and install the .zip but nothing is actually installed
I don't have any other o3d import-export addon at this moment
Any idea? Thank you

Bug Description

Expected Outcome: Object in question exports normally (even without SDK Compatiability)
Actual Outcome: See traceback message below

Steps to Reproduce

This only came up when I'm working with a junction that has more than 7 materials, so I'm not 100% sure if the exporter was built with this in mind

Screenshot of materials and UVs in this one object

n.b. the missing textures don't seem to affect the export, having seperated the single object into multiple ones with less materials, they also seem to export normally

Traceback

  File "C:\Program Files\Blender Foundation\Blender\3.0\scripts\addons\io_export_o3d\exporter.py", line 242, in triangles
    uv_layer = me.uv_layers[wrapper.uv_map]
KeyError: 'bpy_prop_collection[key]: key "" not found'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Blender Foundation\Blender\3.0\scripts\addons\io_export_o3d\__init__.py", line 193, in execute
    exporter.export(objects, Path(self.filepath))
  File "C:\Program Files\Blender Foundation\Blender\3.0\scripts\addons\io_export_o3d\exporter.py", line 299, in export
    mesh.triangles = [meshio.Triangle(vs, m) for vs, m in triangles()]
  File "C:\Program Files\Blender Foundation\Blender\3.0\scripts\addons\io_export_o3d\exporter.py", line 299, in <listcomp>
    mesh.triangles = [meshio.Triangle(vs, m) for vs, m in triangles()]
  File "C:\Program Files\Blender Foundation\Blender\3.0\scripts\addons\io_export_o3d\exporter.py", line 253, in triangles
    me.uv_layers.new()
RuntimeError: Error: Cannot add more than 8 UV maps


location: <unknown location>:-1

Version Information

• Blender: 3.0.0
• Exporter: 2.1.0

The problem

Currently you cannot export using the name of the collection as a default when exporting multiple/single objects as one .o3d.

The current workflow

Manually copy and pasting the collection name when exporting.

The solution

Adding an option to have the collection name as the default name taken for the exported file, similar to the option that will choose the name of the last selected object by default.

The problem

Currently the exporter doesn't support custom split normals. These are used when the bevel modifier has the "Harden Normals" setting checked, or when using the Weighted Normal modifier. The autosmooth setting, found in the object data properties, under the subheading, normals, is required for these settings to work correctly. This causes faces to maintain uniform and flat shading on the model, while maintaining smooth curvature, unlike the usual method of using the edge split modifier.

The current workflow

Currently I am turning off the specularity in the material settings, using the edge split method instead to avoid any odd shading, and making use of 'container loops'.

The solution

For support to be added for this feature if at all possible, I can provide a test file if necessary.

Currently, if a filename is typed out (replacing the auto generated one) and if the .o3d file extension is forgotten, it generates a file with no extension as the save dialog does not auto-complete the filename.

Other exporters (quickly tested with the COLLADA exporter) append the extension once the name is set, so possibly adding this functionality could be a minor, but nice, quality of life improvement.

(Upon a bit of digging, I've put this as an enhancement rather than a bug as I'm not sure if it was intentionally scripted or something to do with Blender 3.0 messing up the plugin again)

Blender 4.1 removes Mesh.calc_normals_split(), resulting in an uncaught exception during export.

Version Information

• Blender: 4.1.0
• Exporter: 4.0.0

The problem

Currently you have to name the o3d by hand but it would be much faster and easier if the default name would be the name of the selected object.

The solution

using the bpy.context.active_object.name for the name instead of untitled.o3d/the last exportet name

The README states that:

Materials with textures are given an opaque white diffuse colour to avoid any undesired shading effects arising from Blender's default off-white Base Color.

However this feature has never actually been implemented—the diffuse colour is set from the (hidden) Base Color and Alpha inputs when an Image Texture node is connected.

The X exporter only exported vertex groups that were referenced by an Armature modifier. This exporter exports all vertex groups that have a non-zero number of non-zero weighted vertices.

I can't think of a use-case where this will be a problem, but if you find one please upvote this issue and explain the use-case in a comment.

All of the normals and UV-map settings seem to not appear to influence the Smooth Flat setting or adhere to smoothing settings.
This issue appears sort of or might be similar to issue #10 .
Models appear with smoothing errors like in the screenshot:

Steps to Reproduce

Exporting any Blend file with the appropriate material settings (in my case a baked texture), any normal and UV-maps setting.
No error messages.
Attached blend file of the model used to test:
Tarwestraat_Gymzaal_nr1_Github.zip
Texture belonging to the model:
Tarwestraat_Gymzaal_nr1_2048x2048.zip

Version Information

• Blender versions tested: 3.3.1, 3.5 and 3.6.1 (I started with this, not seeing in time it's not officially supported, which is why I tried the other 2).
• Exporter: Version used as linked in issue #10 #10 (comment)

Note:
I have messed with the source code and removed the transform module in the exporter. This has solved the smoothing problem, but I will add I have no clue what this might do for animations and their origin points. It was merely a try at attempting to solve this specific problem because for now, it would make my workflow A LOT quicker instead of going from 3.x.x to .obj, import it in 2.79b, export to .x and from there with the XConv tool to .o3d.
For me removing the transform settings and conversion don´t really matter right now: given Blender's design methods, it's good practice to keep transforms in an end product at 1 by definition which is something I do regardless of designing for OMSI.

I've noticed that model files generated using this plugin have a different axis applied to them that results in animations applied to objects behaving differently compared to model files that are run through the .x to .o3d creator.

If this isn't already in the SDK Support option, could an option be put into the exporter to export with the old axis?

(I'll probably put pictures to illustrate this later on)

Bug Description

When I export some models from Blender, they are abnormally brighter than other models. I'm unsure as to what could be causing this. Both of the ticket printer models were exported using the plugin, but they were exported from different .blend files. I was speculating that it could be caused by having the Emission node set up, but this happens even with models that do not have this node connected.

This doesn't happen just to me, I've seen the same issue in a Discord server.

Both of the included .blend files are from Blender 3.6 LTS

Steps to Reproduce

Export a model from Blender

Version Information

• Blender: 3.6 LTS and 4.0
• Exporter: 3.2.0 and 4.0.0 (haven't tried older)

blend.zip

Within an OMSI mesh file strings are limited to 255 characters—this applies both to texture paths and bone names. Vertex group names are limited to 63 characters, so bone names are not an issue; however Blender permits image filepaths to be up to 1023 characters, which makes it possible to enter a filepath that has more than 255 characters after the last texture folder.

Fortunately attempting to encode a string longer than 255 characters results in a Python exception instead of writing a corrupt mesh file, however it would be better to catch the exception and report a useful error message.

Traceback (most recent call last):
  File "io_export_o3d\__init__.py", line 218, in execute
    exporter.export(objects, Path(self.filepath))
  File "io_export_o3d\exporter.py", line 322, in export
    b = meshio.dump(mesh, self._fs)
  File "io_export_o3d\meshio.py", line 437, in dump
    ba += es(m.texture)
  File "io_export_o3d\meshio.py", line 382, in es
    return ef(fs._stringLengthFormat, len(s)) + s.encode(fs._stringFormat)
  File "io_export_o3d\meshio.py", line 378, in ef
    return pack('<' + fmt.fmt, *v)
struct.error: ubyte format requires 0 <= number <= 255