Rather ancient carriages I have made, looking for critiques

[TrabantDeLuxe]

The unavailability of routes hasn't stopped me though . That said, I'd be all in to contribute to an epoche I route!

[AndiS]

For an epoch I route, we should see what TSW offers. If they do a leap towards intelligent figures that perform some act in a believable fashion, then early steam would greatly gain in attraction. It is all about people walking about and turning handles, of switches, brakes, crossing gates, etc.. And cab were pretty open, and observing the train was very much required.

Such a route would be a perfect freeware project as it is far from commercial interest. I would be happy to script a dozen figures doing prototypical stuff, if that would become possible. It all depends on the hooks that DTG provide. Motion depends on train location, door location, footplate location (at wagons), switch handle location, brake crank location. DTG will have to provide shunters who wave their flag anyway, or would they claim that entering your engine is the only human activity in a yard?

So I just sit there and wait what unrolls during 2017. It can be great and it can be a great disappointment. In the worst case, we will again stack individual extensions onto the core, this time with greater power because of the strong base system.

[malkymackay]

To get an idea what kind of interaction UE4 is capable of, then have a look at this: https://www.youtube.com/watch?v=cTI7629Fjro

[AndiS]

I know that these videos are just demos, so the following is not meant to disparage the work shown.

My first thought was: you can do that in RW. But the second video (where the handles are framed in blue or violet) shows that the idea is that the player would be signaller.

If you watch the signaller figure in 3rd person mode, you find that (1) he does not touch the gates when opening them, (2) he does not touch the stairs when taking them, (3) he does not touch the levers when operating them, nor the block device.

So this nicely illustrates what I fear as a worst case: You can have figures walking about, and you can script their animations, but there is no data structure to get the hand of the figure to the gate, lever, handle that needs to be operated. And I mean, the right one, not just some handle so it looks good enough from outside.

You can make signals send a message to the signal box saying "I open now", "I close now" (if the signal box is a "signal" that has a listening track link in each track). Then you could have a figure in the box grab some lever and do some animation in sync with the signal animation. You could even send the lever number so the lever grabbed depends on the signal that changes. However, this is just a gimmick that would stand alone.

I considered modelling the block working messages in more detail in RW signals, but then thought "what the heck".

Likewise, I am not sure how many people would be attracted by the option to be signaller. Sure, it can be a nice change. But it needs to be done very good to attract people for any longer.

DTG could be testing the waters with their train spotter feature, or it was just an imitation of a new feature -- under the cover it was an old trick that never got exploited much.

At any rate, the video again shows that there are protocols to be followed. Since you need AI to be able to jump in, you need to some formalisation. Either AI deciphers the bell signals the same way a human would, or you send a number signifying the message along in parallel to playing the sound.

Of course, you could deny the need for AI to jump in and imagine a situation where all the signal boxes are staffed by players, but that would create huge synchronisation issues with the real world.

I had been daydreaming about AI drivers that look at signals and indeed interpret rendered images. There would even be some shortcuts. I vaguely remember some system call where you could query whether a certain material would be within eyesight from a certain position, but I can't even remember whether that was UE4 or not. Making signal lights of that material would simplify the recognition process. It should also be fun to simulate brakesman or shunters listening for whistles, and missing some because of all the noise. But such are just daydreams, not proposals for a game that will recover its development cost.

Also, this is not even one of the TSW speculation threads. Given that, the video mostly shows that you need data structures to make figures look good. These could be supplied by the system, like cargo transfer points and doors at coaches and platforms. Then it is easy to combine creations from different people. Or the data structures are based on some private initiative. E.g., the signal box can share information with the signaller figure that is supplied, but not with one the is created by someone else. Unless they agree to cooperate. This is what we have in RW now, and I hope it will be better in TSW.

[JamesLit]

With what you were saying about not touching, no actual hands reaching out and grabbing the objects etc, that's entirely possible to do, it's not a problem at all. Just obviously needs the effort made to do it.

[AndiS]

Yes, that is exactly my point. A ton of things are possible, in UE4 and in general. The million dollar questions are: What are the priorities that management set based on marketing research? How much do they get (in terms of features & sophistication) from their programmers, for the allotted money? And how much railway knowledge was used in designing these features?

The Semmering route showed that DTG still do not have knowledgeable contacts at the local operators who help them with stuff like signalling. So I am not putting all my money on them creating a framework that directly supports all the railways things of the world and does not limit their implementation. With some luck, we get an open system where any part can talk to any other part. Then the community of creators must come up with interoperability standards. Or their creations will remain incompatible. This is where I see the real challenge.

In other words, I do not claim that Sly can't make the figure grab the right handle. I say that I am not sure that creators will come up with openly accessible data structures where creator 1, doing the signal box, stores the location and function of all the handles and creator 2, doing the signaller, takes this information so his figure grabs the right handles in a signal box supplied by any other creator.

Now a signal box might sound too ambitious, so look at this simpler -- and more on topic -- example. On the continent, early steam trains had lots of brakesmen in rather open huts, not just one guy in a brake van, because there were no brake vans. Now will this figure of a brakesmen who turns the crank be part of the wagon model, which means it is there all the time? Or will there be a generic brakesman that can be placed on any wagon (give or take the animation of mounting the wagon or even walking to it from some hut). If there is a data structure specifying the brake crank and this data structure is accessible for anyone, than anyone can create such a brakesman and the scenario can define which of the brakes are manned (which is prototypical, because the percentage of manned brakes depended on speed and gradient).

