PDA

View Full Version : Procedural Track FAQ



andi06
June 3rd, 2015, 01:50 AM
Configuration Queries:

1. The extent of subdivision of the rail-lod0 and blade meshes seems excessive - is this really necessary?

2. Since track, wingrail, checkrail, endcaps and sometimes chairs are almost always going to be mirror images why on earth can't you allow a tag for mirroring the left-hand asset to produce the right-hand variant. Anything to reduce the tedium! In some cases this would enable an entire component asset to be omitted.

3. Animation seems too fast yet you are using 150 frames. You specify animation-loop-speed in the mesh-library (a triumph of hope over expectation perhaps) and in the track assets. Neither of them work so I guess you currently have this hard-coded.

4. The stretcher mesh is specified in both rail assets - what happens if they are not the same?

5. Geometry
In your procedural track <kuid2:30501:1001:10> it appears that:
- Ballast meshes are multiples of 3m
- Sleepers have spacing lengths of 0.2 + 0.2
- The sleeper meshes (eg sleepers_lod0.im) are 2.62 long in Y
- This adds up (more or less) to 3 metres
- Corresponding values in the chairs asset also add up to (more or less) 3 metres
- This suggests that the Y spacing being used is 4 sleepers to 3 metres

6. Why then does the sleeper-pitch tag have a value of 0.707 rather than 0.75?

7. What is padding-length in the sleeper-asset (and why is it almost but not quite the same as sleeper-pitch)?

8. Why is sleeper-pitch in the sleeper asset rather than the main track. If it were to be altered here it could not affect the chairs which need to be at the same spacing.

9. Where super-elevation is applied to these tracks the whole mesh is tilted. This puts the high side above ground and creates a shadow. The 'skirts' need to be deformed to stay at ground level and there are tags to specify this but I can't get them to work. Can you help?

narrowgauge
June 3rd, 2015, 02:06 AM
Andi

Re your item 9. It is my impression that on a canted curve, the ballast top face is also canted. If the sleepers show a space then it is the ballast which should be canted and have deeper skirts.

Peter

andi06
June 3rd, 2015, 02:15 AM
The whole spline is tilted such that the outer edge of the ballast gets raised above ground and the inner edge gets buried below the baseboard. Both of these edges need to be forced to Z = 0, the other vertices are directly related to the track and sleepers - there isn't any need to deform those.

martinvk
June 3rd, 2015, 07:16 PM
5. Geometry
In my test track, I rejigged the whole series to have the same mesh lengths at the same LOD-distances. A lot easier to manipulate and maintain.

WindWalkr
June 4th, 2015, 07:54 AM
1. The extent of subdivision of the rail-lod0 and blade meshes seems excessive - is this really necessary?

Not sure what this refers to. Please clarify?



2. Since track, wingrail, checkrail, endcaps and sometimes chairs are almost always going to be mirror images why on earth can't you allow a tag for mirroring the left-hand asset to produce the right-hand variant. Anything to reduce the tedium!

I don't know the specific logic, but I believe it was decided that they were not necessarily complete mirrors. Would it be possible to automatically mirror them for cases where they are? Yes, but not currently supported and it's pretty minor in the grand scheme of things. Something for later polish, perhaps.



3. Animation seems too fast yet you are using 150 frames.

Animation speed has nothing to do with the number of frames in this case. It is imperative that the procedural code knows exactly what angle the blades are at any given frame of the animation, so the animations requirements are designed around that. The procedural code then determines at what speed the blade should move, at what angle the blade should be at any given instant, and then configures the animation to the appropriate frame.


For the rest- I'll pass it on to the engineer responsible and hopefully we'll get something useful back :-)



9. Where super-elevation is applied to these tracks the whole mesh is tilted. This puts the high side above ground and creates a shadow. The 'skirts' need to be deformed to stay at ground level and there are tags to specify this but I can't get them to work. Can you help?

There are two options here:

