3dp File Converter

[Gumboots]

Yeah I read around the web a bit and Blender is notorious for learning curve.

Had another thought. The app I'll be using will export as .dxf, like most of them, and there are free online conveters for .dxf to .3ds. That might be handy. Skip Blender and just get the .3ds directly from the original .dxf. Might try it. Got nothing to lose but my sanity. Most of it's gone already.

[Hawk]

I take it you have an app for 3ds files?

[Gumboots]

Not at the moment (apart from Blender) but one of the guys earlier in the thread was saying the hex from his .3ds (exported from Blender) was usable if pasted into an RRT3 .3dp.

[Hawk]

I believe 3D Object Converter - http://3doc.i3dconverter.com/ - will handle 3ds files.

[Gumboots]

Oh I've got that one. However, when the free version takes a .3dp from RRT3 and exports it as .3ds, the resulting file is about one third the size. I think it's dropping a lot of code that should be kept.

[Hawk]

I was afraid the free version would be somewhat restrictive.

[Gumboots]

I've found the default settings aren't best for modelling RRT3 stuff (IMO). The medium/dark blue surfaces make seeing the points and face edges more difficult than it should be. If the window background is set to a pale grey, vertices set to orange, and surfaces set to a fairly light blue-grey that mimics the old works grey, things look a lot easier to work with.

One tip I didn't screenshot is under "Draw" in the main menu. By default, any face that has a normal pointing away from you will vanish from view. If you turn on "Show backward-facing geometry" under "Draw" it will show both sides of the object regardless of viewing angle. That can be handy sometimes. I prefer it for general use.

Other tips are shown in the shots.

3D-Object-Converter-general.png (33.65 KiB) Viewed 6300 times

3D-Object-Converter-custom.png (26.72 KiB) Viewed 6300 times

3D-Object-Converter-custom2.png (32.8 KiB) Viewed 6300 times

3D-Object-Converter-custom3.png (30.55 KiB) Viewed 6300 times

Then just hit "Apply" as usual.

[Gumboots]

Well, the licence on the trial version has run out, so it no longer works at all. Apparently there's a thirty day limit. So, now I have to decide whether or not it's worth forking out $50 for the full version. Hmmm.

[Wolverine@MSU]

Do you have another computer (laptop or another desktop) that you could intall a trial version and get another 30 days?

[Altoona+BeachCreek]

My goodness, god forbid the FBI ever discover this site! you wouldn't expect a layer back website like this to be harbor to be harbor isn't such under handed computer uses...

[Gumboots]

I already thought of that. However, that still leaves me screwed in another thirty days.

[Gumboots]

Ok, bumping this. Given what Tomix has been up to this is probably worth another look.

Itsa Timmy's post was made on March 12, 2010. Checking the Blender release index indicates that the current version at that time would have been Blender2.49b, so that seems like the one to try.

Having read Itsa Timmy's post again, I probably took the wrong approach last time. He converted RT3 .3dp to .off, then exported the .off from Blender as .3ds. I tried to use 3D Object Converter to convert RT3 .3dp straight to .3ds, so that might have been why it didn't work.

Tomix has been converting RT3 .3dp to .obj and importing that into Blender. Not sure if that makes any difference compared to using .off, but it could possibly explain why trying to export .obj as .3ds gave a result that didn't match the RT3 .3dp hex at all.

One of the threads in the defunct Rail Mogul board had this note:

ardee wrote:

Select mesh.
Switch to edit mode
Mesh-->Scripts-->Poly Reducer
Set the poly reduce factor (defaults 0.5) i.e half the polys than before. Remember that if you're working with quads that the game model will be in tris when calculating the final amount.

This would be well worth having. At the moment, as soon as you move any vertex it wont work properly in the less detailed instances, unless you go through those manually and figure out how to change those too. Nobody has been insane enough to do that. For instance, all of W&P's custom locos only have one instance (ie: the first and most detailed one).

This doesn't seem to be a problem in practice. Nobody ever complains about his custom engines borking their game. I've used plenty of them heaps of times without problems, so just adopted the same approach with my work. The game engine has so much other stuff to keep track of that loco mesh rendering is probably not as big an issue as might be first assumed. Still, if we can automate generating less detailed meshes that would have to be a bonus for performance.

ETA: I think I'll take a look at the Blender 3D Noob to Pro tutorials.

[Gumboots]

Took a look around and found this: 3DS MAX Scene Interchange. It allows importing .3ds files to the latest version of Blender, and exporting .3ds files from Blender.

Since it's an extension that may explain why some people have been unable to find a .3ds export facility in the latest versions of Blender. I haven't tried it yet (been busy hex coding) but will get around to it soon.

[Gumboots]

So I'm on a mission from God, like the Blues Brothers. I'm gonna learn me some Blender, dammit. I have managed to get an RT3 loco model to import into Blender, and I even figured out how to make it twirl around in circles. That's about as far as I've got at the moment.

I did notice something about the coordinate axes. Blender's directions are completely different to the one's used by RT3. If you take a .3dp and export it from 3dConverter as .obj then import that into Blender, the loco will be standing on its nose. Blender thinks the RT3 y axis is the z axis, and vice versa. Not only that, but it switches the directions for them too. Funnily enough, it is fine on the x axis. It's only y and z that are all messed up.