This is where epoche I is more demanding on shared data structures, as more workers are visible. In later years, all you got to model is the working of the brake valve, and that can be done local to every wagon, without any change in the visuals.

[VictoryWorks]

Likewise, I am not sure how many people would be attracted by the option to be signaller. Sure, it can be a nice change. But it needs to be done very good to attract people for any longer.

Just to comment on this part, I really am.
I currently play these http://www.blockpostsoftware.co.uk/ and these http://www.pcrail.co.uk/ and the thought of doing all this in 3D has been digging away at me for a while.

I may be wrong but I suspect that TSW will likely not get into the signalling in this much depth. I can see them having a dispatcher view where someone operates a network (especially for multi-player) but having individual signalmen operating a block system seems unlikely. So I'm REALLY excited for Paul's project - maybe even more so on a personal level than I am for TSW - and if he wasn't building it then I'd be trying it myself. I've already discussed some concepts with him on how I think it could work as a modular system where you put "blocks" together to form the network.
My only complaint on that video is that no self respecting signalman, even at the end of mechanical working, would ever let their signal box get that tatty and run down! They were pristine places where you could see your reflection in the floor and in all the brass work. But clearly Paul has used stand in textures, etc. for this. Getting the art assets correct is the last thing you do, getting the code base working is the priority; it can look pretty later

And apologies to Trabant as this is TOTALLY off-topic for his thread

[TrabantDeLuxe]

No worries, there's no such thing as a central topic here. Sly's work certainly looks interesting.

On the topic of walking your character in a sim to go places and do stuff, who here has played Silent Hunter? You're a submarine skipper and your job is to be an absolute pest to shipping. Up to SH4, you'd have little tabs at the bottom of the screen to take you places. Navigation map, periscope, hydrophones and the lot. And then SH5 came along. Now you had to actually walk places. At first, I hated it. But as time grew on, it became more immersive. Simply clicking a periscope icon is a lot less immersive than diving down the acces hatch, running forwards to the hydrophones, and then getting back to the scopes. Under the obligatory alaaarm and flüuuten screams of course .

Now from a modellers standpoint it means even more bits to model, and I'm not too happy about that .

[AndiS]

I must add that my own interest was not mentioned above. I meant (just like Pete) that DTG are not too likely to create an in-depth simulation of signalling from the signaller's perspective because the market for that is not exactly huge.

As far as I am concerned, I am not much of a driver. I'm not much of a player anyway, but a 3D version of SigSim would certainly something that I must have, if only to try it out. And steam era has my interest much more than modern times.

However, being a signaller at any box that can maintain some interest for some time is no easier than being a driver, so the same people who declare that driving a steamer is too complicated will declare signalling too complicated.

If and when Paul intends to release his project, then there will be the question of compatibility with TSW. It would be a shame if every original creator would have to export his stuff twice. Though in practice, this is how things are.

Half a decade ago, in one of these intense phases of frustration with RW, I dreamt about a little sim without cab view using MSTS rolling stock with proper time tables and physics; and some game engine. But the offerings back then turned me off and I am still realistic enough not to spend too much time with such a dream. And I am not often realistic.

[TrabantDeLuxe]

Tech Time!

Normals and you. All taken using max's default viewport shader, showing realistic materials. In the interest of clarity, I've disabled diffuse and specular textures.

• Top Left: Low poly, game ready model. Note that the smoothing is all wonky - I've given each UV cluster a seperate smoothing group.
• Left: Low poly with normal map applied. The normal map has two purposes, to give the impression of extra geometry and smoothing - using a high poly bake -, and to give a textured appearance to the model. This is done by simply overlaying a texture in photoshop.
• Right: High poly. My main workflow is to use the low poly, clean up geometry a bit to obtain all quads, add support loops and use the turbosmooth modifier. I believe Arrimus 3D has got some great videos on this process on Youtube. His tutorials are highly recommended anyway, go watch them now.

The reason I set the smoothing groups to the UV clusters, has to do with how normal maps work. The basic premise is that softening a 'hard' edge (where two smoothing groups meet) using a normal map causes inverse colours at either side of that edge. Now normal maps are of finite resolution, and artefacts will show up. Setting single smoothing groups has the added benefit of reducing in-game vertex count, as remember, a vertex on a hard edge is considered two be multiple vertices in-game (as the game engine has to calculate multiple vertex normals in stead of one). I have noticed performance increases since reducing the number of hard edges - although I'm not confident to attribute this to only the former.

You might note some shading errors in the LP model. This has got to do with the fact that smooting a 90 degree edge with normals is a bit finicky. Ideally, you'd set these to hard edges, seperate the UV clusters, and bake that way. Another thing to note is that TS seems to use a (X+, Y-, Z+) tangent basis. If you bake using the more common (X+, Y+, Z+) basis, you'll have to flip the green channel before export.

Thread about the above on Polycount, where people do a much better job of explaining this.