1. Simply make them large enough so that this is unlikely (but don't go crazy.)

2. Make them low enough that the bottom is below the rest of the mesh, and then set the "adjust-height-to-ground-threshold" to be just above that height. Also set the "adjust-height-to-ground-offset" appropriately. This is only going to work for splines which actually sit on the ground- if they're on bridges or otherwise suspended, it's likely going to look pretty silly.


chris

andi06
June 4th, 2015, 09:17 AM
Yes, but not currently supported and it's pretty minor in the grand scheme of things.
I can see that its not important for you but its a lot of tedium for me. Every time you hand a mesh in max you are taking your life into your hands and almost all the meshes currently need to have handed versions. If you subsequently need to re-texture or re-map the meshes it becomes a nightmare scenario. I can't believe that you don't already have the necessay routines.


Animation speed has nothing to do with the number of frames in this case. It is imperative that the procedural code knows exactly what angle the blades are at any given frame of the animation, so the animations requirements are designed around that. The procedural code then determines at what speed the blade should move, at what angle the blade should be at any given instant, and then configures the animation to the appropriate frame.
The point is that I can't currently control the animation speed.


Simply make them large enough so that this is unlikely (but don't go crazy.)
.... treats with contempt :-)


This is only going to work for splines which actually sit on the ground- if they're on bridges or otherwise suspended, it's likely going to look pretty silly.
I've had a quick play with your tags and I see your point.

http://i1216.photobucket.com/albums/dd367/andi061/Capture23.jpg

This is a pretty extreme cant but its still obvious at quite shallow angles.

The inner ballast edge is dropping below the baseboard and the outer edge sailing up into the air. Shadows don't seem to show up in game screenshots so I've had to use the snipping tool here.

This will be very tricky for route builders to deal with. If you are tilting the mesh about its own origin what we really need is an option to lock the inner and outer edges (which will usually have the same Z value) This would give a level mesh which should work anywhere don't you think?

I appreciate that track meshes would need to be drawn to take this into account.

WindWalkr
June 4th, 2015, 09:35 AM
I can see that its not important for you but its a lot of tedium for me.

Noted, and we'll keep this in mind when this area of the code is next revisited.



The point is that I can't currently control the animation speed.

No, you can't. This is by design.



The inner ballast edge is dropping below the baseboard and the outer edge sailing up into the air.

As it stands currently, superelevated track provides the angle but does not provide any height adjustments. We don't have any plan to change this because too much of the code is reliant on the track being where it's placed by the creator- while it wouldn't be hard to change how the mesh follows the spline, for example, this would look pretty stupid when you tried to run a train along it. The net result of this is that it's up to the route builder to make any necessary adjustments in height when setting superelevation.

chris

martinvk
June 4th, 2015, 10:52 AM
1. Simply make them large enough so that this is unlikely (but don't go crazy.)
In my tracks in previous versions of Trainz, I usually made the ballast extend below the ground level but with the result that the ballast was hard edged where it intersected the ground plane. With the result that the track would stay level while the ground could be undulating without any gaps showing under the ballast. Naturally this would only work within limits. Following the example of the build-in procedural track, I made the edge of the ballast selectively transparent. Not sure how to keep this effect if the whole is elevated or depressed by the cant. If the outer edges cannot be clamped to the ground, I guess it's back to hard edged ballast.

martinvk
June 4th, 2015, 10:57 AM
... it's up to the route builder to make any necessary adjustments in height when setting superelevation.
Will there be ground tools made available to raise the ground up to the different levels of the inner and outer curve of superelevated track instead of the center line.

andi06
June 4th, 2015, 12:16 PM
No, you can't. This is by design.
Perhaps you could design it to be a little slower?


While it wouldn't be hard to change how the mesh follows the spline, for example, this would look pretty stupid when you tried to run a train along it.
I think you are misunderstanding me, what I'm suggesting is this:

http://i1216.photobucket.com/albums/dd367/andi061/Capture26.jpg

As you can see only the ballast outer edge vertices are affected. This is also pretty close to prototypical.

WindWalkr
June 4th, 2015, 08:35 PM
In my tracks in previous versions of Trainz, I usually made the ballast extend below the ground level but with the result that the ballast was hard edged where it intersected the ground plane. With the result that the track would stay level while the ground could be undulating without any gaps showing under the ballast. Naturally this would only work within limits. Following the example of the build-in procedural track, I made the edge of the ballast selectively transparent. Not sure how to keep this effect if the whole is elevated or depressed by the cant. If the outer edges cannot be clamped to the ground, I guess it's back to hard edged ballast.


True soft edges on the bottom of the ballast is problematic anyway, because it is see-through when seen side-on from a low angle. This makes the track appear to float.

You could maybe work around the above problem by having an inner set of ballast polygons which are fully opaque, and an outer set which have the transparencies. I'm not sure how well this would work out in practice, but it's worth playing with because it shouldn't have the problems you describe.

This is probably a good place for a "soft particles" type material which decreases in opacity the closer it is to another surface. We'll definitely be adding something like this in the future (thanks, E2!) but we're not quite there yet.

chris

andi06
June 5th, 2015, 05:58 AM
Experimentally, I've added conductor rails to some p-track assets using track-type "default". These work well but raise two issues:

Possibly a bug: If you draw a p-track segment (drawn left-to-right) and then add a second segment (drawn right-to-left) the spline directions are changed by the game so that they all match up. This is contrary to the behaviour of normal tracks and makes prototypical third-rail (where the conductor often changes sides) impossible. It also poses difficulties for tracks in stations where the conductor must be on the opposite side to the platform.

A Suggestion: This is a p-track junction cobbled up using four different p-track assets:

http://i1216.photobucket.com/albums/dd367/andi061/Capture24.jpg

Obviously you can't currently use a third rail track within the junction itself but an additional track-type behaviour might be possible. 'track-type conductor' would simply need to suppress the conductor within the overlap zone and provide end-cap ramps at each end of the interruption.

Possible?

andi06
June 5th, 2015, 06:00 AM
True soft edges on the bottom of the ballast is problematic anyway, because it is see-through when seen side-on from a low angle. This makes the track appear to float.

This is true of older tracks with a wide fade zone but if the fade-out is restricted in width and alpha-masked rather than alpha-blended this isn't anything to worry about.

The real graphical issue isn't the fact that the track floats but that a shadow is produced to draw attention to it.

WindWalkr
June 5th, 2015, 06:40 AM
The real graphical issue isn't the fact that the track floats but that a shadow is produced to draw attention to it.

I don't really agree. We don't like floating tracks; the fact that the shadow draws attention to it isn't ideal but isn't the underlying problem. You're right that it isn't a new issue, but it's something that we should definitely focus on reducing.

chris

andi06
June 5th, 2015, 07:46 AM
I don't really agree. We don't like floating tracks; the fact that the shadow draws attention to it isn't ideal but isn't the underlying problem. You're right that it isn't a new issue, but it's something that we should definitely focus on reducing.
What I'm saying is that partial transparency at the edge of tracks is under the creator's control, Martin and I can deal with although new material options would always be nice of course.

With the facilities that are currently available we can't deal with the buried or floating edges produced by super-elevation (nor in my view will route-builders be able to do so) An inner wall of ballast extending below ground might work although it doesn't sound very elegant.

I don't think that its acceptable to say 'we don't have any plan to change this because too much of the code is reliant on the track being where it's placed by the creator' unless the creator is able to place the track to obviate the problem. At the moment the super-elevated track vertices can be raised by the route builder to get the lower ballast out of the ground but the outer bedge will be an insoluble problem. You have to give these guys a fighting chance.

WindWalkr
June 5th, 2015, 08:38 AM
What I'm saying is that partial transparency at the edge of tracks is under the creator's control .. we can't deal with the buried or floating edges produced by super-elevation

I don't really see the difference. Unless you assuming that the underlying terrain is nearly flat (often true, but a bad assumption overall) then you still deal with the same class of problems- the amount of ballast edging exposed varies. Yes, superelevation exacerbates this, but it's not a new problem and we should look at generalised solutions.



An inner wall of ballast extending below ground might work although it doesn't sound very elegant.

Very few things in gaming are elegant :) It's mostly smoke and mirrors. The questions are whether it looks good, and whether it performs well. I don't see any performance issues with that (overdraw isn't great, but we're talking about very small parts of the screen in most cases, and two layers deep at the worst.)




I don't think that its acceptable to say 'we don't have any plan to change this because too much of the code is reliant on the track being where it's placed by the creator' unless the creator is able to place the track to obviate the problem. At the moment the super-elevated track vertices can be raised by the route builder to get the lower ballast out of the ground but the outer bedge will be an insoluble problem. You have to give these guys a fighting chance.

To be clear, the only thing that the route creator is expected to resolve is placing the track at the correct height. Problems with making the track match the underlying terrain is an issue for the spline creators (and/or N3V.)

chris

andi06
June 5th, 2015, 02:55 PM
I'm trying to be constructive.

Here is a very rough (and exaggerated) mockup of the effect of the deformation described in post 10:

http://i1216.photobucket.com/albums/dd367/andi061/2015-06-05%20203813.jpg

Base on what the adjust-ground.... tags seem to do this would appear to be relatively easy for you to do and an improvement on what we have. Its also fairly close to the way that track bases are built up in the prototype.

Of course the ground may not be flat but that's already true of non-banked splines as well.

WindWalkr
June 5th, 2015, 07:49 PM
Base on what the adjust-ground.... tags seem to do this would appear to be relatively easy for you to do and an improvement on what we have. Its also fairly close to the way that track bases are built up in the prototype.

Of course the ground may not be flat but that's already true of non-banked splines as well.


Unless I'm missing what you're attempting here, it's already available to you and requires nothing further from my end. As mentioned above, the downside of this technique is that it will follow the ground height even when you don't want it to. I guess we could add an additional parameter to control a maximum variance or similar. It's of course also possible to create a variant of this which *only* solves the superelevation problem- that's not at all hard to do, but as noted would only work on completely flat ground, requiring you to fall back to other approaches. I'm not anti this approach and can whip something up if we think it's better than the ground-following variant, just pointing out that it's not a panacea.

chris

andi06
June 6th, 2015, 02:48 AM
Unless I'm missing what you're attempting here, it's already available to you and requires nothing further from my end. As mentioned above, the downside of this technique is that it will follow the ground height even when you don't want it to. I guess we could add an additional parameter to control a maximum variance or similar. It's of course also possible to create a variant of this which *only* solves the superelevation problem- that's not at all hard to do, but as noted would only work on completely flat ground, requiring you to fall back to other approaches. I'm not anti this approach and can whip something up if we think it's better than the ground-following variant, just pointing out that it's not a panacea.

Yes, I'm asking for a variation of the adjust-ground... tags which moves vertices to the height of the track rather than to ground level.

WindWalkr
June 6th, 2015, 04:32 AM
Yes, I'm asking for a variation of the adjust-ground... tags which moves vertices to the height of the track rather than to ground level.

Seems fair.

chris

andi06
June 6th, 2015, 05:57 AM
A little bug here.

I've added 'adjust-height-to-ground-threshold 0.05' to a track and it works fine if the track is flat. However it is broken when super-elevation is added, I think because you are selecting the vertices to distort after the section is rotated rather than before.

A little observation and I acknowledge that I'm being very picky here.

I would imagine that, in the prototype, super-elevation is achieved by leaving the lower rail at datum and raising the outer rail to provide the banking. In TRS terms this would mean rotating the track section around the inner running rail surface rather than around the spline origin.

WindWalkr
June 6th, 2015, 06:19 AM
I've added 'adjust-height-to-ground-threshold 0.05' to a track and it works fine if the track is flat. However it is broken when super-elevation is added, I think because you are selecting the vertices to distort after the section is rotated rather than before.

Quite likely, and I concur that it would be better off using the source data. I'll change this.



I would imagine that, in the prototype, super-elevation is achieved by leaving the lower rail at datum and raising the outer rail to provide the banking. In TRS terms this would mean rotating the track section around the inner running rail surface rather than around the spline origin.

As noted previously, this is the domain of the route builder. It would be nice if that were unnecessary, but it's not practical to implement. We might offer tools to automate the necessary height adjustment in the future.

chris

andi06
June 6th, 2015, 06:25 AM
As noted previously, this is the domain of the route builder. It would be nice if that were unnecessary, but it's not practical to implement. We might offer tools to automate the necessary height adjustment in the future.
Fair enough, I said I was being picky and I know that the sums would be tricky.

WindWalkr
June 6th, 2015, 06:37 AM
Fair enough, I said I was being picky and I know that the sums would be tricky.

It's not that the sums are tricky, it's that there's a massive amount of code which makes the assumption that the spline resides at the center of the track. It would be trivially to render the track at some location divorced from the spline, but that would be no use by itself, and to take it further there would inevitably be a lot of unexpected side effects as fundamental assumptions are broken throughout the whole game. It's not impossible, but it would probably take the better part of a year to get the bugs out after a change like that.

chris

andi06
June 6th, 2015, 10:42 AM
I've just won 50p.

I laid a bet with a friend that the phrase '... the sums would be tricky ...' would trigger further comment, thanks Chris :-)

