Open Rails Editiors and Tools

[cn bala]

I am wondering if your team will create Open Rails Editors and Tools program similar to Microsoft Train Simulator Editors and Tools program. That would be nice if we will have one.

John

[lindsayts]

OR made an annoucement a little while ago saying work has started on an editor and such that will put all others to shame. If you have a look back over the past month or two one should be able to find it.

I mean I do not hink I imagined it.

lindsay

[cn bala]

I did search through here and don't see the topic related to Open Rails Editors and Tools. Can you tell me where is the topic that you saw? Highlight the URL then I will see the topic here.

Thank you,

John

[longiron]

Here's the announcement on our web site: http://www.openrails.org/roadmap.html

We've written a first draft of the specification that's 27 pages long.

[kox]

-I've asked about TS2012 style asset blocks some time ago for Openrails. Someone said that there are forest objects already in MSTS that are doing the same. But as i read about those forest objects mostly hardcoded into the game, you can only change it's textures, and it will be always two quads with that texture. But in TS2012 asset block you can use any objects, higher poly 3d models too. Will be the forest objects extended like this in openrails route format?

-another thing that connects to the written above: in msts i see two quads for low poly tree objects, but in RW there is a viewer facing material option, so only one quad is enough which means lower polycount, and looks nicer.

- will be superelevated/canted whatever it called tracks possible in new editor and in the new route format? i think this is very important for realism, more important than the cab sway and suspension effect

- is there news about what will be the new 3d format? As i remember ace textures already have a replacement (DDS). I'd love to forget about these useless barely supported intermediate formats like ace, s in the future

[twpol]

-I've asked about TS2012 style asset blocks some time ago for Openrails. Someone said that there are forest objects already in MSTS that are doing the same. But as i read about those forest objects mostly hardcoded into the game, you can only change it's textures, and it will be always two quads with that texture. But in TS2012 asset block you can use any objects, higher poly 3d models too. Will be the forest objects extended like this in openrails route format?

You are correct about the MSTS forest implementation AFAIK (and certainly how OR works today). As for extending to placing real shapes, I sure hope we do it. I think it'd also be pretty easy to make OR accept a .s file instead of a .ace file in the existing MSTS forest elements as an intermediate hack.

-another thing that connects to the written above: in msts i see two quads for low poly tree objects, but in RW there is a viewer facing material option, so only one quad is enough which means lower polycount, and looks nicer.

MSTS forests are single-quad viewer-facing objects, but they're a bit weird when you move the camera. In fact, we specifically don't cast real shadows onto forest quads because they change as you move the camera. (They do cast their own shadows though.) The low-poly multi-quad objects, however, do get shadows cast on them (as they're static in 3D space). It's one of those trade-off situations I think.

- will be superelevated/canted whatever it called tracks possible in new editor and in the new route format? i think this is very important for realism, more important than the cab sway and suspension effect

Absolutely.

- is there news about what will be the new 3d format? As i remember ace textures already have a replacement (DDS). I'd love to forget about these useless barely supported intermediate formats like ace, s in the future

3D formats are a much trickier proposition unfortunately, but I'm pretty sure we have agreed in principal to support conversion from COLLADA in to whatever we do use. It's not a great format for actually packaging content up IMHO, but it is a good (and well-supported) format for exchanging data between different programs.

[muskokaandtahoe]

If OR does open up the "Forest" concept to other .s files one could always create a typical MSTS tree shape and use that to have a "forests" that's a bit different from what is on offer today.

For my own preferences, I can see some advantages to several methods... the camera facing method in use now would probably be just fine in the background and a 3d MSTS-style forest would probably look right when it was much closer to the normal viewing locations, and then perhaps a more complex 3d shape up close in the foreground. Different solutions for different situations.

[kox]

3D formats are a much trickier proposition unfortunately, but I'm pretty sure we have agreed in principal to support conversion from COLLADA in to whatever we do use. It's not a great format for actually packaging content up IMHO, but it is a good (and well-supported) format for exchanging data between different programs.

What do you mean in "packaging content up". You can store 3d models, textures, materials, object names, animations in it. Or not? What else needed for a train sim?
BTW i like collada it was also my first thought for the new format, because it's opensource, well supported, not needs plugin because the most of cad programs know it by default.

[twpol]

What do you mean in "packaging content up". You can store 3d models, textures, materials, object names, animations in it. Or not? What else needed for a train sim?
BTW i like collada it was also my first thought for the new format, because it's opensource, well supported, not needs plugin because the most of cad programs know it by default.

I mean for distribution of routes (inc. loading by OR); COLLADA is a good format for transfering data between programs (everybody understands it), but it is large and complex to parse in to internal data structures; DDS, for comparison, is basically exactly what DirectX stores in memory, so it just reads a single file in to memory as-is and is pretty much done - very fast and effecient. I don't think we want to go as far as DDS, but something more compact and/or simpler to load is certainly desirable.

[eric]

On the topic of forests.... I'd like to see some added parameters, and the ability to get higher density, even if it means overlapping shapes.

Specifically....

1) Grid placement within the forest object.... I want to model real crop fields that follow terrain. Can't do that with forest objects because the density issue and the random placement. If I could have a super high density **and** have a grid pattern that places the individual "trees" in an evenly spaced pattern, instead of totally random x/y coordinates, that would be the ultimate improvement to me...

2) Multiple shapes to use within a forest object... Let me list several different tree shapes to be invoked, so that it looks naturally random.

Combining both could allow some interesting outcomes, ie a full parking lot using grid plus a list of ten different vehicles, or even a subdivision by using grid plus a list of six or seven house shapes....

Problems might come in by using the extra params with the MSTS engine, but being backward compatible isn't exactly my main concern... And really not much different than non-bin and bin today with some equipment.