Curved Tracks using new idea (post sprites)

[vinaximus]

Hello, I know little about programming and the developers must have thought about it before me. But this came to my mind

The idea here is to identify those tiles on the view port that have turning tracks, junctions. And then replace these tiles on screen after all the graphics for that viewport are drawn. Something like this

-Draw all the sprites and graphics
-Identify the required tiles which needs to be replaced
-Draw the new graphics where required
-Draw the trains

As a result: The player will see curved tracks on the screen, even though there are no actual curved tracks. Its like drawing a red circle (which is part of a grf) and then drawing a blue one on top of it.

[lawton27]

This would be well implemented as a newgrf railtype (or infact just replacement for standard rail using rail types).

As much as it goes against the original look and feel of OTTD I'd like to see someone put this together just to see how it looks in game, it will never be loved by all but it might be useful for some screenshots or simply as a gimmick.

[Zephyris]

This was the reason I suggested that the specs for new rail graphics included a check neighbour tile. I think there was a performance argument against it though.

[Eddi]

that argument has been discussed quite controversial.

i have a concept sheet somewhere how a grf would look like using such a neighbour check, but it needs a lot of work (and especially some graphics)

[Ben_Robbins_]

A similar idea crossed my mind a while back, and I had a load of renders and diagrams to describe some considerations, but alas, they sit on a permanently comatosed computer at the moment. Am I correct in thinking the amount of sprites required to be made would be huge do to curves coming out of, or going into junction combinations, or am I overcomplicating the suggestion? (this is considering the avoidance of graphical glitches in full zoom, caused by track segment overlays as in complex junctions currently)

The idea I was thinking about was having each tile baked from sub-sprites, where a tile is made up of 5 sub-sprites. The tile would be divided diagonally into 4 from each corner across, with a central square, aligned with the tile, making the 5th section. A diagonal track piece going into 2 perpendicular straight pieces on each neighbouring tile, would result in a curve missing the 5th sub-tile, only effecting 2 outer segment sub-tiles for example, where as a cross roads would effect all outer segments sub-tiles, and the 5th.

This would allow for multiple combinations where potentially exponentiating variables are segmented off to avoid the huge sprite counts. The idea of baking them, was due to the frequency of certain combinations, and rarity of others. For parallel tracks without junctions, this method would only smooth the 45' track bend, it wouldn't make them parallel, unless additional sprites where made, and somehow it tracks were understood as working together. Slopes within a combination would add some fun as well.

[Arie-]

I was wondering that as well, how many additional angels do you expect?

curve.png (13.82 KiB) Viewed 7250 times

[planetmaker]

Is there any relation of the image you posted to OpenTTD's track tiles? What is it supposed to illustrate?

EDIT: here a version of pieces which would be required. Gray lines are tile boundaries. Different sprites are coloured differently. They'll need be made available for the other three curves as well and the other diagonal directions. Most of the circles are only "help lines"

[Zephyris]

Re: Arie-'s diagram.

Diagonal tracks in OpenTTD go from edge to edge, not corner to corner.

IMO the only corners that would really benefit from curved graphics would be the two I have shown attached (red squares indicate new, curved, graphics). Junctions have a crazy number of possibilities, I am not sure they would be worth the effort.

[Gremnon]

