[ebnertra000]

I suppose you could make a non-power-of-two texture, reduce or enlarge it to the nearest two power, and use that while you're modeling. Once you're done, you could theoretically go back to the non-two texture, and it would still work, since the mapping coordinates should still be in the right spots on the texture

[thegrindre]

ErickC, on 21 October 2017 - 08:29 AM, said:

That it works is encouraging, though! It means that designers can basically use whatever map size they want for OR. This is good for efficiency's sake, as materials once crammed into a second map can now be placed in the margins of a slightly larger single map.

The real joke here is that GMax doesn't display maps correctly in viewports if they're not a power of two, so I've had to settle on an oversized map with two locomotives in it instead of the original plan of a single locomotive in an extended-size non-power-of-two map. Oh, well. Those of you who are less anal retentive about your mapping have a new trick in your bag, anyway!

Oh, forgot to mention that my tests were in MSTS not ORTS. All worked fine in MSTS. I forgot to test in OR.

http://www.elvastower.com/forums/public/style_emoticons/default/oldstry.gif

[ErickC]

ebnertra000, on 21 October 2017 - 09:32 AM, said:

I suppose you could make a non-power-of-two texture, reduce or enlarge it to the nearest two power, and use that while you're modeling. Once you're done, you could theoretically go back to the non-two texture, and it would still work, since the mapping coordinates should still be in the right spots on the texture

Sort of. My alignment standards are super anal (I expect things to be aligned within a tolerance on the order of a thousandth of a pixel to make stripes easier to align), so this would throw everything off just enough to get on my nerves (especially with wheels). Most people wouldn't have a problem, though, and your suggestion would work perfectly for them.

Most of this, it should be said, results from a philosophy I've taken on over the last few years that the entire model should be mapped to the same resolution, with the resolution expressed as a definite integer fraction of an inch. For this particular project, which I am optimizing for AI use, I have selected a UV plane size of 1024 inches square and a diffuse map of 2048 pixels square, yielding one half inch per pixel. The original plan was one quarter inch per pixel at 2560 pixels square, but I came to the conclusion that the parts start looking blocky at roughly the same point where the difference becomes visible, so one half inch was the more logical choice, with an added bonus of being able to put two whole locomotives' worth of textures in a single map. I place a very big emphasis on consistency of resolution these days.

[Lindsayts]

I apologise for not reading all this thread, but for what its worth, textures for the backgrounds in 2D cabviews DO NOT need to be a power of 2 square, I regularly use 2560 x 1600 backgrounds no problem, Bigger will work but such a level of detail is not required.

LIndsay

[Eldorado.Railroad]

ErickC, on 21 October 2017 - 11:58 AM, said:

Sort of. My alignment standards are super anal (I expect things to be aligned within a tolerance on the order of a thousandth of a pixel to make stripes easier to align), so this would throw everything off just enough to get on my nerves (especially with wheels). Most people wouldn't have a problem, though, and your suggestion would work perfectly for them.

Oh stop teasing us like this...upload a pic of your textured train model..so we know EXACTLY what you are talking about!!!! :sign_thanks:

Cheers,
Steve

[ErickC]

Okay, but I have no idea when I'll have anything done, so keep your expectations low. Truthfully, it's a proof-of-concept, and there really isn't much to show, it's just another early Geep:



In flight simulators, when I'm lost and have no idea what to do, I make DC-9s. In rail simulators, when I'm lost I have no idea what to do, I make GP7s and 9s. I've been recently presented with a huge conundrum: I won't graduate from school for another two and a half years, but the menial factory jobs in my area are driving me crazy. But I love making models for games. I thought that, perhaps, I could make some fairly inexpensive models and reduce the number of hours I have to work in a normal job. So I am presently re-learning how to do all of the things I used to do, and I have a new simulator with expanded capabilities, so I made a quick GP7. This one is different than the last few, though. Whereas there was an upward trend in level of detail on the other models, this is a test of how good I can make a locomotive look from moderate distances using as few resources as possible. This is for two reasons:

1.) My level-of-detail standards have gotten very high for "hero" objects, but there are a lot of subjects that I want to cover, and that would take a lot of time (which is at a premium at the moment, with school). I can make a simple locomotive like this fairly quickly, but the high-resolution projects take months to develop - especially with the 3D cabs, because I won't compromise on visual quality here. I am at least tinkering with the idea of some of the newer models ending up in Railworks since I have found the capability to move GMax projects to 3DCrafter (simple FS9 x-file export with middleman).

2.) With the high level of detail in hero objects comes a performance penalty. Since I predict that relatively few US-based activities will involve train-switching, I think there should be some locomotives meant for AI that look good at moderate distances. Then the user can watch the trains go by, enjoy a bit of a performance boost, and still have a user locomotive that looks good up close (think 3D dynamic brake assemblies and fan grates).

