[tooltroll]

I'm newly registered, so write me off as a noob if you like, but I've been a member at TrainSim.com since 2004, and lurking here almost as long. I'm not just some naive kid, so you might consider the following:

Lindsayts, on 13 June 2017 - 01:57 PM, said:

An important (I think ) off topic comment...............

Earlier in this thread an OR developer said there were few active route developers, this does appear to be true. The reason's are..............

(Lindsay gets on soap box..................) :)

MSTS is seen is old hat

MSTS's editor and and tools do not run well on latte versions of Windows.

MSTS's editor and tools are diffciult to use as is.

OR itself does NOT at this stage have a route editor.

OR REALLY requires a route editor now, the justification that we will not work on a route editor as few are using it is SELF DEFEATING and is a sure way to destroy OR on the long run.

Lindsay

Lindsay is exactly right. Look, I got into train simming because I got frustrated with the space and financial outlay required to build an actual model railroad, and I imagine that I'm not the only one, in fact I'd guess that a large portion of train simmers are former or frustrated MRRs like me. I want to build routes! But the editors with MSTS are cantankerous, kludgy afterthoughts and I don't have the patience to deal with their inconsistent behaviour and constant crashing (and I'm well aware that others have been using them successfully, but that's them, not me.) I have been patiently waiting for over a decade for the OR team to introduce an editor, in vain.

The only reason I'm resuming route building is because Goku wrote TSRE. As Lindsay has pointed out, the OR team's refusal to deal with the editing issue is a grave error in judgement that is only serving to drive people away to other sims, as I did for over a decade. Shades of the VHS/Beta wars, and if the superior product (OR, in my opinion) lacks support, it'll suffer the same fate as betamax, for exactly the same reason. Yes, physics is important; Yes, realism is important; But not everyone is as hung up on them as the OR developers seem to be, everyone has different priorities, and I think the devs need to reexamine theirs, in light of what the community needs. Are you doing this for the community or strictly for yourselves? Frankly, a lot of the devs' comments on this thread read like pouty children jealous of someone else playing with their toys; So Goku hasn't made his editor in exactly the way you'd like? At least he's addressing this grievous lack of vision on the devs' part, and that's good enough for me. If his idea for procedural track works half as well as the rest of his editor, it'll still be better than the MSTS editors, and infinitely better than the still-nonexistent OR editor.

Bob

[Stephen Hjellum]

Bob hit the nail squarely on the head with a wide mallet. Plenty of us in this community (and others) desire a better solution to the click and drop methods of MSTS's editors. I myself have been clamoring for a similar track laying method as seen in RW, as it's simple. Drag, move to where you are going, rinse and repeat. One problem though, Bob. Goku seems to be more oriented on the shapes themselves, instead of coding to provide the 'elastic' track, that we desire. That brings up a question: is procedural track a matter of coding, or track laying? For me, I prefer RW's method, over Trainz and MSTS, and hope that Goku keeps this in mind as he continues his efforts to provide a practical, usable editor as he has been. I have a lot of faith in Goku's work, needless to say that he's the only one who stepped up to the plate that the Dev's refused to consider. Yes, there's a lot of bugs in ORTS. But yes, I agree, there needs to be a balance between debugging, and building an open source program. At least ORTS isn't locked out like R8 or TSW.

[tooltroll]

To be honest, I'm content with working with sectional track, at least for the time being. To be fair, I haven't tried the newer releases out there. I had a copy of RS2008 after I got fed up with the MSTS editors, and the procedural track was still kind of twitchy. I did like the ability to 'draw' in crossings and switches wherever I needed, but I found that often I was running into invisible, undocumented size/length constraints in its abilities. Places where it looked like I should be able to drop in a switch wouldn't work because they were, apparently, too close to some other feature.

However, having sampled the quality of Goku's work thus far, I'm willing to trust that he can execute procedural track in a better fashion than I've seen in the past.

(Digression: What I'd really like to see is procedural scenery, especially vegetation. Using forests and gantry.dat tricks helps, but imagine if you could run a route through a routine that would plant all your trees, bushes, etc., based on elevation, distance from water, distance from track/roads/buildings, with perhaps some cues from the terrtex and maybe an additional texture layer. I don't know about you, but for me the real time consumer in building routes isn't the track or the buildings, it's all the weeds, grass and trees. :) )

Bob

This post has been edited by tooltroll: 07 August 2018 - 08:56 PM

[tooltroll]

Stephen Hjellum, on 07 August 2018 - 03:51 PM, said:

That brings up a question: is procedural track a matter of coding, or track laying?

Oh, and I forgot to address this. I don't think it's either, actually. Goku can code his editor as he sees fit, allowing any and all modes of track laying he cares to incorporate. Someone correct me if I'm wrong, but as long as the entries in the TDB conform to spec, the specific code used to create those entries doesn't really matter, does it?

Bob (Again. Sorry.)

[ebnertra000]

tooltroll, on 07 August 2018 - 08:56 PM, said:

...

(Digression: What I'd really like to see is procedural scenery, especially vegetation. Using forests and gantry.dat tricks helps, but imagine if you could run a route through a routine that would plant all your trees, bushes, etc., based on elevation, distance from water, distance from track/roads/buildings, with perhaps some cues from the terrtex and maybe an additional texture layer. I don't know about you, but for me the real time consumer in building routes isn't the track or the buildings, it's all the weeds, grass and trees. :) )

