openBVE 1.5.0 RC1 - BUGS

The Z-sort issue has appeared in some .x files on faces without transparency too... but as long as it's viewer-only, it's not a big issue, I guess.
I have no idea how openbve can support these loksim functions, to be honest. Especially the font objects (car number, destination window, etc). Thought of considering all the "boolean" options as true and ignoring all fonts.

Will it be reasonable to drop .l3dgrp support and make a converter for such files, which turns l3dgrp into .animated file with links to l3dobj and positions/orientations of the parts?

Making all "boolean" options true will result in a complete mess. Many LS3D objects are very versatile by having dozens over dozens of bits and pieces which can be switched on and off, and which would collide if senselessly activated. I guess we'll have to go with hacks for the legacy route format, and allow for parametrising (or what's that called in English? The word looks somewhat wrong o.O) of objects in the new XML route format.

Parametrizing is as good a word as any, although I'd probably just use adding parameters personally
A better name *might* be keywords, but these are rather a Loksim related concept.

I think the way this may have to be done is to add a supplementary container format (as per animated), which contains a keywords & mapping list.
Probably a nasty amount of work though......

Anyways, I've got the basic model linked now working OK with a little bashing around, other than the known issues with visibility bits.
The 'missing' doors etc. seem to be a result of the Z-sorting algorithm being a little funky, so for the minute at least all static components of a Loksim model are now merged into a single lump.

Will get that added to the main builds later today

Over the last few weeks I've been noticing some graphical glitching occuring, so far I've only noticed this on the network west midlands routes and Birmingham cross city south routes others that I've tried don't seam affected. This seams to affect all the V1.5.2.x builds including the one dated 2nd October although this build does seam slightly better, the attached screenshot was taken with this build. The glitch only occurs for a few hundread metres of the track and only in certain areas, the rest seams to be fine although there does occasionally seam to be objects that are missing / not rendered.
I have tried turning off the attempt to correct transparancy issues and attempt to correct buggy content options with no sucess. However turning off the attempt to correct buggy content option doesn't seam to be saved.

I'd try updating your GPU drivers as well. If they are up to date, consider trying to downdate them to a driver version before the glitches started and check if that helps. It might narrow down the problem.

Hacks option fixed for this build:
(It was actually saving for the current run, but not on restart)

https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-10-04.zip

leezer3 wrote:

That looks strongly to me as if your graphics card is having issues when heavily loaded. Both NWM and Birmingham X-City are high-load routes.

I can't think of any way in which any of the changes in the 1.5.2 series could cause this, but I stand to be corrected

Whilst I'm reasonably certain this isn't openBVE, any chance of a routefile / track location please?

Sure, the screenshot was from the route file  12.00 [HST] 1A34 Maybank-Hammerwich XP on the approach to Riverside station, just after the final overbridge before the station although it does occur at other places
I've also noticed it in this route file also 06.55 [323] 5C17 NortonCS-Hobbs CrossP3 ECS on approach to Hobbs Cross.
These places do appear to be repeatable.

Quork wrote:I'd try updating your GPU drivers as well. If they are up to date, consider trying to downdate them to a driver version before the glitches started and check if that helps. It might narrow down the problem.

I had the latest version 17.7.2 installed dated July 2017, which might explain why I've only noticed it recently, as I've not really had the time since May. So I tried installing 17.2.1 dated Feb 2017 I think this was likely the driver I was using the last time I used openBVE before I saw the glitches.  It looks like you may be right Quork, that the glitches are a driver fault, as the glitches are not present with this older driver.

So it looks as this could be a driver issue.

Everything looks entirely normal with those two routefiles and some random Birmingham X-City ones at this end, sorry.

I have found a couple of small unrelated issues as a result of testing them though, so can't be too bad

If you're getting at what I think you are, this is a somewhat fundamental problem with the properties of a circle, and not easily fixable.

TLDR explanation:

The player's track (Rail 0) forms a curve with a radius of 600m.
If the outer track also had a radius of 600m, something a little like this would happen:


(Excuse the atrocious diagram, positions obviously exaggerated for effect....)

Therefore, the curve radius of the outer track is actually marginally greater than 600m. As a consequence, it's length is also marginally longer.

Similarly, the curve radius of the inner track is marginally smaller, and it's length slightly less.

This manifests itself in the seams that you're highlighting.


The only real internal fix for this would be to manually calculate the lengths of each track segment, and scale the track pieces appropriately.
However, there's an issue with this one:

Should we take the curve, or the straight red line?

Secondary tracks in the current routefile format have no concept of a curve, so there's absolutely no way to tell.

Glad I could help.