RPearson
June 6th, 2015, 12:46 PM
Textbook says the preferred method for applying superelevation (SE) is by raising the outer rail the required amount. What they do in the field I don't know as there seems to be no hard and fast rules and regulations covering how it's done.

To do that in surveyor you'd have to increase the spline point height by 1/2 the SE value at that point and then apply the full SE value to the spline twist - a combined translation and rotation to shift the center of rotation to the inner rail. The SE value at any point is set by the curvature value in the horz plane and any curve that requires SE (to set the allowable speed thru the curve) would also require an easement (providing a smooth change in curvature) leading in and out to the tangent track. Typically the length of run-in and out for the SE and the length of the easements are set equal and the two effects are accomplished in the same stretch of track. In the easement we get a linear varying curvature and in the run-in and out we get a linearly varying change in height of the outer rail. In the circular arc part of the curve we get constant curvature and constant SE value. Length of run- in is usually set so when traveling at max allowed velocity for the curve the vertical velocity of the wheel center is less than some specified value.

Since any large track plan in Trainz with graded track should be using fixed height spline points to achieve and maintain grades along the route this change in height is possible. However linear behavior of the Track spline is rather difficult to achieve in practice - straighten flag if applied to a single track section between 2 points yes but on anything else no.

SE involves rotation (torsion or twist if you like) about the axis of the spline curve. Is SE currently included as a property of the spline having nonlinear characteristic along the arc length of the spline like the curvature behaves now or is it simply an add on as a linear function of the arc length?

Bob Pearson

andi06
June 6th, 2015, 01:06 PM
So N3V got it exactly wrong then? :)

RPearson
June 6th, 2015, 04:23 PM
I didn't say that - exactly. There are at least 3 options to solve the problem. The preferred "textbook" method will result in using more ballast though it holds the ballast voume per unit length under the low rail about the same for normal and SE track. N3V's choice uses about the same total ballast volume but takes some from under the low rail and puts it under the high rail. And a last option which uses the least amount of ballast volume and takes it all out from under the low rail.

If you feel a certain minimum volume of ballast per unit length is required under each side for proper track work then probably option 1 is the one you use. So I don't see it as being wrong - exactly.

Dam*, that smiley face is still winking at me.

Bob Pearson

WindWalkr
June 6th, 2015, 07:54 PM
I've just won 50p.

I laid a bet with a friend that the phrase '... the sums would be tricky ...' would trigger further comment, thanks Chris :-)

Most posts in this forum will trigger further comment. It's kind of the way this forum works ;-)

chris

WindWalkr
June 6th, 2015, 07:59 PM
Textbook says the preferred method for applying superelevation (SE) is by raising the outer rail the required amount.

Without a doubt, the outer rail will need to be raised. The point being that we require the route build to take care of this, rather than attempting to automate it at this time.



SE involves rotation (torsion or twist if you like) about the axis of the spline curve. Is SE currently included as a property of the spline having nonlinear characteristic along the arc length of the spline like the curvature behaves now or is it simply an add on as a linear function of the arc length?

There is a superelevation ratio which is set per track vertex and which uses linear interpolation between these (with a few exception- we disable interpolation in the area immediately around a junction vertex, for example.) This is multiplied by the instantaneous* track curvature to determine the banking angle at any given location. The curvature is obviously not necessarily linear.

*: mathematically not really, for various reasons, but should be treated as such.

chris

andi06
June 7th, 2015, 11:23 AM
I was less than impressed with the earlier iterations of procedural-track but I have to say that the current position (let's call it stage 1) is working well in general. If you can I would welcome your input on additional capabilities in Stage 2, assuming that there will be a Stage 2.

I now have a bunch of procedural-track assets which I will upload as a beta in the next few days.

http://i1216.photobucket.com/albums/dd367/andi061/2015-06-07%20164000.jpg

There is a single mesh-library which contains 4 variations of ballast plus a no ballast option, 3 variations of sleepers, flat-bottom and bullnose track with the appropriate chairs and third and fourth rail conductors via a currently unofficial hack. I've set out to make the assets easy to skin and I will make the layered texture sources available. I've purposely set these assets up in a way which is compatible with my Fixed Track Junctions, so that I can cover items which the procedural track system can't.

Via this thread I've now got to the bottom of most of the issues involved and I will bump the outstanding queries in due course.

The main outstanding query is performance. I'm sure that the attached-spline mechanism and junction formation will have a cost but quite small errors in the lod schemes also have the potential to wreck performance so I would really like some guidance on how to assess the performance of these assets. Ideally we should have some sort of benchmarking.

Comments?

martinvk
June 7th, 2015, 09:02 PM
Everything in one mesh library, wow, that must be a pain every time you modify a detail and have to submit the whole thing again. Always took me a long time compared to the other parts of the track in other kuids. Thanks to splitting the library into small related components, it submits much quicker. A bit concerned about the "unofficial hack for the third and forth rails. Hope it doesn't come back to haunt you or bite you in the end.

Very nice to see you've advanced so far. I'm still at the adjustment stage of my test track.

pcas1986
June 7th, 2015, 11:02 PM
Has anyone worked out what "padding-length" is yet? I'm willing to accept educated guesses. :hehe:

andi06
June 8th, 2015, 02:30 AM
Everything in one mesh library, wow, that must be a pain every time you modify a detail and have to submit the whole thing again.
During development only the meshes that I'm actively working on are in the library asset, the others are in a folder which isn't being submitted :-)

