Differences

This shows you the differences between two versions of the page.

--- dev:proposals:largetracks [2021-10-09 15:16]
56independent [Opinions and Ideas] Format to fit rest
+++ dev:proposals:largetracks [2023-01-13 12:06]
56independent [56independent's Opinion] Add example makefile for my silly little script and publish it for complaints
@@ Line 39: / Line 39: @@
 ===== 56independent's Opinion =====
-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
+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.
+<del>Also, 2-void is for those who like making a pain for themselves and hate ornaments in the centre of track, such as pillars and signal poles</del>
+As a fluent python programmer working a little with some models, i have already created a small language determining how different .obj models can be edited. Creating a series of rotations for large track segments wouldn't be too difficult (i have already written unreleased and untested python code to do this automatically).
+For example, to merge two obj models, you can do ''signal_mast+ks_signal_front'', which would put together the blue signal mast and the black part of the Ks signal. To make a series of rotations, you could do ''dtrack_st*r'', which would make versions of ''dtrack_st'' rotated by 22.5 degrees (half of 45 degrees, should be the knight's move track) each.
+You put all these commands as seperate lines in a file and pass the filename to the script:
+<code>
+(signal_mast+ks_signal_front)*r
+dtrack_st*r
+dtrack_switch*r
+</code>
+Brackets are not yet supported though (but i would add support if requested)
+This could easily reduce the effort needed to make the different models.
+If you wish to be see the code, visit [[https://pastebin.com/28yvuj6D|This paste]]. For any questions, contact me.
 ===== Blockhead's Ideas =====
@@ Line 78: / Line 100: @@
 To preserve visual correctness, we would realistically have to include a static set of all of these components - diamond crossings, turnouts and double slip switches - similar to what we have, also similar to the set track approach. Then at the end of custom curved track sections, the track would have to be aligned at the right angle so that it goes into the component. The track placer would enforce this of course.
+===== 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 ''moreblocks'' table saw shapes.
+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.
+{{:dev:core:doxydoxy_smooth_tracks_sketches.png}}
+The result of my work is now available as {{:dev:core:doxydoxy_smooth_tracks_sketches.zip|Inkscape SVG file}}.
+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's Square in Manchester, and some straight sections just around).
+  * [[https://i.imgur.com/6G1nPU8.png|1]]
+  * [[https://i.imgur.com/7hJS5zv.png|2]]
+  * [[https://i.imgur.com/bEEdo1h.png|3]]
+  * [[https://i.imgur.com/bEEdo1h.png|4]]
+What i think is a good idea is versions of these rails without sleepers and those with sleepers, for tram systems and ballastless track.
+No, my proposal would have sleepers on all track nodes.
+To make tram tracks, you would put the tracks 1/8 node deeper, using https://github.com/minetest/minetest/issues/12352.
+This allows to use all track nodes both with and without sleepers. --- //doxydoxy 2022-09-13 10:21//
+==== 15 Degree Track - BreadBox64====
+I agree with the set state concept, but was wondering what everyone's opinion on 15-degree track is? I think that having 0, 15, 30, 45, 60, and 75 degree track pieces would help make curves look more consistent and allow certain alignments that would look weird otherwise. Considering the scale of these changes, I think integrating 15-degree track would make sense.
+It gets a no from me due to combinatorial explosion. Adding two more angles of track doesn't just add straight track segments, it adds basic turnouts, y-turnouts and 3-way turnouts at that angle. It also adds diamond crossings that cross each other at that angle. The crossings are a particularly bad problem. According to my calculations there are 28 possible shapes with our current system (though some are omitted due to being too shallow of an angle, so we have more like 20). Angles wouldn't be a problem with a large track segment. But with a 15 degree system, there are 66 different combinations. Diagram:
+{{:dev:proposals:crossing_combinatorial_explosion.png?200|}}
+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're made by algorithm, each one adds to the media file size of advtrains, for shapes that maybe nobody will ever see. Finally, it's a block game, not a train simulator: I think we should be content to even have the 30 degree system, since carts don't even really have a true 45 degree system. If you want a good game with voxel terrain and a good track system, try something like Railroads Online, not Minetest.
+--Blockhead 2022-08-22 02:47 (UTC)
+(Sidenote, afaik Railroads Online is not voxel-based internally and certainly isn't in-game, it's free placement.)
+I think adding the necessary turnouts would not be much of an issue, I estimated file size based on the existing models and came to a total of 494KB for all straights, curves, and switches, which would only increase the models folder from 3.62MB to 4.11MB, which isn't too bad in my opinion. On the other hand, I hadn't fully considered the number of crossing pieces and I agree with you that it's an excessive amount of models that won't see much use. I went by hand and calculated how many crossovers would be required, advtrains right now has 17 crossing models, and with 15 & 75 degrees this increases to 41 models. When I estimated the file size change it came out to around 2475MB bringing the net file size to 6.59MB, a bit less than double the current size. I am not convinced this is necessarily a deal breaker, especially considering the number of models set-state track would take. However, this would definitely necessitate the creation of a model creation script. The other option would be to not add the crossings, just the straight, curved, & switches. In my opinion, even though this is inconsistent, it is no more so than the current missing angles, as we effectively have a 15-degree system with 2 angles missing rather than a 30-degree system.  --BreadBox64 2022-08-23 04:40 (UTC)
+Besides the combinatorial explosion mentioned by Blockhead, I think there is no real visual advantage.
+First, the current angles are 0°, 26.57°, 45°, and 63.43°.
+If we add another one at “15°”, that would mean 14.04° (1:4) or 11.31° (1:5).
+Then we could argue whether there should be more angles between 26.57° and 45°, e. g. 33.70° (2:3).
+Second, these angles will look nice at places where a single track line transitions to double track (like in front of a station).
+But they are less useful than 1:2 for open line, because no blocks can be shaped in 1:4 or 1:5 slopes.
+--- I think additional angles (for smooth transitions) can be useful as add-on.
+Without providing turnouts from 14.04° to 26.57° and so on, and without diamond crossings.
+Similar to the tram track set visible in my proposal, which serves specific uses but is not as complete as the track set otherwise. --- //doxydoxy 2022-09-13 14:11//

Advanced Trains

User Tools

Site Tools

Differences

Page Tools