Southern Railways "Schools" V class [WIP]

[Gumboots]

I am totally loving this Blender gizmo. I have the model split into named components now, have got them colour coded with basic materials, and have knocked a few thousand polys off. Still more to do, but it's fast and easy once you get the hang of a few basics. New pic attached.

Schools_class_Blender_2.jpg (35.22 KiB) Viewed 12547 times

[Hawk]

Lookin' good.

Does this mean we'll be seeing some new steamers for the game?
Shame you don't like diesels.

[Gumboots]

Yup, some new steamers is the general idea. Fair amount of work in them, so I won't be churning out dozens in the next few weeks or anything like that, but since I figured out how to go between Blender models and RT3 I am a lot more enthused than I was before. Doing absolutely everything with just a hex editor is possible, but having done it myself it's really not something I want to keep doing (and I don't blame anyone else for not wanting to do it either).

It was worth doing as a learning experience, to really get my head around the way the files are coded, etc, but it's a nasty business for human brains. However, if the process can be reduced to having fun in Blender and Photoshop, followed by a bit of fairly simple cut and paste hexing, that's a lot easier and a far more attractive proposition.

As for diesels no, I'm really not into them. That doesn't mean you can't have any. It just means that somebody else will have to make them. Given how much work goes into a good locomotive model I'm only inclined to make ones that I like. However, if we can get the Blender > RT3 coding process documented then there's no reason why somebody else couldn't have a go at it. It'd be an ideal way of testing out the documentation.

[Gumboots]

I've been refining the mesh to knock the polys back while still keeping the looks as slick as possible. Screenshot shows the loco flat shaded for maximum jagginess, and it still looks pretty good to me. Current vertex count is 864 on the highest level of detail, which compares well with locos like the Red Devil, U1 or WP&P's custom Mallets. There are still some bits to add, but OTOH I can probably trim the mesh back a little bit more. I'll aim for 1,000 vertices with completed details.

Short version is that it seems that I'll be able to get a very smooth-looking model without much in the way of a game performance penalty compared to some default locomotives, and with some extra work for lower levels of detail it should be better for game performance than some custom locos that only have one LOD.

Schools_class_Blender_3.jpg (30.11 KiB) Viewed 12513 times

[Gumboots]

Been playing with LOD ideas to see what's achievable. I think I might grab the lowest LOD out of one of the default .3dp files to see what the original devs did there. So far I've got mine down to 162 vertices, which isn't bad. The default CtC U1 is 116 vertices on the lowest LOD, but some of the other models are a fair bit lower than that. Still, in a pinch I think 162 would be fine for game performance. It's certainly a lot better than the 800+ in many custom locos.

It turns out that there's no need to use Blender's decimate function for generating loco models with low LOD. Given that steam locos are basically built out of primitives anyway (streamliners aside) it's a piece of cake to just throw in new primitives (ie: 4 sided "cylinder" for the boiler instead of 24 sided) at the same length, height, etc. This gives a cleaner result than using decimate, which would probably work better for very complex meshes like high poly human figures.

Fortunately the .3dp coding will also be a lot simpler for the lowest LOD, and the basic UV mapping can be much the same, so generating several levels shouldn't be much of a problem.

Schools_class_LOD.jpg (25.92 KiB) Viewed 12499 times

[Gumboots]

Just took a look at some defaults. Basically I took the standard .3dp file header and copied that to three blank files, changed the byte for "instances" to 01, then grabbed the last instance out of each body.3dp file and pasted that to one of the new files. This gave me three default models on lowest LOD, viewable straight away in 3dConverter. The screenshot shows how they look, which was interesting to me as it indicates I should do things a bit differently to what I was thinking. No problem though. I can easily revamp the Blender model to be more in line with the default models.

If anyone wants to take a look in 3dConverter, I've attached a zip with the three default models in it.

RT3_models_lowest_LOD.jpg (110.71 KiB) Viewed 12443 times

[Gumboots]

Ok, sorted. New lowest LOD model for the Schools class, with 55 vertices and 45 polys. This is as good as any of the default RT3 locos, so no problem.

Schools_class_55_vertices_45_polys.jpg (55.48 KiB) Viewed 12440 times

[Gumboots]

Got some more work done on this. Wheels and cab are just basic game mesh, without any texturing, so that's why they're missing detail at the moment. Detail will be done with the texture of course. I'm going to start modelling the tender soon so I can work on both units together and keep an eye on the overall poly count. After testing the quick-and-rough H10 double header I know what totals I can aim for safely, and it looks like I'll easily be able to stay within that limit while still keeping the model looking as good as it can in RT3.

I expect I'll end up reworking several things as the modelling progresses, and I'll start copying elements out to a separate library file as well, just for ease of reference in future. My aim is to have a Blender > .3dp export script of some description working by the time I finish the modelling. I really do not want to have to do all of the conversion by manual hex editing, and Blender/Python is looking like it won't be that hard to learn for the stuff I need it to do. If I can do most of the code work just by exporting straight to useable .3dp code that will totally rock.

Solid.png (34.34 KiB) Viewed 12403 times

Wireframe.png (63.14 KiB) Viewed 12403 times

[Gumboots]

Hey I had a brainwave. I was playing with Photoshop trying to make a drivewheel skin for mapping, and it was being a bit of a PITA what with one thing and another. So, after looking at all the amazing stuff the Blender wizards make I thought well hey, why not just build a drivewheel in Blender, throw some sort of suitable material on it, put the camera smack in line with the axle, then render the result. That can then be cropped out to make the bit needed for the train skin.

It works. Basic jpg attached. Could do with a bit more work for materials and mesh, but it's basically all there and was arguably easier than making the same thing as a flat image in PS.

Basic_drivewheel_1.jpg (26.9 KiB) Viewed 12390 times

[Gumboots]

Made a bit more progress. It's shaping up alright for vertex and poly count. Should be able to bring it in under the double H10. The modelling is easy enough, even when LOD is considered, and skinning the beast won't be too hard. What I really have to work on soon is learning enough Python to write that export script. That will be an absolute lifesaver if I can get that working.

The pic shows some rough skins on the drivers. I'll make better ones before the final version. I've played around a bit more with the 3D driver model and that is pretty slick now, so should be good for shotz for skinning. It's no good for actually running in the game because it has far more vertices and polys than the actual loco model (up around 6,000 IIRC). It was worth doing just to get more of a feel for Blender though, and should make for a nice skin.

Loco_and_tender_WIP.png (545.79 KiB) Viewed 12375 times

[Gumboots]

I made a start on the UV mapping (ie: the skin image) just to get a feel for that. First stab at it was wrong and I ran out of space, but it gave me a good idea of what scale to aim for. Turns out 25 pixels per RT3 unit should work well for most components for this particular loco and tender. This is handy to know since the scaling in Blender after doing a UV unwrap is a bit hit and miss.

For comparison, average pixel density on the default H10 2-8-2 skin, and the Berkshire skin I made from it, was a bit over 10px/RT3 unit, so this means the detailing on the Schools class loco should be a lot better. The tender will be using its own skin image, like most RT3 steamers, but that will only need to be 768x768 on the A skin. I may even take it a bit smaller than that. All RT3 cares about is that it is less than 1024x1024, and divisible by 2 all the way down the LOD's, so I'll just make whatever size fits stuff at the same scale as the loco.

I'm already looking revamping some of the model's geometry for a better final result, and I've come up with a few new ideas too. Drive wheels are a case in point. These need to be at a larger scale than the rest of the loco, otherwise the binary transparency forced by RT3 makes them too pixellated in looks, which really screws up long narrow spokes. The drivers are being scaled at 256 px for the overall diameter, which is quite a large chunk of the skin. This means I only want to have one of them on the skin, but really they should have different counterweights.

The cunning plan here is to split the driver skin along the 45 degree line and only use half of it (repeated) for most of the wheel. The other half would be stripped down to just the outer rim/tyre. Since I'm using multiple planes to give better wheel looks, I can set the inner planes to pick up the skin that has all the bits and the outermost plane to pick up the bare rim/tyre. I can then set up another few vertices to do separate counterweights for each wheel at very little cost in skin area and polys, and place these between the outer rim and the first layer of spokes. This should give a good effect, with the right counterweights sitting inside the rim where they should be. Obviously on lower LOD they can be ditched, along with the extra wheel layers, to bring things back to a basic 4 vertex/2 tris square.

Pic shows the current state of the loco, with the smoke deflectors, smokebox, boiler, cab and drivers running actual trial skins (which still need more work). The rest is still basic Blender materials, but since it's going to be mapped at one Blender unit = one RT3 unit the skin detailing should be roughly this good in-game at the same camera range. The driver skins are taken off the latest version of the Blender driver model I made, and just need to have another shot taken once I model the axles ends, crankpin boss and counterweights.

Also attached a pic of the driver model and its mesh. This is a good way to learn more about using Blender, and I'd recommend it for anyone who wants to have a go. Make yourself some accurately detailed 3D components. Not only will you get better at modelling in Blender, but you can render the finished model as a handy chunk of train skin.

Update_28_03.jpg (42.03 KiB) Viewed 13463 times

22_spoke_drivewheel_render.jpg (41.86 KiB) Viewed 13463 times

22_spoke_drivewheel_detail.jpg (130.17 KiB) Viewed 13463 times

[Gumboots]

More progress. Got the front truck basic mesh and front bogie splash guards roughed out. Also went over the thing again and tweaked the model to more closely match reference images, saving a few vertices and polys in the process. Naturally the reference images don't agree with each other, just to keep me on my toes.

Also added some extra drivetrain bits. This is turning into a bit of a technical exercise to see how far I can push the limits of RT3's coding. The drivetrain bits will need optimising to haul the poly count back some, since at the moment they're using geometry for everything instead of the (eventual) use of alpha to do some of the work. However, as well as the standard pairs of coupling bars and connecting rods I'm getting a bit fancy.

The default 1.05 Beuth loco has an interesting trick, where an invisible and fixed truck is used to link extra "pistons" and "connecting rods" to the two drivers to emulate the valve gear linkages. This is a basic emulation, due to the limitations of RT3's coding. You can't get a true animation of the way the valve gear would work. All "connecting rods" have to be locked to the same wheel rotation in degrees, so the faked valve motion has to move in lockstep with the true piston (in the cylinder). Anyone who knows how valve gear really works and is paying attention can spot the faking easily enough, but it does add to the "round and round and up and down" steam train look and is quite effective for fun and games.

This got me thinking about how, and how far, you could fake Walschaert's gear. The default RT3 steam locos usually have roughly drawn and badly pixellated valve gear bits that are frozen in place and look disappointing. I think I've come up with a workable solution which will look convincing enough as long as you're more interested in fun than in strict technical accuracy. It's worth trying out anyway. Performance penalty will be negligible even on highest LOD, and obviously it can all be dumped for lowest LOD. This involves using the same tricks as the default Beuth, namely fixed and invisible "trucks" that have extra pistons and connecting rods. These are then hooked up to the required vertices and bits of skin to give the appearance of valve gear linkages and thingummies. It's going to require two extra "pistons" and two extra "connecting rods" each side, but only one of those connecting rods will have any visible elements. The other is just to meet RT3 coding requirements, since the game needs it to push the piston.

Fake_Walschaerts.jpg (78.56 KiB) Viewed 13441 times

The first connecting rod and piston each side are the usual ones you'd expect, connected to the cylinders. The second "connecting rod" will be the rod that runs from the short arm extending from the crankpin that is usual for Walschaert's gear, and goes up to the rocker arm that is hung under the side walkways (this is the rocker arm the reverser bar is also linked to on a real loco). On a real loco, the short arm from the crankpin is angled sharply to offset the valve timing relative to the crankpin, but on RT3 you can't do this. To get it to work in RT3, the arm has to extend from the crankpin directly towards the wheel centre. Not a big deal, IMO. Anyway, the rocker arm under the walkway becomes the second "piston". It won't actually pivot, and will just go forwards and backwards, but this will be ok if the stroke length is chosen carefully to match the required graphics. IOW, as long as the rocker arm doesn't visibly go flying off into the wild blue yonder at the ends of each stroke.

The only catch with this second piston-pretending-to-be-a-rocker-arm is that it will also move vertically to a small extent, due to the line from the driver centre to the arm's lower end not being horizontal. That means it's no good for faking the last bit of valve gear that goes into the valve casing above the cylinder. That last bit has to move horizontally to get the right effect. This is where the third (invisible) connecting rod comes in, to push and pull the third "piston". It has to be a third "piston" because it needs a different stroke to the main one, even though it is running from the same driver.

In principle it's all clear enough and will obviously run in-game. The only question is: will it look good enough to be worth bothering with? I'll get a rough and basic working model of it together soon and try it in-game while I'm finishing all the other stuff. I can use this same basic model for other purposes too like figuring out optimal geometry around bends for track attachment points and front truck attachment points, as well as preliminary testing for speed, pulling power, free weight, etc, so it won't be a waste even if the valve gear turns out to be a total disaster. I'm fairly sure it won't be a disaster.

And while I'm on the subject on pushing things, the Schools class was a three cylinder loco, and on three cylinder locos the centre crank and connecting rod are often visible from some angles. No prizes for guessing what I'm planning here. Again, this can be dumped on lowest LOD (in fact will probably disappear on the 3rd level/C skin) and will have negligible effect on performance even on highest LOD. The centre crank and connecting rod are simple and easy but attempting to fake the central valve gear is too much bother for no visible reward, so I won't go that crazy.

[Gumboots]

Ok, so that's valve gear. I've been trying a couple of other tricks as well. A lot of default locos use multiple (square) wheel layers to give fairly good faking of a solid wheel while keeping the vertex/poly count down. With the smoke deflectors being such imposing elements on the Schools class, and with the shape of them requiring alpha if you don't want the poly count going off the scale, I'm thinking this may be another place where several layers of simple shape could be used.

One layer is fine from the side, but the zero thickness quickly becomes apparent at other angles. I played around with using three layers (again, only on the higher LOD's anyway) with the inner and outer layer set back and down by a very small amount. This seems pretty effective, at least in Blender, so may be worth trying in-game. It'd probably be even more effective if the inner and outer layers only did the pipe framing, with the central layer being the only one which did the sheet steel. Dunno if I'll do that, since it will depend on how much space I allocate for stuff on the skin image for other stuff and which bits turn out to be more important. Obviously even this will fail for looks from directly ahead or directly overhead, as do the multiple layer wheels, but I thought it was worth considering as another technique to make RT3 do things it was never intended to do. Lateral thinking FTW.

The loco and tender as a whole are starting to really look the part now, even without skinning, so I'm getting very enthusiastic about seeing this thing running. Still haven't studied up on Python yet, so I'll have to stop having fun with modeling and get serious about scripting, or at least manage to do both.

Updated.jpg (48.21 KiB) Viewed 13440 times

[Gumboots]

Got some good news. I decided it was time I buckled down and started getting my head around Python (I really was not looking forward to learning another whole coding language from scratch again). So I posted over at the Blender forum, and listed and explained the format of the .3dp files so everyone would know what result I was aiming for. Next thing I know, a bloke throws up some code and says "Hey you could do it like this".

So I've read through the code and it seems to make sense (now that it's written I can take the syntax and correlate it with some basic Python docs and what I know the result has to be). Very clean and simple syntax. I may end up learning a fair bit of Python after all.

The next step is to make some very simple models, including suitable UV mapping, and use those to start testing the script for real. Bogies and trucks are a good place to start, because they are easy to code manually, so I can have a file I know is correct and see how that compares with what gets exported from Blender. Once I've checked to make sure the export process is free of bugs, it should be able to handle any model.

Short version: I can see us having a working Blender>.3dp export script ready to roll out in July. Beats me why we didn't have one years ago.

After that, the sky is the limit. We can model any game asset in Blender and actually get to use it in RT3.

[Hawk]

That sounds promising.

[Gumboots]

Yes, it sure does. I know it can be made to work. Now all I have to do is make it work. The guy over at the Blender forum seems to think coding it is a fun little exercise. I can see why, as I've done coding in other languages for people just for fun and to be helpful, but I'm glad he's doing the heavy lifting on this one. It'd take a lot longer if it relied on me learning Python from scratch.

Once this thing is working (and is it going to) I can see production of nifty models taking quite a leap forward. I have plenty of ideas which I've been ignoring, just because of the extreme amount of work involved in getting them into the game. I'm sure several other people have their own ideas too.

[Hawk]

Are you planing, or have you even considered, doing a Blender tutorial?

[Gumboots]

Oh and here's something: he seems to think it'd be just as easy to extend the script so it handles .3dp>Blender importing as well. Makes sense, since the file format is simple and code has to be written to deal with it anyway.

So, we may end up with what we've always wanted: the ability to import RT3 models straight to Blender, screw around with them as much as we like (adding faces and verts, deleting them, moving them, whatever) and then export the result of the screwing around straight out to usable .3dp.

Edit: Blender tutorial? Not much point me writing one. Their existing docs are very good. That's how I learned enough to make it usable, in very little time. Might have to add a few extra notes here and there, but reading the official stuff is an excellent start and doesn't take that long, because some of it is not relevant to what we want and the stuff that is relevant is not a major hurdle.

Best way to start is to look through their Noob to Pro tutorials and pick out the bits you think you'll need: http://en.wikibooks.org/wiki/Blender_3D ... Background

[Hawk]

Thanks! I have Blender. I might try it out. I'm used to Train Sim Modeler and 3D Canvas so I'm sure Blender will be a whole new ballgame.

[Gumboots]

It's a bit different for sure, but once you get into it a bit it starts to make sense. You'll be able to see why they did things the way they did. IOW, it's different but not stupid. There was a lot of thought put into it, and it's basically a very good app AFAICT. The only other 3D app I was used to is Delftship (developed for ship and boat modelling) and I found adapting to Blender wasn't too bad once I actually RTFriendlyM. RTFriendlyM is definitely essential though. You can't just wing it without reading up on the basics. That will just drive you nuts (I tried it ).

There are some things we should probably have documented specifically for RT3 modelling, but those can be sorted once modelling is possible.