I've lost count of the times that we've asked about padding-length.

WindWalkr
June 8th, 2015, 03:22 AM
Has anyone worked out what "padding-length" is yet? I'm willing to accept educated guesses. :hehe:

It works like this:

* Normally a given length of track is split up into a number of 'repeats'. This causes each repeat to be contracted or expanded slightly so that the overall length is correct.
* In many cases, such as a sleeper mesh containing 4 sleepers, the amount of stretching might become noticeable if the overall track length is too short.
* Instead, we use a padding mesh (which is a smaller length) zero or more times before starting the full-sized mesh repeats.
* Your padding length needs to be small enough to be easily recognisable by the track-lod-tree as separate from the regular repeats.

Avoid it if you can; it's there as a failsafe for cases where you really can't get the regular stuff to do what you want.

chris

WindWalkr
June 8th, 2015, 03:25 AM
The main outstanding query is performance. I'm sure that the attached-spline mechanism and junction formation will have a cost but quite small errors in the lod schemes also have the potential to wreck performance so I would really like some guidance on how to assess the performance of these assets. Ideally we should have some sort of benchmarking.

There are two aspects of performance.

Firstly, how many polygons (etc) are generated. You can watch this in the stitched mesh stats. Be sure to test lots of different scenarios.

Secondly, how long the actual generation takes. This is mostly async, so unless you're actually seeing problems, we're probably safe to ignore it for now. I expect you'll hit the first problem before the second in most cases. In the long run, it would be nice to have tools to better evaluate this.

chris

andi06
June 8th, 2015, 03:44 AM
It works like this:

* Normally a given length of track is split up into a number of 'repeats'. This causes each repeat to be contracted or expanded slightly so that the overall length is correct.
* In many cases, such as a sleeper mesh containing 4 sleepers, the amount of stretching might become noticeable if the overall track length is too short.
* Instead, we use a padding mesh (which is a smaller length) zero or more times before starting the full-sized mesh repeats.
* Your padding length needs to be small enough to be easily recognisable by the track-lod-tree as separate from the regular repeats.

Avoid it if you can; it's there as a failsafe for cases where you really can't get the regular stuff to do what you want.

chris
I get the principle but the details aren't really clear. Any chance of a diagram on the wiki showing the inter-relationship between padding-length, spacing-before and after, sleeper-pitch etc.

At the moment I'm using the same values as your sample assets and there are no issues, but I can't understand why padding-length is present in both the sleeper and chair assets or why sleeper-pitch isn't in the parent track asset (bcause it would affect both sleepers and chairs) I have found that if I alter some of these values I end up with chairs missing sleepers and suspended in mid air.

Having said all of the above the system obviously works because the new tracks are far better than the old ones in terms of avoiding un-natural stretching and forcing their way into attached-track segments.


In the long run, it would be nice to have tools to better evaluate this.
It would be fairly easy to make a spreadsheet to assess polygons per metre at various lod distances - would this be worthwhile?

WindWalkr
June 8th, 2015, 03:49 AM
I get the principle but the details aren't really clear. Any chance of a diagram on the wiki showing the inter-relationship between padding-length, spacing-before and after, sleeper-pitch etc.

Yes, but not this week. Remind me again at some point :)



I have found that if I alter some of these values I end up with chairs missing sleepers and suspended in mid air.

It's obviously important that they line up correctly. All the vertex manipulation code is based around the assumption that the source meshes actually line up.



It would be fairly easy to make a spreadsheet to assess polygons per metre at various lod distances - would this be worthwhile?

Probably? The biggest issue is that there are so many variables that you can control, so what is useful information for one mesh is meaningless (or at least over-generalised) for another. Having some rough numbers is probably better than no numbers, however.

What I really want is a tool which runs through many benchmarks and then displays a small set of numbers (effectively, scores) at the end of the process. That way you can rapidly test any changes and see if they score better or worse.

chris

andi06
June 8th, 2015, 03:55 AM
It's obviously important that they line up correctly. All the vertex manipulation code is based around the assumption that the source meshes actually line up.
They do but its easy to break the relationship by changing the numbers.


What I really want is a tool which runs through many benchmarks and then displays a small set of numbers (effectively, scores) at the end of the process. That way you can rapidly test any changes and see if they score better or worse.
That would be just the ticket.

WindWalkr
June 8th, 2015, 04:25 AM
They do but its easy to break the relationship by changing the numbers.

Sorry, by "source meshes" I mean "including the way it is specified to go together in the config file" and by "vertex manipulation" i mean "all of the procedural bending and slicing and repositioning that goes beyond that."

chris

pcas1986
June 8th, 2015, 04:26 AM
It works like this:

* Normally a given length of track is split up into a number of 'repeats'. This causes each repeat to be contracted or expanded slightly so that the overall length is correct.
* In many cases, such as a sleeper mesh containing 4 sleepers, the amount of stretching might become noticeable if the overall track length is too short.
* Instead, we use a padding mesh (which is a smaller length) zero or more times before starting the full-sized mesh repeats.
* Your padding length needs to be small enough to be easily recognisable by the track-lod-tree as separate from the regular repeats.

Avoid it if you can; it's there as a failsafe for cases where you really can't get the regular stuff to do what you want.

chris

Thanks for the response. I'll need to study it in conjunction with my own experiments and Andi's comments. I have an issue where a LOD0 sleeper mesh is being interspersed between lower level sleeper meshes and I don't understand why. I thought maybe Padding-length may be involved. Perhaps others in this group can help so I will try and post some images and detail tomorrow.

andi06
June 8th, 2015, 05:01 AM
I have an issue where a LOD0 sleeper mesh is being interspersed between lower level sleeper meshes and I don't understand why.
I don't think that its an LOD issue but a mesh-length issue.

If you have a mesh-length of 18 metres, an LOD1 sleeper mesh length of 6 and a track segment of 20 then at LOD1 TRS is providing 3 x LOD1 multi sleeper units and 2 x single sleeper units. There is no LOD1 currently available on the single sleepers so you are getting the LOD0 mesh instead.

The wiki says (or possibly just implies) that LOD capability of single sleepers will be added. For variation in junctions it would also be nice to be able to use lod-random-bias here at LOD0.

pcas1986
June 8th, 2015, 05:22 AM
I don't think that its an LOD issue but a mesh-length issue.

If you have a mesh-length of 18 metres, an LOD1 sleeper mesh length of 6 and a track segment of 20 then at LOD1 TRS is providing 3 x LOD1 multi sleeper units and 2 x single sleeper units. There is no LOD1 currently available on the single sleepers so you are getting the LOD0 mesh instead.
...

That makes sense. Here is a shot of the problem where the LOD0 sleepers are being used in conjunction with LOD2 ballast and LOD1/LOD2 rails. My meshes use red for LOD0, yellow for LOD1, blue for LOD2 and green for LOD3. I would not have noticed except for the obvious colour differences.

This demonstrates that the extra LODs need to be implemented soon.


http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.06.08_20h07m54s_002__zpskh26v8h 6.jpg

andi06
June 9th, 2015, 06:42 AM
Zec may have raised this one, if so excuse the duplication.