Considering Dex' problem - the way I see it, there is no way of changing this without profoundly changing the way rails are handled. Rails are, and AFAIR have always been simply objects put one behind the other in BVE and its formats. They're repeated every X metres, with X being the block length; and that length is simply measured along track 0 and then moved perpendicularily by the lateral distance. Thus the spacing will never be right in curves; on the other hand, having correct spacing would mean the objects get out of sync with the block system, generating a big bunch of problems. In comparison, LS3D handles tracks as a special kind of object and they're bent along curves (no stretching required since there's no blocks as in BVE).
I think the most sensible option is to add two options to objects: Being bent along curves or by a factor set manually, and being stretched along curves or by a factor set manually. Why both as separate options? Because there would be much use to those options in other things as well. To come back to the comparison with LS3D; the algorithms for those operations are in place, but you can't access them, they're hardcoded for rails only. So if you want to do catenary, you need specialised, single use objects for every situation, leading to hundreds or thousands nearly identical catenary objects for high quality routes, created with a special tool (which again doesn't allow creating other bent or stretched objects...). That was no issue back when this was coded, because no one could imagine there'd ever be the computational power available for such detailed routes. But if one was to code this today, as Chris would maybe consider doing for BVE, we should think about such uses as well, and especially keep in mind people might have usages for such option that we'd never have thought of. Thus such features should be done as universally usable as possible. Stretching without bending would be great for catenary objects; you could create a basic set of a few dozen objects (like: straight without zigzag for curves, right-left and left-right for zigzag, transition parts between straight and zigzag, right and left hand switch (joining to straight, to zigzag, to different on different ends...), crossing, etc. etc. etc.) and then you'd just need to stretch them to fit them into the route. And while I have no idea what the hell one would want with bending without stretching, I'm pretty sure sooner or later someone would come up with an idea and ask "why can I stretch and not bend, but not bend without stretching?! I need it for XYZ!".

EDIT

Obviously that's a very profound change, so that's nothing for the current route format. It would be a great adition for the new format (which I hope will leave blocks and the concept of "track 0" on history's dump and allow for multiple usable tracks in one route file).

leezer3 wrote:Everything looks entirely normal with those two routefiles and some random Birmingham X-City ones at this end, sorry.

I have found a couple of small unrelated issues as a result of testing them though, so can't be too bad

Thanks for looking. I think the problem is with the graphics driver and my paricular set up, as no one else appears to be having problems. At least you've managed to fix some other problems.

I have also come across this issue on my WIP route. On this route I have several very tight double track curves (as low as 160 metre radius) with the same gaps/ overlapping on the adjacent track. The best solution I could find was for tracks with radius less of than about 500 metres was to create different length objects. These longer/shorter pieces are used only on the adjacent track and results in no gaps/ overlapping. The running rail uses a separate different standard length track.

I also lowered one end of each object by a few mm so overlapping textures don't z-fight. Above 500 metre radius using the same object for both tracks works well. I found that making tracks for tight curves using the same object for both tracks just wouldn't work because if you make them too long so they fit the block the sleepers are not spaced properly. Hope that makes sense but as a result on those double track tight curves I see no gaps. I did try the short piece of rail but I wasn't happy with that.

It's quite mathematically possible to get the radius and lengths of our curves:
http://mathworld.wolfram.com/ParallelCurves.html

The problem is far more what to do about them.
All track in openBVE is currently laid as a complete segment of object, and hence we'd have to deform the object in question, which is a much more computationally expensive operation than just cloning and placing it within the world.

Yeah, using different object length is what I have gone with, but it does not exactly fill me with joy

To decrease the workload one could go with simplifications. I'm thinking along the lines of dropping bending for radii bigger than a factor X times the object's length and using simpler approximate functions for bending (parabolic comes to mind) for radii bigger than a factor Y times the object's length, with X > Y. X and Y could be user-set in the advanced tab, allowing users to balance accuracy and fps according to their computer power. One would need to draw it and experiment a little, but I guess 3 for Y and 10 for X could be sensible default values.

I was using the lowering of the far end of the rail as well, but it did bring the worng sleeper spacing as well.
Neverthelles, same spot now...

Chris, something I noticed with openBVE 1.5.2.1: in the installer I selected a custom location for the Railway and the Train folders. However, when I start openBVE the route selection box and the train selection box are still in AppData/Roaming/openBVE.

Would it be possible for openBVE to jump to the set Railway and Train folders? Another idea would be to automagically create the Object, Route and Sound folders and jump to the Route folder in the route selection box.

Speaking of folders - I am the only user on my W10 machine, so I have the admin rights, logically. Yet still whenever I open the Object or Route Viewer, it does not start in the folder I was last in, it resets to a default folder.That is slightly annoying... :-D

I just installed OpenBVE 1.5.2.1 on Ubuntu 17.10 (Beta 2) using the .deb package. It installed fine and I also installed a few route/train packages. When I selected a route and a train and hit the Start button I got an error message:



Clicking on it took me back to the route selection screen.

Do you have OpenAL correctly installed?

That is a good question. I looked for OpenAL related packages but didn't have time to install a decent package manager, and the default Gnome Software is not much use. But I guess all necessary packages are marked as dependencies in the .deb. It definitely didn't complain about any dependencies.

Hmm, that's interesting, and I suppose my fault

openAL isn't set as a dependancy; I just used the original Debian package template, which doesn't call for it.

You want libopenal1, although I'm marginally surprised something hasn't already installed it.
Will see if I can detect this error specifically and provide a more useful prompt. Current build now has a better error message for missing general system libraries, and a specific error for openAL


Will also add libopenal1 to the dependancy list.