[SP 0-6-0]

Evening, I have been very interested in integrating parts of openBVE into ORTS for some time now. OpenBVE seems to have gotten certain aspects like animated water and scenery items right. The coding is ingenious and yet simple enough to replicate into ORTS.

Thanks Lindsay for pointing all this out to me.

First and formost, I would love to see more of a Railworks style water animation in OpenRails. And I think a way forward on this has been discovered right here by the OpenBVE developers. Animated Water

The moving water in the above X-City South v1.4 video also needs some work, but involves a static canal object with ordinary texture, and then two animated, texture shifted alpha-enabled surfaces overlaid; one moving left to right (to match the cloud’s direction of movement), and the other moving along the Z-axis. When combined, they make the water appear to ripple slightly if you look closely for a few seconds, particularly where the tree reflections are visible on the right in the video.

How animated birds and swaying power cables have been realized. OpenBVE Birds

Animated, Segmented Objects Animated, Segmented Objects

While I understand ORTS does not yet have a full comprehensive dynamic weather system for explorer or activity modes. I do hope in the future lightning like this of OpenBVE can be archived? I am naturally interested in lightning so this effect would be awesome. Lightning Affect

Lindsay and Dave have both proposed very interesting ideas and suggestions for how to handle multiple shapes in ORTS only to have their ideas rejected with the somewhat standard line, "We need a new shape format" quite frankly I don't think we really need another new file format just yet for ORTS. The standard MSTS .S has been getting the job done since the beginning of MSTS/ORTS. Sure, It is limited and technically the property of M$/Kuju. However, Recently there was two papers written about the .S file format. IMHO both should be read by anyone creating content for MSTS or ORTS. Both are right here in ET's file library. These two papers were "Shape File Format" by Jeffrey Kraus-Yao and "Shape file (.s) specification" by StationMaster. With these two papers at hand it should be feasible to expand the .S file format within ORTS while maintaining backwards compatibility with MSTS.

Dave Nelson recently posted in a discussion about articulated locomotives the following excert,

IMO assembly of multiple mesh files into one in-game object is an essential improvement for OR and, unfortunately, no matter which object you want to apply that too means a fair amount of change. Basically KUJU's files and software can't deal with it.

I've argued for some time that the letters s and d in .sd mean Shape Description. After a fashion both .eng and .wag are also shape descriptions. These extra files are needed because the CAD software doesn't provide for game-specific data... those have to go somewhere else.

Following that logic I've felt that the matter of assembling multiple meshes into one in-game object should address all objects -- static as well as rolling stock. This has led me to think the .sd file would be the best place for this. Conversing w/ Chris Jakeman on this some months ago he argued against that and for a new file type.

Either way, I mention this to point out that the matter is larger than just articulated locomotives and I suspect the solution is too.

Lindsay responded with the following excert,

The Animation file format in Open BVE does this, have you has a glance at it, I have found it logical and flexible and is a major step forward when building complex models.

I had a look last night at the OpenBVE setup and must admit that I agree with Lindsay on how ORTS should move forward with handling the combination of multiple shapes into one in game.

OpenBVE also makes use of some rather ingenious route developer tools that allow for bending of shapes and other neat methods not currently possible in MSTS or ORTS route building.

All of the OpenBVE methods are well documented and can be found in the following links.

OpenBVE Link 1

OpenBVE Link 2

OpenBVE Link 3

OpenBVE Link 4

OpenBVE Link 5

OpenBVE Tools

Dave, Lindsay, I think both of these ideas are well worth pursuing. I know there is an argument to be had for a new shape file format. And they may be right. But, I do like the way OpenBVE shapes can be combined. Also OpenBVE allows for animating of any shape regardless of whether or not it has animation properties. This in it's self is intriguing. Dave, I like the idea of combining shapes into one in the SD file. Even freight anim files could be added and subtracted in the SD file instead of the wag or engine files. This is a kinda brilliant really. ORTS freight anim could be expanded to have a specific file name just for non animated locomotive super detailing and leave freight anim for loads that are animated. These two really should be seperated. Either of these ideas gentleman would allow for the smoother operation of the those big Milw electrics and I am just as annoyed with the inability to enjoy this mighty beast without them having the trembles.

I strongly feel the ORTS developers are just being a little silly in not impelmenting similar features of OpenBVE in ORTS for whatever reason. I strongly feel going forward the only right path is to utilize the methods of OpenBVE in furthering ORTS capabilities.

Robert

[Lindsayts]

In case anyone is wondering OpneBVE allows the use of their source code in another opensource project as long as one clearly states it is NOT part of OpenBVE.

I brought it up as I believe it may be usefull, it does not both me at all if the idea goes no further. I am using it in my own train sim, it works well , why is it necesary to reinvent the wheel?

Lindsay

[SP 0-6-0]

A valid point Lindsay.

The old saying comes to mind. If ain't broke, Dont fix it. If the OpenBVE code can get the job done then why monkey about with something else?

Robert

[Lindsayts]

SP 0-6-0, on 08 July 2016 - 04:37 PM, said:

A valid point Lindsay.