TANE is generally very good indeed at dealing with junctions where some or all of the tracks at the junction node are different kuids. There is just one case that might be improved.


http://i1216.photobucket.com/albums/dd367/andi061/2015-06-09%20121820.jpg

As you can see we have a rusty junction track joining a bright main line but the blade on the right is rusty when it would be bright in the prototype. Accommodating this might be easy and it might be hard and there are potential issues if the other track parameters are too different but it would be worth looking at.

I see that attachments are working, thanks for enabling this (even if I might have cocked up and included the file twice)

S301
June 9th, 2015, 07:20 AM
Zec may have raised this one, if so excuse the duplication.

TANE is generally very good indeed at dealing with junctions where some or all of the tracks at the junction node are different kuids. There is just one case that might be improved.

(image removed :) )\

As you can see we have a rusty junction track joining a bright main line but the blade on the right is rusty when it would be bright in the prototype. Accommodating this might be easy and it might be hard and there are potential issues if the other track parameters are too different but it would be worth looking at.

I see that attachments are working, thanks for enabling this (even if I might have cocked up and included the file twice)

I've been giving some thought to this. Since Trainz won't know the difference, I think this is more a 'mesh'/'texture' error than a Trainz issue. I think the easy solution would be to raise the shiny rail, or lower the rusty rail, by about 1-4mm (I think somewhere in that range should work). This is no more of a difference than you'll see in the 'flat spots' on a wheel as it rotates, and raising the shiny rail may even improve this slightly here... Worth a shot anyway (I was planning to, but am working on my tracks in spits and spurts at the moment :) ).

I think the bigger issue is the blades being one or the other. I know earlier builds handled this properly (as I was happily testing two entirely different tracks, and track gauges(!) at the time :P ), but it might have caused issues; no idea.

I have to say, I love the look of the ballast texture. I really need to look closely at my track textures soon, they need some improvements methinks! :)

Regards
Zec

andi06
June 9th, 2015, 07:33 AM
Since Trainz won't know the difference, I think this is more a 'mesh'/'texture' error than a Trainz issue. I think the easy solution would be to raise the shiny rail, or lower the rusty rail, by about 1-4mm
I can't see what difference that would make, TANE is only ever going to produce one blade animation in any one place so you can't hide rusty under shiny, unless I'm misunderstanding you.


I have to say, I love the look of the ballast texture.
Finding suitable textures for ballast is a big problem, they need to cover about 3 metres square, viewed from above and without any strong directional lighting or repetitive patterns.

Its also a huge problem getting a decent normal map - The NVidia filter isn't much good for this. There is a more flexible filter available for Gimp but I can't get musch out of that one either. Its clearly impractical to draw a matching mesh and use Max so if anybody has any idea how this can be done I would love to hear it.

S301
June 9th, 2015, 07:46 AM
Hi Andi, apologies I thought you were referring to the crossover/frog rather than the blades :) Yeah, it definitely needs to use blade meshes from the appropriate rail asset (as I noted, it did in a previous build) :)

As to the normals map, this might be a situation where re-drawing in photoshop may be the way to go. Or use an air brush to 'fix' any errant shadows, and reduce/increase the highs and lows. Remember to convert to a 'height'/'bump' map first, and look at it as 'high' and 'low' points, then do the normals map conversion. I actually found a neat little tutorial that went over some basics of this, albeit for non organic objects, but alas I didn't save it, and not sure I could find it :(

Regards

andi06
June 9th, 2015, 07:57 AM
Hi Andi, apologies I thought you were referring to the crossover/frog rather than the blades :)

Now I see what you mean. Yes dropping a rusty rail surface would work there but everyone would have to do it.

I think that the vee ahould be mitred rather than overlapped anyway, since even if both rails are in the same asset they may not be symmetrical. Whichever way you go with this it will sometimes be wrong but we're getting very picky.

andi06
June 11th, 2015, 07:13 AM
Back to padding-length! I decided to add some silly values and see what happened. So I altered my own padding length to 250 for sleepers with this result:

596

Now it makes a little more sense to me and seems to be very effective in preventing track splines from stretching and looking unreal as a result.

However in the example we have a padding-length value of 250 for the sleepers and 750 for the chairs. One is a multiple of the other so, by accident, the chairs are still lining up with the sleepers - but only at every third sleeper.

This will mean that tracks will only be able to use attached-spline components which have the same padding-length values, a considerable restriction on the flexibility of the system.

Surely this variable should be in the parent track asset and passed down from there to both sleepers and chairs. I would have thought that the same would be true of sleeper-pitch which appears to carry out spacing function in the actual junction zones.

andi06
June 11th, 2015, 07:26 AM
I did some experiments last night with importing an old route and using the 'Replace Assets' function to replace the old track with a procedural-track asset. Mostly this works very well but there were some red circles. In the main these seem to be due to the grades of the two branch tracks being too different, which is always going to happen when the ground isn't flat.

I found that it could be very fiddly indeed to edit these junctions to clear the error.

Are you planning a tool to make this easier?

In essence I think that you just need to force a matching gradient from the junction node to the point of the frog.

RPearson
June 11th, 2015, 11:12 AM
I think you might want to go beyond the frog andi. I really haven't played with this yet but if we end up with the procedures just defining track splines then we end up with the usual Trainz 3d spline. We usually consider the horz plane but also vert and in fact in any number of planes are possible.

What you want and need is a plane surface thru that area with the splines staying in the plane. Just setting a matching gradient on both tracks in surveyor will only ensure the 3 spline points are co-planer. The spines will pass thru the points for sure but they can and do bend out of that plane. In my own experience with the std spline junctions I had to go 1 vertex beyond the frog and 1 before the points to really enforce that plane - approximately. Do we have to in all case - no. Depends on the severity of the difference in grades of thru and divergent tracks.

I've run into the problem as I say with spline junction on my NG layouts - modern high speed track work ? I don't do that stuff.

Bob Pearson

WindWalkr
June 12th, 2015, 08:28 PM
We're already doing similar things with superelevation near the junction nodes. It may be reasonable to extend this logic to other attributes. Not a trivial change, but not impossible either.

chris

andi06
June 13th, 2015, 06:26 AM
Chris, would you please comment on Post 49 of this thread.

Andi

WindWalkr
June 13th, 2015, 07:05 AM
Chris, would you please comment on Post 49 of this thread.

I'm not entirely sure what you're after there. Is your suggestion a good one? Perhaps, but it's not how things work within Trainz currently. Each spline is deliberately rendered independently of its "parent". Could we change this in the future? Perhaps; we'd have to look at the pros and cons of making such changes. Something to discuss at some point, but I've got plenty of other things to address before we start talking about potential improvements in this area.

Or if you're looking for some other feedback, then I guess I've missed what you're asking?

chris

andi06
June 13th, 2015, 12:01 PM
Sleeper-Pitch Value
I really do want to fully understand the system and for the first time ever we have an asset type with a significant amount of dimensional info within the config. My tracks are standard gauge like your sample and I could just copy all of the values over, but if I do that I won't be able to help people doing other gauges and track types where copying your setup isn't going to be all that helpful.

Your main sleeper meshes (and mine) show 4 sleepers per 3 metre length. Sleeper-pitch obviously only refers to the junction-overlap zone and I'm using the obvious sleeper-pitch value of 0.750 (3 metres / 4) but you are using 0.707. Why?