I could be wrong, but I see a problem with both of those. In the left, it's going to look very strange when doing long diagonal stretches unless the track tiles can tell when they're being used that way (which I don't think they can yet). In the right one, it's much the same - the straight-track tile isn't going to know it has to use a different sprite to provide the start of that bend for the same reason.

[planetmaker]

Pre-condition and actual starting point of this discussion:

This was the reason I suggested that the specs for new rail graphics included a check neighbour tile. I think there was a performance argument against it though.

(Highlight mine)

[Eddi]

Well, in my mind, each trackbit would consist of two parts, each going from the middle of the (half-)tile to one of the edges. the center of the trackbit is always fixed, no matter what. the edge is varying between 3 possible states:

• for trackbits in X/Y direction: adjacent tile has same direction: track-half is straight (like currently), otherwise it is offset by a certain value to one or the other direction.
• for trackbits in "diagonal" directions: likewise if the adjacent tile has the same direction, the track-half is straight, if the other direction is X/Y it is offset by the same value, if it's a 90° corner it's double the value.

the track-half is somehow "smoothly" connecting the center to the offset at the edge, the offset value is chosen so it looks somewhat smooth between the adjacent tiles, and not too big, because vehicles would go "off" the rails. (Note: by this method, Zephyris' first picture can't be possible, but the second picture can)

this means based on 6 trackbits you need 6*2*3 = 36 curvy-rail half-trackbits

"combinatorial" tiles (full trackbits, switches, etc.) should be precomputed, so the game does not have to assemble them (performance), this means that the above sprites should be split in two layers (rails and sleepers, trackbed-edge and trackbed-base) so they are easier to combine. this can be scripted, or for really insane people it can be hand-drawn.

so 6 trackbits, 2 track-halves, 2^3 adjacent track configurations per side makes 6*8*8 = 384 track sprites and same number of trackbase sprites, made from 4*36 = 144 actual pixel art layers.

combinatorial explosions will get worse if you want to provide all potential crossings as one sprite but the number of drawings will not change, if the combination is scripted

[Ben_Robbins_]

I'm not gunna lie, I'm slightly unclear on that description Eddi; some clarity, maybe as a diagram would be appreciated on that.

In terms of the number of sprites required. If each tile considers it's neighbour, and has all variations I get numbers in the millions, as there are 7 different local options which can align to any 1 edge, each having to consider the neighbour edge with it's 7 options, and then appear on a tile with 3 other edges each considering the same. So =(7^2)^4.

The 7 combo's are from the 3 directions = \l/ = a b c, so (a,b,c,ab,ac,bc,abc) ('none' can be treated the same as 'b' by the neighbouring edge, so not counted). This considers 180 turns are allowed, and the graphics support this. There are considerably less if they are not allowed, however as a game option is to have them, there would potentially need to be a graphics set of this size.

I have just forked out a load of money and got access to the files I previously mentioned, so I can visually show what I was talking about. It complies with the aforementioned Pre-condition, and requires tiles to monitor there neighbour. It moves the point at which all tracks meet, from the tile edge to a point inside the tiles on the diagonal. Then brings the original edge points into a smaller central tile. (basic change.png)

It would then lead to the outcome as in image:tile.png
These would combine to look something like this: (180's off) http://i57.photobucket.com/albums/g226/ ... urves2.png

There are a couple of hundred sub-tiles then required, however they are mostly assembled from a few renders. In fact it's 39 renders, with only 9 pieces rendered at 4 angles, with 3 additional centre tiles. There would be 160 connection points need rendering (where tracks have gap in for wheels to run through), although all done in one render, and then assembled post-render.

There are 2 issues I have stumbled upon. I have attached a string of images to describe the first 1, because writing it out makes it more confusing that it should be:

(All in the raillayout.rar file)
answer1.PNG - How a junction would appear with 180 degree turns allowed and appearing
answer2.PNG - Adding an additional track, with 180 degree turns allowed and appearing
answer3.PNG - Turning off 180 degrees, and not having them appearing
answer4.PNG - Adding an additional track without 180 degrees allowed. (Pink section therefore simpler)
answer5.PNG - Removing the 2nd half of the additional track just added leaves Pink section sticking across curve, requiring a new set of pieces.
answer5a.PNG - Having some means of seeing this issue, and therefore cutting that track short
answer6.PNG - The appearance of a singular 180 degree turn with out 180's allowed, or appearing in the graphics set.

The 2nd issue is shown in this image: http://i57.photobucket.com/albums/g226/ ... kissue.png
Here 2 parallel tracks take a corner together, however if a perpendicular line was drawn between the 2 tracks at any point on both the 2 directional sections of tracks. The distances along the track between an end of the perpendicular line would be different on each track, and therefore to have nice tracks it wouldn't work with any of the above methods. There would need to be specific pieces for this situation, and a means of the game identifying tracks that work together. Possibly done by having a way-point group the tracks?

[YNM]

These would combine to look something like this: (180's off) http://i57.photobucket.com/albums/g226/ ... urves2.png

Quite much what I have in mind.

The number of curved rails to make is :
4*2 views of initial curved tracks for horizontal and vertical tracks (N-S and E-W)
4 full curved diagonal tracks (left-right NE-SW and left-right SE-NW)
4*2 initial curved track for diagonal tracks (2*left-right NE-SW and SE-NW)

Also as a possible addition, half-tile horizontal and vertical tracks.

[Eddi]

your tile.png pretty much shows what i said, except i didn't separate the center crossing.

wrt combinatorial explosion: if you consider the full tile, you have 6 trackbits on the tile, and 3 (relevant) trackbits on each adjacent tile, making 2^6*(2^3)^4 potential states, so 2^(6+3*4) = 2^18 = 256k as upper bound, but quite large parts are irrelevant

[Eddi]

a try at a lower upper bound:

depending on the track configuration, you have 3 cases to consider:

• two adjacent tiles (simple straights and curves): 6 potential trackbits, twice 3 neighbouring trackbits = 6*(2^3)^2 = 384
• three adjacent tiles (simple switches or triangles): 4 directions, 4 trackbit combinations (full triangle or one trackbit missing) per direction, three times 3 neighbouring trackbits: 4*4*(2^3)^3 = 2^(2+2+3*3) = 2^13 = 8192
• four adjacent tiles (complex crossings): X/Y cross, 2 directions of parallel tracks or at least 3 trackbits present minus the 4 trigangles from above: 1+2+(20+15+6+1)-4 = 41 track configurations, so 41*(2^3)^4 = 41*2^12 = 39*4096 = 167936

so 384+8192+167936 = 176512 sprites.


but you should consider that most of the 4-tile variants are really rare, so do you really want to create individual sprites for each of them?

[Eddi]

and a different approach, this time considering each trackbit individually, but with the full track configuration at each end:

at each end you have 3 adjacent trackbits at the next tile, and 2 adjacent trackbits on the same tile, so (2^5)^2, additionally consider the X/Y cross makes 2*(2^5)^2 for the normal rails, so 4*2^10+2*2*2^10=2^13=8192 sprites

[Ben_Robbins_]

The bit that keeps throwing the numbers off for me is symmetry where replication appears, and the requirement in certain combinations for the additional tight 180' element and/or for additional sprite-sections without.

The formula I made a rough estimate with is something like, (4 (sides of tile) x 'Possible Combinations on sub-tile-piece a' x 'Possible Combinations on the touching sub-tile-piece b'(on neighbouring tile) x 2 (amount of pieces making up sequence (a+b=2))). Then divide that by the amount which would be in a group, if you group a and b into groups based on there total track bits on each. So in if 2 track bits meet at the tile edge, and split into 2 on the other tile, a and b are both in the same group with 1 track bit, so 2 in that group. This last section partly deals with the repetition. This gets me a string of numbers for each group, where each group has a matching amount of track spread the same between the tiles. This gets me close, but I then had to work out how many sharp bend exceptions there where manually. Couldn't work that one out otherwise.

Basically I got this: Columns from Left to Right: Total Sprites, Total Sprites Which don't conflict with the 180' option, Total Sprites for 180' not allowed game, Total Sprites Just for 180' allowed game.

05 00 00 05 Blank Track Segments
03 00 00 03 Centre Piece Segments
36 28 00 08 Single to Single Track Segments
72 40 00 32 Single to Double Track Segments
24 08 00 16 Single to Triple Track Segments
64 08 28 28 Double to Double Track Segments
48 00 24 24 Double to Triple Track Segments
16 00 12 04 Triple to Triple Track Segments

So a total of 156 segments with 180's banned. 204 with 180's allowed. 268 sprites required to be made to have the option of 180's on/off.

I've attached an image, showing what I believe are all the elements.

[peter1138]

How will that work if the first straight tile is, say, a level crossing, station tile or bridge ramp, for example?

[Ben_Robbins_]

petern: Your correct, I have forgotten to include a few tiles. Including Sloped tiles also. However all of those are unable to have junctions on them, which makes it a lot simpler. There would be 49 combo's on each, unless they are split in half, in which case there would be 7 variations on 2 segments.
Fluidity vertically is another matter, which would greatly increase the count, requiring all neighbouring tile segments to have a raised and lowered variant of each combination.

[YNM]

How will that work if the first straight tile is, say, a level crossing, station tile or bridge ramp, for example?

Make sure the tracks doesn't collide with platforms and bridge fence, also with crossing lights and road edges

Sorry if I wrong, but I think in general, only the slope tiles (total 16 more sprites) has to be added - bridge uses the same sprite as flat & sloped terrain sprites, level crossings and station uses the same sprite as flat terrain sprites. I'm not sure, but if this is going to be overlay sprites, thats the answer