[Question] How many vertices are currently supported in a single .b3d file?

[BPI-919]

Description

Hi,

I have recently seen in the developer documentation, that maximum 65534 pieces of Vertex command can be accepted in 1 .b3d file.

I was thinking about the related warning messages appearing in Object Viewer, and I took a look at the source code, and I think I found an interesting thing...

As you can see above, according to the (source code) warning message, 65535 pieces of Vertex command is still acceptable.

So can you please clarify the maximum number of the supported Vertex commands in 1 .b3d file?

65534 pieces of Vertex command - allowed
65535 Vertex - still allowed (?)
65536 Vertex - not allowed (too many vertices)

Or 65536 is still supported, because in the source code, a[j] starts from 0 and ends with 65535, which means 65536 pieces of vertices are allowed (?).

I am also curious about the appearance of the [MeshBuilder] s:
What happens if I try to load an .b3d object with e.g. 65540 vertices / too many vertices ?
Let's say that 65532 Vertex commands are in 1 [MeshBuilder] , and the rest 8 Vertex commands are in another 1 [MeshBuilder] . In this case, the whole of the first [MeshBuilder] appear properly, and the second one does not appear at all, or will the loading of this .b3d object file produce another / different result(s)?

Thanks in advance for your answers!

[leezer3]

Initially, the vertex index in a mesh was stored as a ushort
This gives a technical possible range of vertex indicies of 0 - 65,535 (hence actually 65,536 total possible).
It seemed better however to use 65,534 as most people don't understand the concept of zero-based indexing very well.

Michelle's parser never bothered to check the actual length of this number (other than by validating it was a valid index to a declared vertex), presumably as at the time it was written that many verticies were completely unusuable.

With regards to multiple MeshBuilders, it'll probably allow 65,536 vertices in each section, up-to a total of 2,147,483,648 vertices (That being the max positive length of an uint)
Realistically though, I suspect it'll either run out of memory or crash somewhat long before then.

Whilst I could quite easily change the parser to allow longer indicies, the entirety of support for larger objects isn't too great, and using things of this size slows down quite considerably.
This is somewhat worse with CSV / B3D objects as these are normally hand-built and have an ill-defined structure, which means that the whole parser is a bunch of additional hacks / bodges.
Re-writing the parser here is on a long list of things to do, but as it works tolerably at the moment, it's not high on that list......

[BPI-919]

Ahh, okay, I understood. So every [MeshBuilder] section can contains 65536 Vertex commands. If I divide the 2,147,483,648 by 65,536 , I will get 32,768 , so 32,768 [MeshBuilder] can be present in every .b3d file. (Perhaps it is possible to create a Warning / Error message also for [MeshBuilder] limits. :D )
I misunderstood the limits, but now it is clear for me.

I faced another kind of thing:
If I have 1 or more error message(s) in Object Viewer, when I view them by pressing the F9 button, I cannot read the whole message, because the file path of the current (loaded) object file is not too short, and despite I try to widen on the column of the text message every time, it seems that there can be a limitation in the maximum length of the visible message...
So can you please duplicate the maximum length of the writable log-message in Object Viewer and Route Viewer?
...because now I cannot read the entire message per messages. :/

[leezer3]

I can't reproduce the issue with error width.

The window will resize, and this grows the message.
You also ought to have a scrollbar at the bottom of the window, which will allow you to view anything that's offscreen.

If that's not working properly, can I see a screenshot of the message window?
Can't think of anything that would mess that up, unless it's the HU locale doing something funny :/

[BPI-919]

Hi,

I collected a couple odd things of the latest openBVE version (2024.12.04.), you can find the related video here.
For me, it was an easier way (showing the issues) than writing them.
Could you please take a look at these bugs?
And feel free to advise.
Thanks in advance.

[leezer3]

Skimmed the first part of the video, but i can't really see anything other than you launching things via Visual Studio.

Are you looking at the exit codes or something?
They're irrelevant if so.

[Kenny-Hui]

Had a better look of the video:

1. Launching ATSPluginProxy standalone from Visual Studio exits with a non-zero code
2. The "Check for Updates" does not report today's date
3. ObjectViewer/RouteViewer cannot launch the window in maximized
4. Object/RouteViewer's Resolution Setting is clamped to the total width/height of the window
5. Many GUI in WinForm does not respect options.cfg, such as "Mode of driving", VSync, Interpolation section, Object Parser etc. (i.e. It sets to Nearest Neighbor everytime, despite the actual settings being otherwise). This also goes for ObjectViewer & RouteViewer.
6. Object Viewer's "Keys" config, the "Backwards" fields would always follow the "Forwards" field, making it impossible to set a different value for Forward/Backwards
7. Object Viewer's "Keys" config is not user-friendly, as you must find the key through a long list of keys, and manually typing the key's name does not work.
8. Object/RouteViewer's version still says 1.7.2.0