Sleeper-Pitch Tag Location
In my business you draw everything once but, unless you enjoy being sued, you make sure that you draw nothing twice because its a recipe for disaster. This means that you need to draw it in the right place. I believe that the same applies to software.

It seems to me that sleeper-pitch is in the wrong place because, logically, it affects sleepers and chairs and, if it were to be in the main asset, it would make using attached-spline components from other asset sets a reliable proposition. 'It's not how things work within Trainz currently' seems a bit weak in this case because these components are procedural-track assets themselves and probably can't have an independent existence.

Now if I change the value of sleeper-pitch to 0.500 in a sleeper asset and reload the parent track, I now have sleepers AND chairs at 500mm centres in the junction zone - this contradicts what you are saying about drawing the splines independently because I don't need to modify the track or chair assets to do this.

I'm trying to be helpful in pointing out one of several logical inconsistencies in your design:)

WindWalkr
June 13th, 2015, 10:23 PM
'It's not how things work within Trainz currently' seems a bit weak in this case because these components are procedural-track assets themselves and probably can't have an independent existence.

My point is not that the assets will be reused, but that the code is reused. Could we make custom code to deal with these assets in a custom way? Yes, but that's not what we've got currently.



Btw, a while back I mentioned that I would ask our procedurals programmer a few of the questions. I did get a reply, however I haven't had time to parse it out of programmer-speak for you as yet. I'll attach it verbatim in case it ends up answering any of your questions.


4. The stretcher mesh is specified in both rail assets - what happens if they are not the same?

Oh I don't remember that the stretcher mesh is specified in both rail asset. As far as I remember, the left rail asset is the one I look in to find the stretcher mesh. Maybe as a fallback I look in the right rail asset if there is nothing in the left rail asset. But it needs to be specified only in the left rail asset I think.




5. Geometry
In your procedural track <kuid2:30501:1001:10> it appears that:
- Ballast meshes are multiples of 3m
- Sleepers have spacing lengths of 0.2 + 0.2
- The sleeper meshes (eg sleepers_lod0.im) are 2.62 long in Y
- This adds up (more or less) to 3 metres
- Corresponding values in the chairs asset also add up to (more or less) 3 metres
- This suggests that the Y spacing being used is 4 sleepers to 3 metres


6. Why then does the sleeper-pitch tag have a value of 0.707 rather than 0.75?


7. What is padding-length in the sleeper-asset (and why is it almost but not quite the same as sleeper-pitch)?
the padding length is more or less equivalent to : spacing-before + single sleeper width + spacing-after
but the sleeper pitch is : half single sleeper width + sleeper interspace (average) + half single sleeper width
and I guess that the half sleeper interspace (average) is not always the same as the spacing-before/after ?





8. Why is sleeper-pitch in the sleeper asset rather than the main track. If it were to be altered here it could not affect the chairs which need to be at the same spacing.
it is basically true, but the sleeper-pitch is anyway used only for the procedural junctions (I think it is written in the document provided to the content creators), and the procedural junctions use only the single sleeper mesh and the single chair mesh in this context,
the sleeper-pitch is only an indication on how long should the interspace be, but it is rarely exactly the same (the interspace and the width are scaled to adapt to the area of the custom sleepers chunks).
Say clearly to them that the single sleeper and single chair are always used together for the procedural junction, and only in that context, with the sleeper-pitch as an indication (and the procedural algorithms place automatically these single elements one by one).
The n-sleepers meshes and n-chairs meshes are always used together (for a given n being 4, 2, etc ...) and out of the procedural junction context (so the sleeper pitch is not used at all, only the spacing which is in the original mesh will define the spacing between the elements and they should be synchronized between the n-sleepers and the n-chairs)

martinvk
June 13th, 2015, 10:37 PM
Looking forward to your
parse it out of programmer-speak
For the stretcher mesh
But it needs to be specified only in the left rail asset I think.Will have to try this and see if it works.
As for the padding length
spacing-before + single sleeper width + spacing-aftershouldn't that be half before and half after? Otherwise there will be an overlap with the next single sleeper or is that already accounted for in the calculations?
What I take away from your description is that padding is for the single sleepers and chairs and pitch is for the n-sleepers and n-chairs.

Now to go back and make some adjustments in my track and see how they look.

andi06
June 14th, 2015, 03:26 AM
7. What is padding-length in the sleeper-asset (and why is it almost but not quite the same as sleeper-pitch)?the padding length is more or less equivalent to : spacing-before + single sleeper width + spacing-after
but the sleeper pitch is : half single sleeper width + sleeper interspace (average) + half single sleeper width
and I guess that the half sleeper interspace (average) is not always the same as the spacing-before/after ?
To reply in the same language :-)

Typically (spacing-before + single sleeper width + spacing-after) = (half single sleeper width + sleeper interspace (average) + half single sleeper width)

Which drops back to: padding-length = sleeper-pitch

Ergo - you probably don't need to ask for padding-length since you can calculate it from other info supplied, but the tag must be present and it must have a sensible value. For most assets I would suggest that padding-length (specified in sleeper and chair assets) should be the same as sleeper-pitch (specified in sleeper assets) and that both of these values should be (length of main multi-sleeper mesh) / (number of sleepers in that mesh) This should give a sleeper spacing roughly equal to that in the main track sections.

As for why Auran are using 0.707 instead of 0.750 my guess is that they don't actually know :)



Why is sleeper-pitch in the sleeper asset rather than the main track. If it were to be altered here it could not affect the chairs which need to be at the same spacing.
it is basically true, but the sleeper-pitch is anyway used only for the procedural junctions (I think it is written in the document provided to the content creators), and the procedural junctions use only the single sleeper mesh and the single chair mesh in this context,
It is clear that the parent and all of the sub-component assets are considered together when doing your sums and I'm not actually suggesting that you do it any differently. But take it from me that the sleeper-pitch tag is currently in the wrong asset and will come back to haunt you.

RPearson
June 14th, 2015, 08:28 AM
Per the track guide on the wiki:
The mesh-table for the sleeper asset includes a single sleeper instance which is used by the procedural junction system. The sleeper single mesh is not referenced through the track-lod-tree. The term sleeper single is specifically required in the mesh-table, the mesh file itself can be named as desired. The sleeper single mesh is always used under junctions, the tracklod-tree is always used when not inside a junction. For this reason, we recommend you provide different lengths of spline section in the track-lod-tree, including down to a single sleeper length.


The tag sleeper-pitch determines the spacing of single sleepers at junctions. It is measured from the centre of a sleeper to the centre of the next sleeper. The sleeper-pitch is only used for the junctions. It is not relevant for plain line tracks.

I gather from this that the single mesh sleeper used in the junction is just the model of the sleeper while when used in the lod table it has to include the "white" (1/2 the inter-sleeper spacing) before and after it.

Bob Pearson

PS.

I have a few questions re the procedural track when 1 or more of the attach "child" splines are designated as "visual-only 0", indicating that these splines are to be treated as separate stretches of track. The offset tag doesn't appear to work correctly with them. Also the original primary spline appears to lose that "track" function. I don't have any pics yet and I won't be back til later today.

I know this is probably going beyond what was envisioned but I do a lot of 3 rail dual gauge track. I got the same problem andi06 showed within the junctions. One spline section appears to be drawn in the opposite direction to the rest. Any asymmetric track will not render corretly in these junctions. Andi's 3rd rail for electric power or my 3rd rail to carry wheel loads from the trains of the 2nd track gauge show the same problem in the junctions.

