Updated RouteViewer- Testers Please

Any chance of a couple of people trying out this updated version of RouteViewer please?
http://vps.bvecornwall.co.uk/OpenBVE/Experimental/RouteViewer_1.4.5.zip

I've spent today porting across the openBVE loading screen features (No custom load screens just at the minute, I want to make sure I haven't broken the simple stuff first), plus made various small improvements in the options dialog and the text rendering functions.
There should be no changes to route or object handling, just need someone else to test that it's not completely broken before I think about pushing this as the 'stable' version.

Cheers

It loaded up the first route I tried it on (Kilmagranny, as it happened). However, there are some tree objs which I seem to remember used alpha transparency and these don't render correctly - although the old route viewer worked with them.
I placed the Viewer in the folder with the 1.4.230.722 Program. The two files included with the viewer, OpenBveApi.dll and SharpCompress.Unsigned.dll were not installed as I wasn't sure if I should overwrite the existing ones.

I installed the program in with 1.4.233.1350 overwriting the 2 dll files already in place. I tried this on my route and displays correctly after I changed the interpolation settings. The default settings resulted in transparency not displayed correctly further away from the camera. I also tried it on Kilmagranny with no issues including the trees. I loaded your Plymouth route also and displays correctly.

Thanks
It looks like the tree texture in graymac's image failed to load, and it just grabbed the first texture in the buffer. 

I suspect it'll either be a one-time thing, or possibly related to a settings combination. The texture loading in Route Viewer is not nice code...
Will do some testing.

IIRC the default settings are producing what I'd expect, but will check.

The DLL files don't matter either way, assuming you're on one of my builds they should be identical, just zipped them for completeness.

I have done some more testing and I loaded my route several times and in one of these times a ballast texture didn't displayed correctly. It looked just graymac's tree texture issue. This only happened in only one face even though the texture has been used in other objects. I also just occasionally get a few faces that uses setcolor change to white and/or blinks white when you move the camera to a certain place and then the texture returns back to normal when you move the camera to another place. These were in my route but didn't happen every time. I also tried your route but without issues.

Also the program crashes if I use F7 while it is loading a route. In the interpolation settings if I select intermediate the route doesn't reload and when I return to the settings it show one of the other settings instead. Sharp and smooth work correctly and the route reloads after I select OK.

I agree now that it's likely a "loading problem" and not (as I first thought) a "transparency issue" - the mis-rendered object had no texture detail either in the solids or the transparent part, it was all missing as only the faces had loaded. So, faces load but not textures????
On a second run, I adjusted the settings to allow anisotropic filtering (which is how I run the program proper). The trees showed correctly this time. However, near a level crossing after the 9km point another texture was blacked out. On a third try, this was fine, but another run brought the tree texture back-to-black. This time, instead of closing the viewer, I used F5 to re-load and the texture came back up properly.

The texture loading in Route Viewer is not nice code...

Bet the problem's in there somewhere, worse luck!!

On the plus side, it's great to be able to use a viewer at a larger window size than the original, so I'm delighted to see this project coming to fruition.

OK, please try again, same link above

Replaced the entire font handling/ text drawing subsystems in RouteViewer with those from the main program (Considerably more sane....), and that seems to have fixed the issue at this end.
Something very screwy was going on when it failed to load a texture, not exactly sure what. Highly intermittent too, which is probably why Matt never saw it