The old saying comes to mind. If ain't broke, Dont fix it. If the OpenBVE code can get the job done then way monkey about with something else?

Robert

Again I am not trying to have a go at anyone just stating a position.

Finding use full file formats was the second thought that popped through my mind when a started work on my train sim, why reinvent the wheel, if there's a file format out there then use it..

The first thought was how is the terrain and world model to done so that its accurate. as i knew nothing about cartography this took a goodeal of research.

Lindsay

[SP 0-6-0]

Lindsay, What are you using for a physics engine? Does your sim have any kind of basic derailments?

I've been looking at these two physics engines wondering if basic MSTS like derailments refined could be done for OpenBVE.

ODE

OPAL

Physics Engines

OpenBVE does not yet have A.I. traffic, Which would require a major rewrite if I am not mistaken? Does your program have A.I. traffic?

Robert

[Lindsayts]

SP 0-6-0, on 08 July 2016 - 09:05 PM, said:

Lindsay, What are you using for a physics engine? Does your sim have any kind of basic derailments?

I've been looking at these two physics engines wondering if basic MSTS like derailments refined could be done for OpenBVE.

ODE

OPAL

Physics Engines

OpenBVE does not yet have A.I. traffic, Which would require a major rewrite if I am not mistaken? Does your program have A.I. traffic?

Robert

I am not using any external game engines I have study some of them and found them unsuited to my idea of a train sim. The terrain rendering and world model are also all my own doing. I found it was not particularly difficult tom find a terrain rendering engine, but a disliked the ones I tried as to slow. The mathematics often being quite complex. I have found a relatively simple way of generation CORRECTLY shaped terrain, the accuracy spec being 1 in 1000, that is a distance of 100 kilometres must be accurate to plus or minus 100 metres. The method of world model generation used has been taken from a flight sim, one can use 1 or 3 DEM tiles directly, this saves having to generate special wold tiles. Routes can be any length in any direction and will retain accuarcy.

n my case mathematics for the physics are writen in external text files that are read in on program startup, thus allowing changes without redoing any programming. I am though a keen user of look up tables to define values.

One other aspect as regard to rolling stock physics is I am not doing any internal simulation in the locomotives, what is simulated is the effect of the whole system, this is a train simulator not a physic simulator (Note 1), the method resembles an enhanced method of the way MSTS works.

The whole idea was to be able to correctly represent a whole (small) system, ie with all traffic running. I have as yet only got the basic rolling stock running and have been tackling a world editor

Note 1: There is nothing wrong with a phsyics simulator in fact I have writen one for a steam engine, It's just I believe its not necarary to do this in a train sim.

Its being writen in standard C using Mesa (openGL) for all the graphics, including the interface. I am doing it because after playing with MSTS I had a desire to see if one could write a better sim. I though consider MSTS graphics are good enough and are relatively easy to do. I at this stage do not intend to openly release it as for me the joy is in the journey to create it.

Not a few people think I am crazy for doing it, but I LOVE to find out new things and this has been a joy doing all the investigations and the research to get things running properly. I am quite happy with the accuracy of the rolling stock physics and its been something or a real insite why railways do some of the things they do.

Note: I have contributed to open source projects, including the linux kernel I am quite happy though for all my work to go unrecognised, I do it because I like to do it, there is little better in this world than to get something running one has built one self.

Open BVE only has a single path in its "routes" which is why there's no AI traffic. The way routes are done is that objects are relative to the track, And there is no real world model
Inspite of its limitations there;s a lot to like in the way OpenBVE goes about things. a lot of thought has gone into that program. I ma using its animation and also its cabview file format a couple of others are under investication for future use.

Lindsay

[sergio]

very interesting thread, i hope you can join parts of openbve in openrails.

[Goku]

SP 0-6-0, on 07 July 2016 - 05:55 PM, said:

The Animation file format in Open BVE does this, have you has a glance at it, I have found it logical and flexible and is a major step forward when building complex models.

Complex models? How you define shape hierarchy, or 'skeletal animation' in openBVE shape format?

Only 'advantage' of openBVE formats over KUJU formats is that you can easly edit it in text editor - but it is not advantage. For me it is way better to implement some popular game file formats where you have lots of dedicated tools. Content creators want to have simple tools to convert their 3ds max / maya etc projects, not another weird formats, you have to make text files and calculate animation matrices, shifts etc. by hand.

[Z31SPL]

Goku, on 09 July 2016 - 06:27 AM, said:

Complex models? How you define shape hierarchy, or 'skeletal animation' in openBVE shape format?

Only 'advantage' of openBVE formats over KUJU formats is that you can easly edit it in text editor - but it is not advantage. For me it is way better to implement some popular game file formats where you have lots of dedicated tools. Content creators want to have simple tools to convert their 3ds max / maya etc projects, not another weird formats, you have to make text files and calculate animation matrices, shifts etc. by hand.

Basically just get caught up to modern times in terms of game design

[copperpen]

Having looked at the BVE animation demo video, I am singularly unimpressed. The animations are not anywhere natural looking, and the water just does not look right either.