My case is a little different though as I definitely need the 3rd rail carried thru the junction and not surpressed.

andi06
June 14th, 2015, 10:49 AM
Per the track guide on the wiki:
I gather from this that the single mesh sleeper used in the junction is just the model of the sleeper while when used in the lod table it has to include the "white" (1/2 the inter-sleeper spacing) before and after it.
I think that this statement is wrong. There is only one single-sleeper mesh (with two lod levels) and it is used within the junction zone and as part of the main LOD setup for very short track segments.

When you draw these meshes there can never be 'white space' at the top of the mesh, there must always be at least one vertex at Y = 0. The spacing tags provide the information for the game to work around this limitation.


I have a few questions re the procedural track when 1 or more of the attach "child" splines are designated as "visual-only 0", indicating that these splines are to be treated as separate stretches of track. The offset tag doesn't appear to work correctly with them. Also the original primary spline appears to lose that "track" function. I don't have any pics yet and I won't be back til later today.
I don't think that you can include any old child spline in the attached-splines table of a procedural-track, it has to have one of the pre-defined track-types. I've defined my conductor splines (in the component asset) as track-type "rail-left" but they must be added to the attached-spline table after the operating junction tracks. If you don't do this you will get blades on the third-rail!


I know this is probably going beyond what was envisioned but I do a lot of 3 rail dual gauge track. I got the same problem andi06 showed within the junctions. One spline section appears to be drawn in the opposite direction to the rest. Any asymmetric track will not render corretly in these junctions. Andi's 3rd rail for electric power or my 3rd rail to carry wheel loads from the trains of the 2nd track gauge show the same problem in the junctions.
Yes, one rail is certainly drawn back-to-front or inside-out. Interesting that they are easily able to mirror a track by mistake but are not too keen to allow us to do it deliberately.:)


My case is a little different though as I definitely need the 3rd rail carried thru the junction and not surpressed.
Best of luck to you. :hehe:

ZecMurphy
June 14th, 2015, 07:47 PM
I think that this statement is wrong. There is only one single-sleeper mesh (with two lod levels) and it is used within the junction zone and as part of the main LOD setup for very short track segments.


Hi Andi
The sleeper used throughout a turnout is the "sleeper_single" mesh in the config.txt (same as for the wing rails, blades, stretchers, and 'single' chairs and slide chairs). T:ANE does not use the track-lod-tree to create these sleepers (And hence, they don't currently have any LOD).

The built-in 'T:ANE' track also has a 'single sleeper' length version of the spline in the track-lod-tree. This is needed to 'fill' gaps created in specific situations (very short distances between spline points, or between the end of the 'junction' sleepers and the spline sleepers).

Regards

RPearson
June 14th, 2015, 09:07 PM
Right of course andi06. I also noticed the track will switch direction to match up with an existing one you are connecting it to. With asymmetrical track it becomes very obvious. However it doesn't do it in junctions. [Edit as you can see below the splines attaching at the junction vertex maintain the same direction in which they were set down - no need for speculation as to why]. I think the problem I noticed with part of the junctions being drawn in the opposite direction happened when I used the asset replacement tool replacing spline track with the procedural track.

I certainly will have to check to see if I have any obvious mistakes in the track container specifying the 3rd rail of the dual gauge track I was playing with. I probably will have to see if I'm using the rail_right or rail_left asset for the 3rd rail when the 3rd rail is added on the left side for "common rail on the right" track and vice versa. [EDIT I found mistakes so doesn't seem to make a difference if configs are correctly formed]

It seems that I can lay track in different directions to and from the junction and the results aren't so intuitive. See below pic where the long black arrows indicate the direction the track is layed. Note I use the common rail on the left when I reverse the direction I lay the track so it looks right. It did not end for end this track like it does outside the junction limits to make the directions match up.

http://i109.photobucket.com/albums/n74/EBTng3/TANE/TANE%202015-06-14%2017-10-40-171PT4.jpg

The above is really just a standard gauge track with the ng rail added and spaced at 36 in inside face to inside face for visual effect only. This is the same way I make my dg spline track now - and this track does connect up to it. An invisible track spline has to be add at the centerline of the ng components to actually carry the ng trains. With the Proc Track at least part of the extra junction eye candy might be added automatically - for the SG components. If I can make a child spline carry traffic then this could be a lot easier than I do it now (it does that now if I attach an old invisible spline track but it seems to act like the old kind bridge and not form junctions among other things). If I can't get that to work I can still make dg track essentially the same way I do it now except it can have a procedural track base instead of a spline track base.

All things considered the junction on the right doesn't look too bad at all. The sg rails have switch blades where they should and the both 3rd ng rails continue thru to the points. [edit - frog rails and guard rails show up as if it were just a std gauge turnout so nothing appears broken in that regard] The switch blade should be on the ng curved rail.

The junction turnout on the left has some problems - the curved 3rd rail ng gets stopped short but in reality this is the one that continues thur to the points and the straight rail is the one stopped short and the switch blade located there.

andi06, I'm looking forward to digging thru your new track assets.

Bob Pearson

EDIT: To set the record straight I checked the track configs and found that the configs have a mistake in them. a mismatch of rail-right with a left side offset and vise versa. Correcting those mistakes gives the correct turnout except for a missing bade on the 3rd (inside) rail. Of course we don't expect to see the 2 additional frogs or 6 additional wing rails though it would be a nice touch wouldn't it. 8-)

andi06
June 15th, 2015, 03:25 AM
Right of course andi06. I also noticed the track will switch direction to match up with an existing one you are connecting it to.
Yes, I think that this is a bug, since it doesn't happen with older style track and it makes it very difficult to use assymmetrical tracks.


