Exporting from Blender to x format

I have been using this exporter for Blender -

https://github.com/DodgeeSoftware/io_scene_directx

It works quite well when I open the .x file in Object Viewer but when I load a route with that same .x file I get an error to say that there is no plugin capable of loading that object.

It works in Object Viewer with both the new and assimp parser.

That's odd.

If it works in one, it *should* work in all, that was the whole point of converting things to plugins.
Any chance of a small sample file?

I didn't realise that there were options in the main program to choose the NewXParser. The files now load in game. However, I still get the errors in Route Viewer where there seems to be no options to choose the NewXParser.

Interesting, you're right.

Never seems to have been added as an option to Route Viewer, although I now have.

I've found at least one of the issues (original parser *really* doesn't like empty texture strings), but if it's still broken, I'll need a sample file.

If you want to specifically control the X parser in use, there is the following routefile command available:

Options.XParser
Arguments:
0- Original X parser
1- New X parser
2- Assimp X parser

This is deliberately undocumented (The new X parser is set as default unless specifically user-changed in the main program), and primarily intended for backwards compatibility hacks usage.
I'd much rather find the bugs in the parsers than have this changed though

Thanks Chris. The new build has everything working.

When I export a file with more than one object it seems that ObjectViewer only sees one of them. If I combined the two objects it has no problem. In most other 3d viewers the two objects are displayed. 
Here is a blend file(Blender2.93) with the two objects I have tested -

Your file isn't public (I've requested access)


Thanks.
The trouble is that we've got two root frames, but with differing transform matrices, which we don't seem to handle well.
Should be able to fix this for the new X parser and Assimp, but the original parser may be more difficult.

NewXParser and Assimp now fixed.

The original X parser doesn't support frame transform matrices full-stop unfortunately. Not really intending on adding this, as it's major work.

I may well deprecate the original X parser by removing it as a selectable option for the next major release (but keep it available for forcing via the above routefile command / hacks if people really want it)

Thanks Chris!
I don't think I would have stuck with OpenBVE all these years if it wasn't for your dedicated support for the program.

It seems the newXparser can handle 0,0,0 black in the ObjectViewer but not in Route Viewer or in game. See attached sample.

https://drive.google.com/file/d/1_DNs8FzjXwnqmxnYSYvEePanRnKha8Zk/view?usp=sharing

That's hitting a BVE4 edge-case, and is technically as designed.
No good way to solve it, either way is likely to break things.

TLDR:
BVE4 introduced support for X files.
However, it only still supported BMP textures in 32-bit or 256 colors. Obviously, this is a problem, as neither of these support the use of an alpha channel.
Hence, pure black (0,0,0) was reserved for color-key transparency usage. This is actually in the developer documentation too: https://openbve-project.net/documentation_hugo/en/objects/other/x.html

The issue is that there's no reliable way to detect whether a route was designed for BVE4 or OpenBVE (and the for that matter the older BRSigs etc. libraries still use this) and change this behaviour.

Maybe have a bool "BlackIsAlphaInX" at the beginning of a route, default setting "true"?

Quork wrote:Maybe have a bool "BlackIsAlphaInX" at the beginning of a route, default setting "true"?

That would work, but having what's techincally broken behaviour (according to the X specification) on by default isn't what I'd call a good idea.....
I *could* possibly try and detect older X files, but I don't know off the top of my head whether any of the older stuff used exported 3D models *and* this trick. I'd hope not, but the amount of random mess I've found in some routes is unreal
At the minute, I think having it documented as a 'quirk' of the engine is the best thing to do, unless anyone else wants to comment. Also need to check what BVE5 actually does for that matter......

Something like this would ideally be removed with the introduction of a new routefile format, but that's not likely to happen any time soon