I built this model because the new CP SD40-2 I am working on as a first "high-resolution" release was driving me crazy (I am in the last stages of the 3D cab). I wanted a break, but I wanted to keep towards the goal of having something to release. So the goal here has been to create models roughly approximating late MSTS level-of-detail, but using ORs expanded ability to handle materials to dramatically reduce the umber of drawcalls, because I no longer use MSTS, and therefore can't justify building for it. Since I no longer need to worry about bit depth with alpha channels, there is no reason for me to have a separate texture for the windows. The goal then becomes putting everything on one texture sheet. I noticed that a resolution of .5 inch per pixel yielded textures that start looking blocky at about the same distance as the model details start looking blocky, so it became apparent that this was the optimum texture resolution, and I was able to fit the entire locomotive in a 2048 x 1024 pixel space, meaning I can throw a quick UVW XForm on a second locomotive and put two locomotives in a single texture sheet:



I'm unsure if this will end up as anything other than a test, though, I'm not sure how many people are interested in the concept. If there is a degree of interest large enough to justify making more, I have a laundry list of weird and wonderful early Geeps and Geep-derived rebuilds that I want to do between the mind-numbing higher-resolution projects (think of CNW low-nose rebuilds, AS-16m, the Beep, maybe the fright-inducing WM rebuilds for next Halloween, GP28Ms, things like that).

I should say that it's technically not "just" another early Geep. For the first time, I had access to a real GP7 (MNTX 559), so I measured as many detail parts as was feasible. It's an order of magnitude more accurate than any of the older models. It may be the first MSTS or OR model with the correct Blomberg truck profile (they're not flat).

[Eldorado.Railroad]

ErickC, on 31 October 2017 - 12:13 PM, said:

Okay, but I have no idea when I'll have anything done, so keep your expectations low. Truthfully, it's a proof-of-concept, and there really isn't much to show, it's just another early Geep:

Since this is a first try at this, well if I may be so bold, I would not worry about power of two textures. If anything, given what you have done so far, I would just stick with 2048x2048 textures. Yes you will learn some neat tricks as you go along, but I can say that some payware vendors even restrict themselves to smaller textures, but more of them and all are a power of two. Whether this is optimal for OR is another matter. Personally I think getting the thing "out the door" is more important than optimal fixes from the onset. Yes some modellers, do waste a lot of space in their textures, but I do not see that in yours, so I would relax and texture, even if the size creeps up.

[OneFlyer]

Man, this Geep is looking pretty good (saying that because I don't know a bit about modeling for ORTS). Having those large textures will bring a bit of a burden on weaker systems that can't handle ORTS/MSTS routes already created, but the solution to that is to upgrade the system or look for a poorer substitute. I know my system can handle this wonderful model. When I said I didn't know a bit about modeling, I lied a little because I did try to create a 2-10-4 Texas-type steam engine in TSM and it worked in ORTS(had to rip data from a similar loco). I worked on it for about a week but then quit cause I didn't know how to make my own textures(ripped textures from another loco for my testing) and then school started so that kinda ruined my ORTS/MSTS time also. What I'm trying to say is you really are committed to this project, I support you on this(along with any one else on this thread). Good luck on the texturing and testing. :good:

[ErickC]

Eldorado.Railroad, on 31 October 2017 - 03:39 PM, said:

Since this is a first try at this, well if I may be so bold, I would not worry about power of two textures. If anything, given what you have done so far, I would just stick with 2048x2048 textures. Yes you will learn some neat tricks as you go along, but I can say that some payware vendors even restrict themselves to smaller textures, but more of them and all are a power of two. Whether this is optimal for OR is another matter. Personally I think getting the thing "out the door" is more important than optimal fixes from the onset. Yes some modellers, do waste a lot of space in their textures, but I do not see that in yours, so I would relax and texture, even if the size creeps up.

Well, the 2560 x 2560 idea came from originally wanting to have a 1/4 inch per pixel resolution, but it quickly became apparent that this was more resolution than was actually necessary for this model. The texture resolution, as it stands, is roughly similar to my older models (I actually slapped the long hood texture from a Matt Doti repaint of my GP20 on it briefly to get an idea of what it might look like with some actual textures on it), as is the overall level of detail, but the triangle counts are much, much lower due to heavy optimization. Whereas the re-release of FRV 4505 was about 19,000, and BN 2290 was 17,500, this model is only about 12,000. The hi-res re-release of CP 5577, on the other hand, is sitting at about 40,000 at the moment...

[Jovet]

Lindsayts, on 29 October 2017 - 11:37 AM, said:

I apologise for not reading all this thread, but for what its worth, textures for the backgrounds in 2D cabviews DO NOT need to be a power of 2 square, I regularly use 2560 x 1600 backgrounds no problem, Bigger will work but such a level of detail is not required.

2D Cab views are not textured models. A 2D Cab view .ace is just treated as a bitmap file, which has never had any limitations short of what the display itself can show.