Route testers needed

Evening all,

I'm after some testers to give my Isle of Wight route a try, I'm having a couple of issues and need help from more experienced developers...

Any willing volunteers?

Download link - http://s000.tinyupload.com/index.php?file_id=26548923105636042273

Basically, the main issue is on the approach to Brading, as you pass under the road bridge, OpenBVE freezes, anyone care to take a look for me, I've rebuilt the whole area with to no avail...

Thanks in advance,

Adam

I can see a slight hitch there if running on max speed, but nothing else.

If you look, that's where you hit the maximum number of polygons on screen at once.
If it's hitching more than you think acceptable, you basically need to cut back on the number of trees in the area, as that's whats causing the issue.
The number of transparencies on the trees won't be helping matters either- A face with transparency is an order of magnitude more complex to render than an opaque one

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Chris, out of curiosity - for trees not seen that closely (second and further rows in forest scenes, or ones not concealed but >30m from the track axis) it would be possible to shape a rough object with opaque texture, a polygon consisting of maybe a dozen triangles. Would that decrease the load, compared to a tree with transparencies but only one polygon (rectangle, two triangles)? Or better put: What is the factor by which load increases per rendered triangle when adding transparencies? If the number is say 10, I would create some non-transparent trees based on my tree textures for distant use.

leezer3 wrote:I can see a slight hitch there if running on max speed, but nothing else.

If you look, that's where you hit the maximum number of polygons on screen at once.
If it's hitching more than you think acceptable, you basically need to cut back on the number of trees in the area, as that's whats causing the issue.
The number of transparencies on the trees won't be helping matters either- A face with transparency is an order of magnitude more complex to render than an opaque one

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Ah I see, thanks for looking, I've already reduced the number of trees in the area once, looks as if I'll have to try again, thanks.

Quork wrote:Chris, out of curiosity - for trees not seen that closely (second and further rows in forest scenes, or ones not concealed but >30m from the track axis) it would be possible to shape a rough object with opaque texture, a polygon consisting of maybe a dozen triangles. Would that decrease the load, compared to a tree with transparencies but only one polygon (rectangle, two triangles)? Or better put: What is the factor by which load increases per rendered triangle when adding transparencies? If the number is say 10, I would create some non-transparent trees based on my tree textures for distant use.

Short answer is not sure, but I'd expect it to be approximately 3-4, maybe even more.
Longer answer:
Opaque faces are rendered using a single pass, and OpenGL display lists.

Faces using transparency on the other hand require several distinct extra passes:
1. A sort is run from furthest to nearest.
2. Fully opaque pixels are rendered with Z-buffer writes enabled.
3. Transparent or semi-transparent pixels are rendered with Z-buffer writes disabled.

No OpenGL display lists are used with these.

You could probably run quite a reasonable test by generating a forest with ForestBuilder, and editing the trees to remove the transparencies between runs
To a certain extent though, remember that we're talking milliseconds per tree difference.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Hallo Adam,

I have also tested your railroad -- I must say, really nice work.

A few things about it:

(1) As Quork already mentioned you can reduce the trees, especially in the second and/or third row. That would increase performance and no one would notice that little lack of detail.

(2) During my test run there was also a sudden decrease of frame rate on top of the street bridge that appears after Lake station. Maybe there is an object that has faces with "wrong" orientation ... as far as I know you can use the "face2" command for your objects instead of "face" if you are in doubt about orientation. (Is that right, Chris?)

(3) I seems to me as if you did not ship signals with your line. Because I do not have the wanted "brsigs" folder on my system I could not test them. (I only got error messages on this -- can I obtain those signals somewhere?)

(4) There is a little problem with your station/stop layout. You have placed your .sta and .stop commands several times at the _same_ location. That may cause erratic behaviour of that blue "station bar" that appears in normal/arcade mode. They should be separated like this:

Code:

;; platform starts here
2300,
.Sta Sandown;09.43;09.44;;1;1;;;15;30,

;; stopping area
2400,
.stop 0;10;10