1, 2, 3, 4 is probably intentional
5, 6 seems like a bug
7, 8 is an issue, but not as "breaking"

For 2, the date indicates the date of the latest release version, not today's date. If you are looking for the latest nightly build, you need to manually modify options.cfg dailybuildupdates to true

[leezer3]

Thanks :)

I've fixed the issue with the options reverting to default (a incorrect case sensitivity check in the replacement CFG parser), plus removed some useless cruft. (It was manually using a switch-case to set the option, rather than just a ToString() call....)

1:
There's absolutely nothing you can do here.
Windows unceremonously unloads the program when you close the console window, and doesn't respect anything you try to do.
It's not designed to be manually launched anyway.

8:
There's actually been no real development in Object Viewer / Route Viewer for a long time- They're functionally essentially finished, and everything is being done in the external libraries.
I think the key adding is probably the only significant thing done since the 1.7 series.
Version numbering has never really been a strong point though. I ought to see if I can get the script that auto-generates the version for the main program to do it for the others as well, but it's minor......

[BPI-919]

Thank you so much! :)
I wanted describe the problems I faced, but unfortunately for me it takes more time, because I always would like to write the things the most exactly / exactest.
Thanks for the summary, again!
I want switch the OpenBVE update mode to check the nightly build updates, and I also have not had the knowledge about this option so far.
One of my problem was that although I used the latest nightly build, when I clicked to the update checking button I got message on an older update, but not got a message like: No updates are available.
My question is, why does OpenBVE not recognise the version itself and does it not make a decision on the build automatically? I mean if I download the main release, then OpenBVE checks the updates from the list of main releases, but if I download a nightly build, then it would have to check the updates from the list of nightly builds.
I hope it is not very hard to implement the mentioned things above.

[leezer3]

Making a decision on updating itself automatically isn't really something I want to go into- There's a lot of potential issues with regards to breaking existing setups.

Thinking about it, I'm not sure it actually checks the version of the build against the current for daily builds, just prompts with the current version. (This should be updated automatically once one is pushed)
I'll try and look into that one.

[BPI-919]

Hi, I just set the driving mode from arcade to normal in OpenBVE, then I closed, after that I reopened and it crashed... :(

OpenBVE Crash- 2024.12.08[20.53].log

Can you please help me? :(

[BPI-919]

Small update: Now I rebuilt and ran, and now it works properly. Interesting...
Update-2: It only works when Visual Studio is opened alongside OpenBVE. Hmm. :/

[leezer3]

OK, fixed that. Seems to have been an issue from the start of the packages feature, I'm not sure why no-one found that before....

[BPI-919]

Is this an other kind of issue, that "Azure Pipelines" is failed or not?

[leezer3]

Not really.

Basically, we're using an Azure pipeline (machine in the cloud) to build and upload the daily builds.
The Apple instance of this is currently rather unreliable at actually managing to build the DMG ( actions/runner-images#7522 )

[BPI-919]

"
3. ObjectViewer/RouteViewer cannot launch the window in maximized
4. Object/RouteViewer's Resolution Setting is clamped to the total width/height of the window
5. Many GUI in WinForm does not respect options.cfg, such as "Mode of driving", VSync, Interpolation section, Object Parser etc. (i.e. It sets to Nearest Neighbor everytime, despite the actual settings being otherwise). This also goes for ObjectViewer & RouteViewer.
6. Object Viewer's "Keys" config, the "Backwards" fields would always follow the "Forwards" field, making it impossible to set a different value for Forward/Backwards
7. Object Viewer's "Keys" config is not user-friendly, as you must find the key through a long list of keys, and manually typing the key's name does not work.
"

From these previously mentioned things, I got these conclusions:

3. It would be a good idea to create a checkbox in the Options part of the Object/RouteViewer, with which I can set the starting mode of the Object/RouteViewer (Maximized default option would also be available).
4. Not solved yet (I tested this in the past few minutes)
5. Solved
6. This issue is still valid, unfortunately. :( (I also tested this part)
7. Not implemented yet, but it is not a critical problem.

The remained 3 points (1, 2 and 8) are not vital and we already discussed the 2nd point.

So if you had a little time, would you go on to the 4th point?
4. My resolution setting had not been saved in the Option part of Object/RouteViewer.

Many thanks! :)

[leezer3]

December & Christmas / New Year is a very busy time for me....

I think with the most recent build the options and key glitches are now fixed.
It also changes it so that the window state is deliberately set to maximised if the width / height match the display resolution.

I think the only remaining glitch is probably the slight inconsistancy in the check for updates.