This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
dev:proposals:largetracks [2021-10-07 21:50] 56independent Add my idea |
dev:proposals:largetracks [2022-08-22 05:02] blockhead no to 15: addendum: rr online |
||
---|---|---|---|
Line 37: | Line 37: | ||
====== Opinions and Ideas ====== | ====== Opinions and Ideas ====== | ||
There will be several ideas and opinons regarding this. They are listed here, at this section: | There will be several ideas and opinons regarding this. They are listed here, at this section: | ||
- | * I think that this might work if a different mod is made. That way, server admins can choose between small or large track. This may also work as a setting, which defaults to the regular tracks, to prevent destroying infastructure on existing servers. ~56independent | ||
+ | ===== 56independent' | ||
+ | What i believe is a good option is putting both regular and large track segments in the mod, giving the choice between large track segments and regular tracks. This ensures backwards compatibility with existing rail networks whilst allowing large track segments on new line. | ||
+ | I also believe that simple junctions should also have their own segments. Building a t-junction is currently a lot of work, and i believe that a single-block spawner would make sense. You should choose between gaps, like 1-void for railyards, 2-void, and 3-void, as well as driving direction, whether it is the same on both sides or different. | ||
+ | < | ||
+ | ===== Blockhead' | ||
+ | Sorry about this wall of text, this probably isn't going to get much visibility, but I've been doing a lot of thinking over an extended period and I felt the need to dump it all out. | ||
+ | |||
+ | ==== Set track ==== | ||
+ | This idea bears a lot of similarity to orwell' | ||
+ | |||
+ | Model railways are pretty comparable to advtrains in a lot of ways. They are both played with for fun, and they both still have sharper curves than most real railways. There are a variety of manufacturers of model railway track for different scales and gauges. These come in pieces that can be snapped together. We could take inspiration from the product catalogues of some of those manufacturers and build our own ' | ||
+ | |||
+ | This would be quite model-heavy, | ||
+ | |||
+ | An an example of a poor implementation of this kind of system can be found in the Traincraft/ | ||
+ | * Different lengths of straight track. | ||
+ | * Sharp, Medium and Wide 90 degree curves. | ||
+ | * Turnout to two parallel tracks which continue for a long time - can't recall if both left and right-hand turnouts are available. Yards have to be built by chaining many of these and using a lot of space. Also the frog has a huuge gap. | ||
+ | |||
+ | Note in particular no diagonals, only wibbly-wobbly - the workaround is you can use their trains on minecart tracks and those have the usual zig-zag that works to travel in a straight line on a 45 degree angle. No diamond crossings whatsoever which means no realistic junctions whatsoever - not even a two-track T-junction is possible. | ||
+ | |||
+ | All in all we can only say that the Traincraft system, as directly copied, would be a feature downgrade. A successful //set track// implementation must therefore include everything we already expect from advtrains or more. | ||
+ | |||
+ | The set track system would fit into the nodedb format without issue, but the adjacent track node finding code would have to change to accommodate custom adjacent directions per registered node. It still may be worth exploring if it's worth changing the nodedb format - with migration code of course. For example, if the nodedb also recorded the connections that a track node has. This may make pathfinding quicker to compute by removing adjacency calculations; | ||
+ | |||
+ | ==== Custom curvature ==== | ||
+ | I want to stress that I don't see this type of system as realistic for the Minetest engine but it's worth exploring it anyway and discussing the challenges with it. | ||
+ | |||
+ | Another route would be to take ideas from the [[https:// | ||
+ | |||
+ | I'm not sure how the medieval engineers engine and this mod work together to store the rail information, | ||
+ | |||
+ | Inside the Minetest engine the height at each end of each track segment would have to be an integer, which is quite different to Medieval Engineers' | ||
+ | |||
+ | I'm also not how we could put these segments into the Minetest engine with some combination of nodes and/or entities. Nodes can only show a static simple shape, so they would work for straight tracks and predefined slope tracks. We would probably have to use invisible nodes that manage a series of entities. Each entity would be a sleeper or a small section of track or perhaps both in one model file. | ||
+ | |||
+ | We have to be careful with entities because (1) they have a serious performance penalty with the current Minetest engine and get_objects_inside_radius (2) if we do it wrong and the entity-track doesn' | ||
+ | |||
+ | Visual correctness: | ||
+ | |||
+ | To preserve visual correctness, | ||
+ | |||
+ | ===== doxydoxy’s Proposal ===== | ||
+ | I have explored the possibilities of larger track segments that align to the voxel grid, i. e. the “set track” approach. | ||
+ | |||
+ | The currently available 16 angles are fine, they align to the grid every 2m, and are compatible with '' | ||
+ | But the voxel grid is quite restrictive for the possible curve radii. | ||
+ | |||
+ | I have drawn 26.57° and 45° curves in Inkscape, and scaled them up in various sizes, to see which radii fit well on the voxel grid. | ||
+ | Of course, no radius fits without some stretching. | ||
+ | But stretching is possible well enough even with quadratic bezier curves, so it should not be an issue if the result //looks// fine. | ||
+ | |||
+ | I have chosen radii of 5.5m, 14.5m, 18.5m, and 35.5m. | ||
+ | (The half metre is caused by straight tracks ending on centers of node edges.) | ||
+ | I have drawn turnouts with the 18.5m radius, diamond crossings, and an additional set of “tram tracks”, which use only 5.12m radius and 45° angles. | ||
+ | |||
+ | I have also added sleepers to all track segments, and tried to avoid overlapping sleepers as far as possible. | ||
+ | Turnouts and crossings use parallel sleepers, aligned to the “more major” axis. | ||
+ | Many diamond crossovers and similar track layouts are possible with only parallel sleepers. | ||
+ | |||
+ | Because curves now consume more than one node, it is more difficult to do small lateral movements within one track. | ||
+ | Two adjacent curves move at least 3m laterally, if this is too much, the lateral movement must be propagated until a single curve is needed anyway. | ||
+ | |||
+ | Therefore I found it necessary to add off-center diamond crossings (to avoid the need for lateral adjustments when 26.57° tracks meet), and dedicated S curve tracks. | ||
+ | Compared to plain curves and turnouts, the amount of additional nodes is small. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | The result of my work is now available as {{: | ||
+ | To implement these track segments, more than 100 individual meshes need to be created. | ||
+ | I think someone should write a script collection to create these meshes. | ||
+ | Like this: | ||
+ | |||
+ | - An XSLT or Python script to convert an Inkscape drawing to a numeric description of rails, sleepers, switch blades, frogs, guard rails, and slide chairs. This should probably be divided further. | ||
+ | - Assign roles (rail, switch blade, ...) to individual SVG elements. | ||
+ | - Stitch rail elements together to get a continuous run (switch blade → rail → frog → rail). | ||
+ | - Calculate positions of switch blades in diverged state. | ||
+ | - Calculate positions of slide chairs. | ||
+ | - A Blender Python script to create a mesh from the numeric description. | ||
+ | * Be careful about UV mapping, so all track nodes can use the same texture. (A human could not do this >100 times without mistakes.) | ||
+ | * Make sure to use different materials (texture slots) for rails and sleepers. This will very likely be useful at some time. | ||
+ | |||
+ | The script approach allows to change the level of detail later, without discarding a lot of work. | ||
+ | For example, someone may think that guard rails and frogs are useless, or that slide chairs are important. | ||
+ | |||
+ | ==== 56i's Opinion ==== | ||
+ | Do the tram tracks come without sleepers? I feel that tram tracks should be metal rails driven straight into the ground, as you can see in below reference image (of points at St Peter' | ||
+ | |||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | What i think is a good idea is versions of these rails without sleepers and those with sleepers, for tram systems and ballastless track. | ||
+ | |||
+ | ==== 15 Degree Track - BreadBox64==== | ||
+ | I agree with the set state concept, but was wondering what everyone' | ||
+ | |||
+ | |||
+ | |||
+ | It gets a no from me due to combinatorial explosion. Adding two more angles of track doesn' | ||
+ | {{: | ||
+ | |||
+ | This would increase the amount of time needed to manually make them, making more obvious we should have an algorithm that generates the track shapes. But even if they' | ||
+ | --Blockhead 2022-08-22 02:47 (UTC) |