Old abandoned openBVE 2 demo?

[JakubVanek]

Have you seen this? It looks really interesting. http://railsimroutes.net/blog/?p=891 http://web.archive.org/web/20101129142153/http://openbve.trainsimcentral.co.uk/openbve2.html (https://github.com/sladen/openbve2 ?) Jakub Vaněk

[JakubVanek]

"The potential future of openBVE", now like The future, the present and the past of openBVE" http://web.archive.org/web/20101031114746/http://openbve.trainsimcentral.co.uk/articles/thepotentialfuture.html

[leezer3]

Yeah, I know about this. The issue is in many ways rooted in the current routefile format.

In essence, a .RW or .CSV route file works in a strictly linear sense. A short 'example'- We place one object at 100m At 125m, we start a curve of 100m radius At 200m, we finish the curve Finally, at 225m, we place a final object

In basically any other sim, these four commands would be independant entities. To understand this, take our curve: Most other simulations would store two 3D world co-ordinates. The curve would then be worked out mathematically between these two points.

OpenBVE on the other hand uses a strictly linear model, in that our curve is placed relative to what has come before it. If we now add a curve between 25m and 50m, the position of our previously placed curve changes. Similarly, if we remove the curve, the world-position of our object at 225m will change, as it is placed relative to the world-position of Rail 0 at 225m

What the renderer demo does (Please bear in mind that I've not done a massive amount of digging on this) is essentially to re-write the world system into a more conventional system. This is fine, but has the major problem that this only handles the placement of objects- In essence, it's only placing static 3D models within the worldspace. In order to make this work, what it would require is the addition of a parser to setup the track position itself. This is far more difficult than it looks :)

[mgavioli]

"This is far more difficult than it looks :)": given your experience with openBVE, I'll trust you blindly! But, at first sight, it shouldn't be so hard.

As far as I know, openBVE only supports straight and circular portions of track (no fancy functions, not even Bézier splines); both have rather simple (and reversible) mathematical treatment.

Care should be probably taken with rounding errors but, as openBVE only support integral meter track positions (correct me if I'm wrong), there should be ample room for tolerance.

Am I missing something?

Another point could be: re-writing the internal working might be fine and might even increase the performance (not obvious, but possible). A non-linear (or a multi-linear) track arrangement would not be available to route developers, though, unless the file format is extended and this would bring a number of cross-version compatibility (and of BVE-openBVE compatibility, if this is still a goal).

[leezer3]

The bigggest thing you're missing is that the current format allows you to effectively 'cross' over to or near your previous position with no consequences, as it's already been disposed of. Convert some routes into a 3D worldspace format, and you'll discover that you get overlapping objects when the route direction changes.

Track positions can be non-integral if you want- I'm not sure how far they go down in precision off the top of my head, but I would expect any floating-point number to work.

For that matter, if you use Options.Blocklength it's possible to override the default 25m block length, but in order to do this, you'd have to re-write all of your Rail, Wall, Dike etc. objects to be of your desired block length.

This image shows what I mean (IIRC the developer in question altered the block length to 5m for when he took this screenshot, but didn't change the track object lengths)

[mgavioli]

Eventually I had the occasion to read Michelle's notes quoted a the beginning carefully enough! (I probably did not focus correctly the topic)

At this point, it seems to me it greatly depends on the goal one has in mind.

If I am not mistaken, the simulator already converts track-relative object positions (read from the route file) into world 3D positions; these positions can be kept even if the main track does change (reversing the direction, changing to another independent track or even if the topology does change because of switching). None of this should necessarily affect rendering in the simulator.

Of course, this would affect an editor, as track-relative positions should be re-computed for saving, if the file structure remains the current one: there might be several possibilities for choosing the track piece to which re-attach each object (but probably any would be fine; worse is if there happens to be none!).

It seems to me signals (and similar) would be a bigger concern as, currently, signal systems only work 'forward' and assume a unique path after them.

[danielleighton]

@leezer3 I'm a bit of an interloper in this conversation, but I have a question on this in relation to some experimental work I was doing in Unity3d using object and route parsing code from OpenBVE

The bigggest thing you're missing is that the current format allows you to effectively 'cross' over to or near your previous position with no consequences, as it's already been disposed of. Convert some routes into a 3D worldspace format, and you'll discover that you get overlapping objects when the route direction changes.

Can you link examples of routes that have this phenomenon at all?

One thing that confuses me here is how it relates to the existing "free camera" type functionality in the Route Viewer or indeed OpenBVE itself. Are you saying that basically the scene is rendered on a "track section by track section" basis, only giving the illusion of a consistent world as such?

I've attached a gif that maybe answers my question above - the route (via RouteViewer) does seem to get rendered only partially, and in chunks - but still, I'd like to further understand an example of what you talk about above, if at all possible - thanks

[leezer3]

You're correct. Not sure I've got an available example off the top of my head, but just alter the curve radius to something silly on an existing route.