I know I can hex code models from scratch, but if there is some way of exporting something from Blender to RT3, even if it's only components rather than entire locos, that could save an awful lot of horrible hexing.

ETA: Ok, found out some more. The first thing is that Itsa_Timmy's plan of exporting the RT3 .3dp as an .off mesh and then importing that into Blender does not seem to be possible any more. For a start, in default form Blender will not import .off files at all. It doesn't even recognise that they exist.

There is an import script for .off to Blender (available as an add-on) but when I exported a loco from 3dConverter as .off, then tried to import that into Blender, the result is always that Blender stops responding and has to be shut down via the Windoze task manager. Needless to say, this is not exactly useful behaviour on Blender's part. So, the .3dp to .off to Blender idea appears to be a no-go, at least with the latest Blender and with the only "import .off" add-on I have found so far.

Blender will import .obj files, and I've imported one of Tomix's for a 242A1 loco body. That's fine in Blender, apart from the mixed up coordinate axes, but when I tried exporting that from Blender as .3ds, in the hope that this might work like the mythical .off to .3ds export mentioned earlier in this thread, the result was hex code that bore absolutely no resemblance to the hex of the original RT3 .3dp file. The same series of four bytes, from the original .3dp, was nowhere to be found anywhere in the .3ds file exported from Blender.

Short version: if this method worked once, it sure doesn't appear to work now. There's no way of getting a loco body into Blender as .off, and if you use .obj that will result in a .3ds export from Blender which is useless for RT3 modelling.

[RulerofRails]

Even though I have very little idea what I am doing, sometimes it's fun to play anyway. I decided to see if the latest version of Blender will load the off files with the developmental add-on. I managed to convert the body for your Berkshire into the off format in object convertor and then load it in Blender ok, but it was standing on its end and two points were obviously wrong. Don't know if this helps at all. I went quickly to hex to see if the 3dp and 3ds looked similar at all, but no joy there. Maybe because it didn't load correctly it's not that useful?

[Gumboots]

What "developmental add-on"?

[RulerofRails]

Sorry, developmental wasn't a good word to use. I read that it was a "Work in progress", that's all I meant to convey. It's on some of their main pages and you no doubt have it already. Anyway it's here: http://wiki.blender.org/index.php/Exten ... %28.off%29.

[Gumboots]

Yes, that's the one I tried already. I couldn't get Blender to import .off with that add-on. All that happened is that Blender would lock up and stop responding, then have to be shut down.

[RulerofRails]

3ds vs 3dp Blender 2.49b.jpg (179.75 KiB) Viewed 5912 times

I tried an old version of Blender (2.49b) and it seems that there at least some similarities between the .3ds it outputted and the original file as highlighted. I am fumbling in the dark with this stuff, and was just loading and then immediately saving the models in Blender but at least they are right way up and look okay. I might try an even older version of Blender to see what happens as Itsa Timmy may not have had the latest version. Anyway, importing .off files is much easier in the old version as no add-on is required. It might work for you.

[Gumboots]

When viewing .3dp files set your hex editor to 12 columns, not 16, and set the offsets (ie: row and column numbers) to decimal instead of hex. This makes it a lot easier to compare files. Having twelve columns means your x, y and z axis co-ordinates will always be in their own columns. If you use 16 columns (like you have in your screenshot) the x, y and z co-ordinates are constantly changing columns rather than stacking neatly down the page, which is far more confusing.

Anyway, the start of the actual body co-ordinates in the .3dp file is the sequence B2 2E A4 40. This is the x axis co-ordinate for the lower left point on the rear face of the firebox, and when converted to normal numbers means the point is 5.13070011 RT3 units to the left of the centreline of the loco, with each RT3 unit equating to roughly 10 inches (IOW, the rear of the firebox is around 8 feet wide at full scale).

The first sequence that you have highlighted in yellow in the .3dp file is mixing up co-ordinates. 67 B5 33 41 (+11.23 RT3 units above the track) is the z axis co-ordinate for the second point on the rear of the firebox. D2 00 79 40 (3.89067507 to the left of the CL) is the x axis co-ordinate for the third point.

The corresponding bytes in the .3ds* on the left are 72 99 68 41 (+14.53 RT3 units above the track) and D2 00 79 C0 (3.89067507 to the right of the CL). So, this means the height of the second point is way out, by around 3 feet at full scale, and the third point is flipped left to right.

BTW, the coordinates for the body points (or for truck points or bogie points or whatever) are always taken four bytes at a time: B2 2E A4 40 (x axis) then 75 63 B9 41 (y axis) then CF B7 D3 40 (z axis) for the first point. Then 5B D3 95 40 (x axis) and F0 86 B3 41 (y axis) and 67 B5 33 41 (z axis) for the second point. Etc, etc.

*The bytes in the .3ds example are staggered one column to the left, but shunted an extra row down, relative to the same bytes in the .3dp file.

I'll grab 2.49b and play with it.