Have also fixed a couple more of bugs that came to light:
* The selected level of antialiasing was always applied, no matter if selected or not. (If your textures look worse with this build, that's why.)
* The main program was never using mipmapping, unless antialiasing was selected. The mipmapped options will look marginally better in the next build.

That seems to have done the trick!
Tried the same route as before, no probs. Did a few jumps to random viewpoints and nothing seems to have been missed or mis-rendered. Also did a short flick through the Cheltenham route and no probs visible there either.

Something very screwy was going on when it failed to load a texture, not exactly sure what. Highly intermittent too, which is probably why Matt never saw it

The intermittency of the problem was evident in the short time I tried the previous build.

I saw the issue of a texture failing to load just the once in only one face even though the texture has been used for several objects as I have said above. The issue with the setcolor may be related to this issue but that only happened sometimes. I tried my route and Kilmagranny with your updated version and no issues were found with faces.

The crash when using F7 while it loading a route and not being able to select Intermediate in the transparency setting happens also in this version of the viewer.

I have tested this new version and so far the only issue I have found is related to the loading screen. I have noticed that the loading screen is shown every time the route is reloaded via F5, and objects too close to the camera before reloading somehow manage to appear in front of the loading image.



I find the loading screen a bit annoying when the same route is reloaded, but it is just my opinion.

Marc Riera wrote:I have tested this new version and so far the only issue I have found is related to the loading screen. I have noticed that the loading screen is shown every time the route is reloaded via F5, and objects too close to the camera before reloading somehow manage to appear in front of the loading image.



I find the loading screen a bit annoying when the same route is reloaded, but it is just my opinion.

Loading screen being shown every time is deliberate; I think it's better than the whole program freezing up whilst it loads, and it provides a visual indication of what's happening.

Could add an option to disable it if it bothers you

Found and fixed the issue with the objects close to the camera (Forgotten to disable depth testing...), and have also fixed the crash if you use the options screen whilst it's loading.

Intermediate transparencies don't actually seem to be implemented though. (The enum member is there, but not the code to make them work...)
Don't worry too much about that

Build above has been updated with these fixes.

I have been using this version of the route viewer without more issues. When reloading a route I would rather not have the loading screen reappear each time though I am used to how it has been with the older versions. When working on a route I am used to seeing how the details in the route changes upon reloading the route. But you know more about this than me. Thanks for all your efforts.

MattD6R wrote:I have been using this version of the route viewer without more issues. When reloading a route I would rather not have the loading screen reappear each time though I am used to how it has been with the older versions. When working on a route I am used to seeing how the details in the route changes upon reloading the route. But you know more about this than me. Thanks for all your efforts.

Fair enough, that's a very logical use-case.

Will add an option later.

Cheers

I'm using the route viewer regularly right now (in preference to the original) on a new WIP.
Like Matt, I'm also not amused with the loco pics popping up when F5 reloading, I find it a bit distracting. If a loading image is really necessary, perhaps a plain ground with nothing more decorative than (perhaps) the word "loading" showing????
Viewer is working well, no probs with multiple (accumulative) reloads or anything.

Could a progress bar be overload in the (updating) route view?  That way you can see it's doing something, and hasn't frozen, but you can also see the changes happen?  Best of both worlds?
It sounds like it's the background image itself that's the contentious issue?

Of course, you can change the images too, I've replaced mine (sorry Chris) with British Rail era moquette patterns.

My initial aim was to stop everything from completely freezing whilst loading, and on large routes & slower machines the progress bar is IMHO absolutely necessary.
(NWM takes several minutes to load on the laptop, and a hard freeze is *not* good, even if it does come back again)

I think it's also important for new users attempting to use Route Viewer not to be presented with something that appears to freeze whilst loading, as you run the risk of it being mistakenly discarded as not working.

Overlaying the progress bar onto the view isn't dead simple (I think I'll have to render the last scene to a texture and use this as the background, will think about it), but it should be do-able.
I'm sure I can oblige with options to suit all, although it may take a day or two

I do like the progress bar you have added to the route viewer because you can see it doing something as you said. The loading screen I don't think should be used when reloading a route with the viewer which I find slightly annoying but that's only what I think. I don't mind the loading screen when you are loading a route for the first time. As it been said it would be good if the progress bar was overlaid onto the view of the route so that I can see the change to the route when it is reloaded. I been using this version on the building of my WIP route and is working very well.

I really appreciate additional informations shown by this new version of Route Wiewer, as well as the ability to set up interpolation options and video resolution.

As the F5 key is usually used by developers to test changes made to a route file or to some object placed in it, the direct visual feedback of changes made is, in my opinion too, important that it is not distracted from a standby screen.

To locate a possible loading lock, I'd suggest, if possible, to change the static label "Loading ..." appearing in the upper left corner of Michelle's original version, with a dynamic label "Loading 0%", Loading 1%, Loading 2%, and so on until "Loading 100%" is reached.

OK, took me a couple of weeks (Sorry.....)

Build has been updated again:
http://vps.bvecornwall.co.uk/OpenBVE/Experimental/RouteViewer_1.4.5.zip

All 'new' loading screen options are now optional, so you can choose whether to have the following:

• Backgrounds
  
• Progress bar
  
• Central openBVE logo
  

Don't think this version should cause any trouble, but it's been compiled with VS2015, as I'm away until next Friday, and that's the only thing on this laptop.....

Using it now on "KIlmagranny 2016" WIP, works fine for me! 

Your update is working well on my WIP route. It is intentional that you get a white screen if you don't select any loading screen checkboxes? Also if I only select the progress bar I get the progress bar and the white screen. Selecting the 'Show Logo' without background selected results in the logo shown on the white screen with some of the logo not visible against the white background.

If I change the loading screen settings in F8 window and press OK and then go back to the setting window the previous selected checkpoints are unselected. If I don't change any settings and I then exit the setting window without pressing OK the settings previously selected are used. But if I press OK after I have not selected any checkboxes then none of the loading screen options are used.