Bob

Well, you'd better get started. I highly doubt that that's possible unless the whole software is basically redesigned to that sole end.

In the end, the real test of a route builder's ability isn't in laying track, or roads, or interactives. It's in making the scenery look convincing. I honestly don't think it's possible to program nature in such a way that it looks, well, natural. I wouldn't want to use such a method anyway. If I'm going to build a route, I'm going to be the one who actually puts it together - not some bit of code

[conductorchris]

It actually should be possible to make convincing looking "random" nature. That's because chaos theory tells us that there is a mathematical formula under the randomness. The leaves of a tree look random, but are actually the same pattern as the coast of England and a host of other natural phenomenon.
Christopher

[ebnertra000]

I suppose that there is some degree of method to the madness of nature, but what kind of mathematical formula would it take to replicate the natural World. I bet it would be pretty intense, and math was never my strong suit. I think I'm just going to keep planting trees in the meantime


EDITED: Rounded up a missing word

[tooltroll]

Unfortunately, unless I can write it in BASIC or 6809 machine code, my programming skills are quite obsolete. ;)

I can ponder the concepts required, though. This could be implemented in an editor or as a standalone utility.

Basically, it would read the data in from the tiles, terrtex and .w files, and place vegetation objects according to some rules, for example:
Nothing in or on existing track or objects; (Duh!)
The closer to track and objects, the smaller/less dense the veg;
The lower the location or closer to exposed water, the taller/denser the veg;
Lookup a user defined table to compare terrtex colour with veg type (The user could specify colour ranges to tell it to use specified weeds where the terrtex is yellowish, for instance.)

The 'Veg-O-Matic' could also use its own texture overlays to control how it 'plants' things: Import the terrtex/bounding boxes for reference, and the user could 'paint' areas to control certain things. It could be as simple as a grayscale .bmp governing plant density where white=plants and black=no plants. Or, each different type of plant could have its own grayscale 'density' overlay, or be assigned a certain overlay. It could do all this internally and then just add the vegetation object entries to the .w files. Any extra overlays as described above would not be used by OR, just by the Veg-O-Matic. It'd be one of the last steps in building a route, and you could then open it in your regular editor and double check that everything got planted ok, and perhaps finesse it a bit if required.

The issue I see with this approach is that all the veg would be static objects and not make use of the forest method of saving resources. I've never quite understood why it's done the way it is: Forests use less resources because they only have to load the shape and texture once, correct? Why the heck didn't they have all repeated objects use the same method? Say I've got a forest of Tree1, and some 'individual' Tree1 trees also sprinkled here and there; If the Tree1.s/.ace are already loaded for the forest, why doesn't it just use those for any subsequent copies of Tree1 it needs? Probably some deep technical reason, but imagine the performance benefit if all the trees on a route, or at least a tile, were only loaded once for each type.

Bob

[jtr1962]

The big problem with procedural vegetation is the need to introduce enough randomness to make it look convincing. That requires a lot of computational power. And incidentally, the same lack of randomness in vegetation is in my opinion one of the big things detracting from the realism of most routes. You might have a few types of trees or shrubs. You can intermix them, but eventually the repetition becomes obvious. You might start saying to yourself why are all the pine trees the same shape and height? One way I can think around this is to have a special kind of shape file for vegetation. Each part of it has a number attached. The computer generates random numbers, and only renders the parts which have those numbers attached. A tree designer might design the object in such a way that one random number represents the height, another the fullness, and so forth. You only need to load one set of textures and one object, but the same shape file could be rendered thousands or millions of different ways.

Procedural shapes are great for things which are always more or less the same shape, like tracks or fences or catenary, although even for those you might introduce a bit of randomness in the track bed.

[tooltroll]

jtr1962, on 08 August 2018 - 02:38 PM, said:

The big problem with procedural vegetation is the need to introduce enough randomness to make it look convincing. That requires a lot of computational power. . . One way I can think around this is to have a special kind of shape file for vegetation. Each part of it has a number attached. The computer generates random numbers, and only renders the parts which have those numbers attached. A tree designer might design the object in such a way that one random number represents the height, another the fullness, and so forth. You only need to load one set of textures and one object, but the same shape file could be rendered thousands or millions of different ways.

Fair enough points, but there are ways to compensate, and I like your idea of having more than just width and height randomised, as you can in forests. I'm not quite sure if you mean just assigning more randomisable attributes to the whole tree, though. I see it kind of like this: Blender has a 'sapling' addon that breaks down the tree into a hierarchy (or 'tree', if you will ;) ) of trunk, big branches, little branches, and so on, that may prove instructive: What if a tree came in pieces? Each piece could have a random chance of existing for each tree, so the trunk would appear 100%, each of three or four (?) big branches could appear, say, 60%, and each big branch could have three or four (?) little branches that each appear 40% of the time. The leaves would be part of the final branches in the hierarchy. Some 'final' branches could come in a few variations, as well. So the tree designer would make the whole tree, positioning all the branches, sub-branches, etc., and assign them probabilities, and at editing time, the software could throw dice to see how much of each tree gets included in each instance. At runtime, you'd load several small objects and textures that could then be used to 'build' the trees. Is that along the lines you're thinking?

Regarding the computational power requirements, the computations will be done at editing, so this is only a concern for route builders. Personally, I'd trade an hour or two of the computer chewing on a tile for spending days doing it myself.

Bob