[BVE5] Texturing problems probably caused by Blender

I am trying to create a German Lf7(speed limit) sign on a pole. It's rectangular. The problem is that Blender seems to kinda mess up the UV and the scaling? It's supposed to be centered on the pole. As you can see in the close-up, there's a very thin line where I suspect an edge of the sign to be, because BVE apparently interprets it to be twice as wide. What did I miss in Blender? Is Blender even a good option for creating .x files? Help?

Now that's odd.

What does your texure look like?


If you can upload the broken object somewhere, I can definitely see if it's our parser causing the issue.

leezer3 wrote:What does your texure look like?

I would really like to attach a file, but I apparently "exceeded total storage space (Free Space: 7)"? What does the 7 mean? My image is just 9.5K..... And since I'm new to this board, I can't link to external stuff either.

leezer3 wrote:if it's our parser causing the issue

I'm not sure if we're talking about openBVE or BVE 5.8, because the latter is what I'm using. I'm still new to the BVE community, and I'm very sorry, but I don't really know the difference between these two yet...

Sorry, I'm the primary developer / maintainer for OpenBVE these days

I think you probably can still link, just leave off the http

If OpenBVE and you still can't get linking to work, try opening an issue on Github:
http://github.com/leezer3/OpenBVE

leezer3 wrote:I think you probably can still link, just leave off the http

The texture is i.imgur.com/89uURgZ.png . And you can find the strange file at nc.softlimepoof.de/index.php/s/3LHHjQw9SZNmmPG .

Interesting- I've found one bug (broken matrix rotation if using Assim parser) and a piece of awkward legacy behaviour.

I can't reproduce your exact glitch though.
Is this a screenshot from Route Viewer or the main game?

---

The legacy behaviour dates back to when BVE4 was in development. (2003 or so.....)
Mackoy decided to switch to X as the preferrred object format, presumably due to the fact that it could be generated by most 3D programs.
Unfortunately, at the time the only texture format supported was BMP, but transparency support was required, which the X format doesn't provide.

As a consquence, in BVE X files, the color pure black (0,0,0) is reserved and used to provide transparencies.
I'm very reluctant to change this, as it'd break a bunch of older stuff badly.

leezer3 wrote:I can't reproduce your exact glitch though.
Is this a screenshot from Route Viewer or the main game?

It's a screenshot from BVE 5.8 ingame. Like I said, I'm not using openBVE, and the reason I haven't switched yet is because I'm not sure if exactly the same stuff I can do in BVE 5.8 is possible in OpenBVE.

leezer3 wrote:As a consquence, in BVE X files, the color pure black (0,0,0) is reserved and used to provide transparencies.

Do you recommend I brighten the color slightly? Like (1,1,1)?

Most things from BVE5 are possible in OpenBVE, but some are different

OpenBVE has a somewhat more international following than BVE5, but is generally very similar.
The primary 'missing' feature at the minute is BVE5's support for arbritary repeaters with non-block lengths. There are a few other minor differences, such as BVE5 supporting textual keys for rails etc. as opposed to numerical.

---

Brightening the color slightly (1,1,1 is fine assuming you don't save as a reduced color PNG or anything) would be required for OpenBVE, but I don't think that's the glitch in BVE5.

I can't see anything techincally wrong with your file, so it would be up to Mackoy to fix whatever's broken. Unfortunately, I don't have source access to BVE5 to see much more of what's going on.

FWIW, the Japanese community tend to use Metasequoia ( https://www.metaseq.net/en/ ) for 3D modelling of this nature, so this may be a viable alternative & files produced in this way are more likely to not have unexpected bugs.