The sleeper used throughout a turnout is the "sleeper_single" mesh in the config.txt (same as for the wing rails, blades, stretchers, and 'single' chairs and slide chairs). T:ANE does not use the track-lod-tree to create these sleepers (And hence, they don't currently have any LOD).

The built-in 'T:ANE' track also has a 'single sleeper' length version of the spline in the track-lod-tree. This is needed to 'fill' gaps created in specific situations (very short distances between spline points, or between the end of the 'junction' sleepers and the spline sleepers).
Yes, my point was that the wiki suggests that these are provided as two different meshes, whereas they actually seem to be the same mesh used in two different ways.

andi06
June 15th, 2015, 11:27 AM
Something that I cooked up earlier:

609

In this shot the track with ballast is a double track (bridge) asset with two p-tracks as attached splines, I've appended the config to the end of this post. You can attach a single track to any node of a double-track, if its an end node you can attach two single tracks. In both cases procedural junctions are formed and seem to work correctly.

The double crossover is formed by 'joining the dots' between two double-track segments. Sure it makes a bit of a pig's ear of the sleepers at present and it doesn't deal with the diamond crossing, but other than that its not bad. There is an added bonus in that you can raise or lower the two tracks together without generating red circles. This makes editing heights a whole lot easier and looks like this:

610

Note that the blades are correctly curved in section to lie in the plane of the running rail surfaces.

Looking at how they are configured, I can't imagine that there is any significant performance penalty associated with multiple tracks, no doubt Chris will correct me if I'm wrong or if he sees any other issues.



kuid <kuid:122285:8175>
username "Protrack B Double"
kind "track"
trainz-build 4.2
mesh-table { // must be present even though its empty
}
attached-splines {
left {
lateral-offset -1.75
use-same-direction 1
spline-kuid <kuid:122285:80100> // valid procedural-track
visual-only 0
}
right {
lateral-offset 1.75
use-same-direction 1
spline-kuid <kuid:122285:80100> // valid procedural-track
visual-only 0
}
}
istrack 1
track { // must be present even though its empty
mesh-length 18.00 // must be present, value not relevant
track-lod-tree { // must be present even though its empty
}
}
category-class "TR"
category-era "1920s"
category-region "00"
thumbnails {
}
kuid-table {
}

pcas1986
June 16th, 2015, 02:29 AM
That's looks very useful. The diamond crossing part is perhaps the only real problem. The sleepers in my shot below are a bit bunched and there is a gap to the right but I wonder if that is a consequence of the sequence of track laying I used. I did have a couple of tries before I got this version.

It would be nice if throwing a switch activated the corresponding switch on the opposite junction. i.e. the bottom left and the top right. I'll just leave that question open. :)

http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.06.16_17h19m39s_001__zps3jnskhy g.jpg

andi06
June 16th, 2015, 05:34 AM
The diamond crossing part is perhaps the only real problem.
I don't think that there is any code at present to detect situations where the overlap zones of 'Junction A' and 'Junction B' intersect, nor is there anything to handle the crossing. So the dog's dinner with the sleepers is to be expected at this stage.

I don't think that there would be any shame if Auran didn't handle double-slips or three-way points but they really have to develop a solution for a double crossover because its such a common track formation. The bridge trick makes it easier for a route builder to lay down and edit the junction, but it won't make life any easier for the coders.


It would be nice if throwing a switch activated the corresponding switch on the opposite junction.
Linking of junctions can be done with script although you have to very careful not to get into a contest with the AI. In fact a double-crossover like this has three mutually exclusive states, leading crossover, trailing crossover and the two straight paths. A single control point can toggle between the three or a change to any one of the four junctions can define which way all four junctions should be set up, the AI doesn't understand this, mainly because it doesn't understand that the crossing can't be occupied by two trains.

Presumably 'interlocking junctions' will include additional capabilities in this area.

On the main forum, Jeff Morris has pointed out that a double-track asset like this can also include bridge or tunnel meshes of its own which makes this very flexible. Its a shame that the attached-splines technique doesn't support 'use-adjoining-track-type 1' but you probably can't have everything.

pcas1986
June 17th, 2015, 01:09 AM
...

Presumably 'interlocking junctions' will include additional capabilities in this area.
....

After making the deliberately tongue in cheek comment, I thought about the issue for a while and figured it might be possible, but I had forgotten about the "interlocking junctions" goal. So, there is little point in doing anything just yet.

RPearson
June 18th, 2015, 12:22 PM
Thanks andi06 very interesting. Since build ver 2.9 the "kind track" asset has taken over for spline tracks, double tracks, bridges and tunnels. Pretty powerful stuff actually. I've been pretty much trying to play catch-up the last several years and I'm still loosing. The problem I was running into with the procedural track was if I tried to incorporate more than 1 visual and active spline in the track definition the junction making abilities got broken.

So 2 or more procedural tracks attached to a parent "kind track" spline (Chris should be showing up anytime now) still retain the properties of procedural track splines and can individually form junctions. Sounds just like what the doctor order. I know just what I'm going to try to put together this afternoon.

Apparently procedural and probably any track with attached splines will automatically swap end for end to match direction of track you're appending. I have some single track with unsymmetrical mesh and they don't change. Doing some testing on it I think it's always been that way for bridge and double track going back as far as TRS04 anyhow.

Bob Pearson

RPearson
June 18th, 2015, 03:18 PM
andi06 a question on your new Protrack:
I corrected the configs for my track (N3V clones) above. Now I see something more in line with what I was expecting. However I am still missing 1 blade - on the 3rd (inner) rail. See top track in pic below.

When I made a junction with your 3 rail (conductor rail outside) track I got no blades and the frog and wing rails were only on one side. See bottom track in pic below. I took a quick look a your config and rail "parts" and couldn't see why yours is missing those parts. What's going on here:?

http://i109.photobucket.com/albums/n74/EBTng3/TANE/TANE%202015-06-18%2015-42-08-056.jpg

Bob Pearson

andi06
June 18th, 2015, 03:48 PM
Not sure Bob. Mine were behaving like yours at one point and I don't recall changing anything since then.

However the way to form third and fourth rail junctions at present is to use a matching track without conductors for the junction itself, so I'm not particularly concerned.

Have you tried building two rails and a twin blade animation into your left-hand track? I wouldn't really expect this to work but you never know.

RPearson
June 18th, 2015, 04:48 PM
Haven't yet but the blade is there to use and certainly there's enough room. Clearly using track with no 3rd rail on the outside in your case is the way to go.

In your track I would expect to see the other half of the frog and the blade at the bottom. I mean if I can get 1/2 the frog rails why not gives us 1 blade?

Funny thing is if I replace the 3 rail track [EDIT: in the diverging leg only] with your 2 rail version I still don't get a full frog. nor any switch blades. With the info provided in the configs we should be seeing more stuff here. They found the point of the frog in all pics shown and where the switch blade ends in some of them yet they're not always displayed.

http://i109.photobucket.com/albums/n74/EBTng3/TANE/TANE%202015-06-18%2017-31-02-880.jpg

Bob Pearson

andi06
June 18th, 2015, 05:13 PM
I'm forming junctions in third and fourth rail track by drawing the root and branches first and stopping short of the junction. I then 'join the dots' with a matching plain track. Once the junction is formed I can close the two branch tracks up. This allows me to keep the track directions that I first draw. This is pretty close to prototypical except that the interruptions in the conductor rails are too long.

If I close up too far (as in the top track in the image) the wingrails and checkrails are suppressed.

615

On maps I've noticed that the blades are sometimes missing, a quick tweak of their position fixes it in Surveyor.

martinvk
June 19th, 2015, 09:22 PM
Yes, but not this week. Remind me again at some point :)


...
chris

Is it too soon to ask for the wiki diagram?

martinvk
June 21st, 2015, 07:55 PM
I think I've finally sussed how to use and apply the padding-length tag in my procedural track.
Here you see two small segments that illustrate the results.
642
The sleepers-lod0 mesh is 3.7 m long and with spacing-before and after of 0.15 m each, the total effective mesh is 4 m.



...
track-type "sleepers"
sleeper-pitch 0.5

mesh-table
{
...
}
track
{
mesh-length 4
padding-length 0.49
spacing-length-before 0.15
spacing-length-after 0.15
adjust-cross-section-to-ground 0
dont-scale-mesh-to-fit-length 0

track-lod-tree
{
lod-length 3.49

high-detail
{
subdivisions 8
mesh "sleeper_single"
}
When the track segment is less than 4 m long the single sleeper(s) are used. As it increases in length, extra single sleepers are placed until a sleeper-lod0 mesh can be used. That in turn get stretched until another single sleeper gets added. Up to 7 are then added until another sleeper-lod0 of 4 m is placed. etc.

martinvk
June 22nd, 2015, 06:37 PM
A few pictures of my track showing various junction configurations.
First a crossover
645

Next several closely spaced junctions.
646

If they are too close together I get the red warning circles.
647

The sleeper placement algorithm occasionally has a problem calculating the locations of the extended sleepers.

I also don't seem to have the repeating auto-naming of the junctions problem. Each one has its own number.