(5) You have shipped an executable program called "converter2.0r.exe" inside your 38TS subdirectory. Is that intended?

(6) There are a few large *.bmp files. They could be converted into *.png files to save disk space and download traffic.

Hope I could help you.

Greetings from Germany

Sando

Short answer to the use of face2 is yes, that's correct

BRSigs (To be exact, that's BRSigs, BRSema4Sigs & BRSigs_Open):
http://www.bvecornwall.co.uk/downloads/BRSigs.7z

Extract to the root object folder.


Now that _sando_ mentions BMP files, I now notice that Braiding station is horrific
You're using **17mb** worth of BMPs for a single building, and none of them are to the power of 2 either.
When the sim loads Braiding, it'll page in all 17mb of those BMPs, and then resize them to a power of 2....

Assuming I remember, I'll post a rather optimised Braiding station building tomorrow

Cheers

Chris Lees

http://www.bvecornwall.co.uk

_sando_ wrote:Hallo Adam,

I have also tested your railroad -- I must say, really nice work.

A few things about it:

(1) As Quork already mentioned you can reduce the trees, especially in the second and/or third row. That would increase performance and no one would notice that little lack of detail.

(2) During my test run there was also a sudden decrease of frame rate on top of the street bridge that appears after Lake station. Maybe there is an object that has faces with "wrong" orientation ... as far as I know you can use the "face2" command for your objects instead of "face" if you are in doubt about orientation. (Is that right, Chris?)

(3) I seems to me as if you did not ship signals with your line. Because I do not have the wanted "brsigs" folder on my system I could not test them. (I only got error messages on this -- can I obtain those signals somewhere?)

(4) There is a little problem with your station/stop layout. You have placed your .sta and .stop commands several times at the _same_ location. That may cause erratic behaviour of that blue "station bar" that appears in normal/arcade mode. They should be separated like this:

Code:

;; platform starts here
2300,
.Sta Sandown;09.43;09.44;;1;1;;;15;30,

;; stopping area
2400,
.stop 0;10;10

(5) You have shipped an executable program called "converter2.0r.exe" inside your 38TS subdirectory. Is that intended?

(6) There are a few large *.bmp files. They could be converted into *.png files to save disk space and download traffic.

Hope I could help you.

Greetings from Germany

Sando

Thanks, plenty to look at.

1 - Already made a start.
2 - The bridge it's self is very frame heavy, I'll have a go at reducing the number of faces.
3 - It uses the BrSigs that were available, I didn't think to include these with the route, I'll drop the required signals in with the objects.
4 - Hadn't noticed this, I'll look in to it.
5 - Oops, that's quite an old tool for converting and mirroring objects - not mine though so it shouldn't have been included!
6 - Done a fair bit of image reducing already, I didn't want to because I wanted high-res textures, but I've since noticed it doesn't really make much difference in game.

Thanks for the feedback!

Adam

I'm not sure if I remember correctly, but you should first check the BrSigs license before redistributing it. I remember at least one popular signal set (might have just as well been BrSemaSigs) was permitted to be reused, but not to be redistributed, so it always had to be obtained separately. On the other hand, didn't someone on these boards do a fully compatible remake?

So, this is the optimised version of Braiding I mentioned
(BraidingL3.b3d)
http://www.bvecornwall.co.uk/downloads/external/OptimisedTest.7z
Total texture size is down from 17mb to 0.98mb, along with a bunch of smaller mesh tweaks, and I can see basically no difference. A factor of 17 difference I think is quite impressive

A few notes on what I've done-

1. Halved the width of the roof texture & canopy edging, compensated for using tiling
   
2. Combined all 4 parts of the platform top surface into a single mesh- Saves duplicate vertices and two texture loads.
   
3. Resized the end & canopy textures to avoid extra bits- Also take a look at the way I've shaped the end and canopy supports, and used texture mapping to shift them around. Doesn't do much, but looks much better occasionally.
   
4. Most textures reduced in size considerably.
   

I would start doing some more aggressive rebuilding, but it's your object

You'll also benefit from using a common texture folder, as you've got various duplicate textures, which will be being loaded into memory twice uncessarily.

Quork wrote:I'm not sure if I remember correctly, but you should first check the BrSigs license before redistributing it. I remember at least one popular signal set (might have just as well been BrSemaSigs) was permitted to be reused, but not to be redistributed, so it always had to be obtained separately. On the other hand, didn't someone on these boards do a fully compatible remake?

Who, what, me again??
All variants are as far as I'm aware free to distribute, however, a fully 3D open source version of BRSema4Sigs is here:
http://www.bvecornwall.co.uk/wordpress/openbve-semaphore-signals/

Cheers

Chris Lees

http://www.bvecornwall.co.uk

leezer3 wrote:So, this is the optimised version of Braiding I mentioned
(BraidingL3.b3d)
http://www.bvecornwall.co.uk/downloads/external/OptimisedTest.7z
Total texture size is down from 17mb to 0.98mb, along with a bunch of smaller mesh tweaks, and I can see basically no difference. A factor of 17 difference I think is quite impressive

A few notes on what I've done-

1. Halved the width of the roof texture & canopy edging, compensated for using tiling
   
2. Combined all 4 parts of the platform top surface into a single mesh- Saves duplicate vertices and two texture loads.
   
3. Resized the end & canopy textures to avoid extra bits- Also take a look at the way I've shaped the end and canopy supports, and used texture mapping to shift them around. Doesn't do much, but looks much better occasionally.
   
4. Most textures reduced in size considerably.
   

I would start doing some more aggressive rebuilding, but it's your object

You'll also benefit from using a common texture folder, as you've got various duplicate textures, which will be being loaded into memory twice uncessarily.

Quork wrote:I'm not sure if I remember correctly, but you should first check the BrSigs license before redistributing it. I remember at least one popular signal set (might have just as well been BrSemaSigs) was permitted to be reused, but not to be redistributed, so it always had to be obtained separately. On the other hand, didn't someone on these boards do a fully compatible remake?

Who, what, me again??
All variants are as far as I'm aware free to distribute, however, a fully 3D open source version of BRSema4Sigs is here:
http://www.bvecornwall.co.uk/wordpress/openbve-semaphore-signals/

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Chris, I thank you!  I appreciate your help, I've copied the optimized station into the route and it does indeed run a little smoother.

I didn't realize I still had to abide by the power of 2 rule, with OpenBVE I was under the impression that the textures only had to be an even number of pixels in height and width... I've learnt something today!

No problem for me, it is as smooth as butter on my PC.

ap1991 wrote:Chris, I thank you!  I appreciate your help, I've copied the optimized station into the route and it does indeed run a little smoother.

I didn't realize I still had to abide by the power of 2 rule, with OpenBVE I was under the impression that the textures only had to be an even number of pixels in height and width... I've learnt something today!

No problem
Whilst this is wandering off topic a little, it's relavant:

The power of 2 is a fundamental part of graphics architecture-
http://gamedev.stackexchange.com/questions/26187/why-are-textures-always-square-powers-of-two-what-if-they-arent

To get the reason for this, we need to step back a little further, and think about what a computer processor works on at the basic logic level-
Binary (Zeroes and ones), which obviously ties in with the power of two rule, with two possible states for a bit.
Once you dig deep enough behind the scenes, most things on a computer conform to this- For a completely different example, look at the sizes of hard-drives; They're made up of a number of platters, each of which is a size conforming to the power of two rule

Now, in the modern world, this 'rule' isn't so much of a problem as it once was, as all we actually need to do is to break or resize our texture internally to conform to this, and indeed OpenBVE actually resizes any textures on loading to conform to the power of two rule.
This however consumes resources every time the texture is loaded, and you also loose control over the resizing process- For a quick example, make a texture with complicated transparencies, and let the engine resize it, versus resizing it yourself. You'll normally see artifacts around the edge, and often the resized quality will be much poorer

Cheers

Chris Lees

http://www.bvecornwall.co.uk