[cjakeman]

Our next session is in a week's time, on Sat 4th Nov.

Is there any topic that you would like ORMT to discuss?

[rickloader]

I would like to thank James for explaining about lights . Could not static lights ( yard, platform street) be given a volume sphere? Say 20 meters where they light up pixels in range. That way fewer pixels would have to be computed.
In minecraft you have to place torches to prevent hostile Mobs spawning in low light levels. A minecraft scene may have a hundred torches with out loss of performance. (static light sources) I bet these static lights are limited or fudged in some way, but the effect is still gorgeous.
I realise that getting a dev to implement things is a problem, but are there not ready made chunks of monogame code ?
https://deepworldgam...t-point-lights/
I`m not a coder so sorry if the above is not relevant.
Anyway, perhaps ORMT can find a moment to discuss static lights. Or even a move to direct x 10? Thanks, Rick

[James Ross]

rickloader, on 29 October 2023 - 01:47 AM, said:

I would like to thank James for explaining about lights . Could not static lights ( yard, platform street) be given a volume sphere? Say 20 meters where they light up pixels in range. That way fewer pixels would have to be computed.

It doesn't matter what shape the lights are, with immediate rendering, we need to calculate the light effect for every pixel (multiplied by number of lights). Every pixel on screen (in the 3D world) is calculating the light cone effect currently.

rickloader, on 29 October 2023 - 01:47 AM, said:

I realise that getting a dev to implement things is a problem, but are there not ready made chunks of monogame code ?
https://deepworldgam...t-point-lights/

The code here appears to have been removed, but it is nevertheless going to be applying all 20 lights to every pixel. I don't remember what the maximum number of lights we could do with DirectX feature level 9_3, but more will definitely be worse for performance.

The main way out, which I believe most game engines use (or at least support) these days, is deferred rendering.

rickloader, on 29 October 2023 - 01:47 AM, said:

In minecraft you have to place torches to prevent hostile Mobs spawning in low light levels. A minecraft scene may have a hundred torches with out loss of performance. (static light sources) I bet these static lights are limited or fudged in some way, but the effect is still gorgeous.

Minecraft has an almost unique optimisation it can do: almost everything can be calculated at vertices, not pixels, which massively speeds up things.

[rickloader]

Thank you James for your explanation. I am sorry my example was flawed, but there are a lot tutorials showing Momogame lights and water on the web. it doesn`t seem necessary to invent the code from scratch, but of course it still needs a coder to integrate with OR.
I must now reads about deferred rendering. thanks, Rick

[James Ross]

rickloader, on 31 October 2023 - 02:31 PM, said:

Thank you James for your explanation. I am sorry my example was flawed, but there are a lot tutorials showing Momogame lights and water on the web. it doesn`t seem necessary to invent the code from scratch, but of course it still needs a coder to integrate with OR.

The code to do multiple lights (up to an arbitrary fixed limit) is pretty simple, but it needs someone to take the time to implement it and test the performance effect (and see if it'll even work with our supported shader levels). Without that, we don't even really know if deferred rendering is needed (or a bump on minimum specs). :(

[Eldorado.Railroad]

James Ross, on 31 October 2023 - 01:50 PM, said:

The main way out, which I believe most game engines use (or at least support) these days, is deferred rendering.

While you are here, may as well "spill the beans" on anti-aliasing as well (warning this will almost surely cause some "brain pain" to read):
Multisample anti-aliasing in deferred rendering

If you want to see what a high performance, but limited AA looks like, I give you Run8. Running OR without quality AA, but with lights galore might be not what you are asking for. Many FPS games cheat by having a lot of black on the screen to "improve" visual performance with less AA. The last time I looked at Dovetail's offerings FXAA did very little for me. The simple but expensive SSAA works very well in forward rendering. Per say SSAA, is not really possible in deferred rendering without a fabulous GPU setup (dual Nvidia 4090s anyone?!) and even then you might be relegated to 1920x1080 as opposed to 4K to get decent frame rates. If this is so "simple" to do, somebody would have tried it out already. Alas the years role by.

There is also the "messy" issue how deferred rendering handles transparencies, this might turn the handling of common OR shaders upside down.

Steve

[gpz]

James Ross, on 28 October 2023 - 07:02 AM, said:

At the end of the day, it's mostly down to nobody trying to implement it, as with most other desired-but-missing features. :)

James Ross, on 31 October 2023 - 04:44 PM, said:

The code to do multiple lights (up to an arbitrary fixed limit) is pretty simple, but it needs someone to take the time to implement it and test the performance effect (and see if it'll even work with our supported shader levels). Without that, we don't even really know if deferred rendering is needed (or a bump on minimum specs). :(

Let me take the chance to note here that the support for multiple lights is part of the glTF PR, which is part of the unstable release for more than a year. (Maybe more than two? I'm not in a mood to check back...) Currently the only supported way of adding more lights to the scene is to create a glTF object with attached lights, which then can be used either as a vehicle or a scenery object. Multiple of such glTF-s can be displayed at the same time, and one object may contain multiple lights. Currently there is a constant max. limit number of 20 is set in the code, but this is just because I don't know the performance implications.

[James Ross]

Eldorado.Railroad, on 31 October 2023 - 06:57 PM, said:

If this is so "simple" to do, somebody would have tried it out already. Alas the years role by.

There is also the "messy" issue how deferred rendering handles transparencies, this might turn the handling of common OR shaders upside down.

I hope you didn't think I meant deferred rendering is "simple", because it certainly isn't, and I know about the anti-aliasing and transparency downsides.

What is "simple" is changing our existing shader from doing 1 light to doing a higher (but still limited) number of lights, like Peter has done in the glTF patch (along with a lot of other work, of course).

gpz, on 01 November 2023 - 06:01 AM, said:

Currently there is a constant max. limit number of 20 is set in the code, but this is just because I don't know the performance implications.

There is also the implications of increasing the minimum spec from DirectX feature level 9_1 to 10_0.

[Jonatan]

What I'm suprised is that no one's done this "simple" change to the shader just on an experimental basis on their own system to see if it works, and study what happens.

Nevermind the professed outcomes, someone has to even try. Until that happens, we can speculate all we want.

[eric from trainsim]

For the steering committee... can we perhaps get some roadmap "swimlane" updates?

• Physics Improvements
  
• Lightning Improvements
  
• File Structure Evolution
  
• World and Activity Editors
  
• Documentation
  
• Installers and Tutorials to simplify new user experience

If there's another way organizationally that these topics fall into swimlanes, great. We have various "camps" of interest, and it seems that some camps are more favoured than others.

I also want to continue to beat the drum on resurrecting TSRE -- please find a volunteer within the developers who might be able to figure out the QT components and see if there's a way to port that into C#.

Get as many eyes on that source code as we can, and perhaps someone will see a path forward. But people have to look at it. It's not fixing itself, and Goku continues to be absent.

Without new routes, we're screwed.

[Jonatan]

I agree TSRE is a major pillar in the sim that needs attention., so I'll echo eolesens sentiments.

[Genma Saotome]

eolesen, on 01 November 2023 - 12:12 PM, said:

For the steering committee... can we perhaps get some roadmap "swimlane" updates?

• Physics Improvements
  
• Lightning Improvements
  
• File Structure Evolution
  
• World and Activity Editors
  
• Documentation
  
• Installers and Tutorials to simplify new user experience

If there's another way organizationally that these topics fall into swimlanes, great. We have various "camps" of interest, and it seems that some camps are more favored than others.

IMO migrating from one file type to another isn't going to do much for creators and users, certainly not absent a robust conversion program. OTOH re-thinking what could/should be in files should open the doors to many new features. As an example, in North America a train is defined as one or more locomotives coupled to one or more cars. The current .con files does that for us. But in North America a train is often understood as a collection of locomotives coupled to one or more collections of cars, where each collection of cars are destined for very different points. That's not what the .con can handle. A file structure that can handle the later can also handle the former... but the former cannot handle the later. If files are to change the information they carry, please, please keep an open mind.

eolesen, on 01 November 2023 - 12:12 PM, said:

I also want to continue to beat the drum on resurrecting TSRE -- please find a volunteer within the developers who might be able to figure out the QT components and see if there's a way to port that into C#.

Get as many eyes on that source code as we can, and perhaps someone will see a path forward. But people have to look at it. It's not fixing itself, and Goku continues to be absent.

Very good points. Many of the functions that do things are good. Would that not be the hardest part to code from scratch? Translate them C#. HOW you get to those functions via the UI needs a major re-work.

eolesen, on 01 November 2023 - 12:12 PM, said:

Without new routes, we're screwed.

I've been making that point since day 1. Nobody was interested.

[dajones]

I would think that the main reason for creating an editor in C# would be so that you can reuse the OR infrastructure. But if you port TSRE code to C# you won't end up with anything shared. I have lots of experience with C++, but none with QT. I have no problem reading the TSRE code and I think it is worth using it as a reference. But I'm not sure if it make sense to try porting any of it.

I recently thought about building route editing features using the OR infrastructure. I was originally thinking of copying the RunActivity code, removing all of the simulation code and then adding editing features. But the simulation and rendering code are heavily intertwined, so removing the simulation looks like a lot of work. It would probably be easier to add route editing features to RunActivity and arrange it so that they only work when the simulation is paused using escape. This might not be the best solution in the long run, but it would be a way to get started.

So far I haven't decided to do any of this, mostly because I don't have a Windows machine. I have a DesktopGL version of RunActivity that I created a few years ago and I could modify that. But the DesktopGL version has performance issues and I had remove all window specific features from it. For example that version can't read any of the options settings from the registry. So, I'm not sure I would end up with something others would use.

Doug

[cjakeman]

eolesen, on 01 November 2023 - 12:12 PM, said:

For the steering committee... can we perhaps get some roadmap "swimlane" updates?

• Physics Improvements
• Lightning Improvements

I'm assuming that should be "Lighting" :-)

[BillC]

dajones, on 02 November 2023 - 07:00 AM, said:

I would think that the main reason for creating an editor in C# would be so that you can reuse the OR infrastructure. But if you port TSRE code to C# you won't end up with anything shared. I have lots of experience with C++, but none with QT. I have no problem reading the TSRE code and I think it is worth using it as a reference. But I'm not sure if it make sense to try porting any of it.

Doug, I Agree with your assessment. I also have experience using C/C++ background. Decades ago, more at a bit banging level level developing device drivers. Specializing with disk drives, communications device drivers, and modems. For embedded systems, Unix systems, MS PC systems.


Having also read some comments about more developers eyes on the code, from non-programmers. Some with out a programming background don’t understand. That it is not just not translating C++ code to C# but other factors as well. If I recall in the past members of the ORMT had a discussion with Goku, and more than likely have looked at the code.

dajones, on 02 November 2023 - 07:00 AM, said:

I recently thought about building route editing features using the OR infrastructure. I was originally thinking of copying the RunActivity code, removing all of the simulation code and then adding editing features. But the simulation and rendering code are heavily intertwined, so removing the simulation looks like a lot of work. It would probably be easier to add route editing features to RunActivity and arrange it so that they only work when the simulation is paused using escape. This might not be the best solution in the long run, but it would be a way to get started.

I took a different approach near the end of Covid. Cloning the code from from GitHub, hacking out RunActivity and other commingled code was able to have a running dynamic version running on Windows 10 using QT. However was not able to have sound working.

Troubleshooting the problem was not a simple code fix. But appears to be a design problem. Down loading Goku’s latest code, running on two different Windows 10 64 bit systems, and a Windows 7 systems has the same problem.

Without getting into the details problems having to do with using OpenAL, transitioning QT dynamic code to Windows *.exe executable code. In addition Goku may been on shadow ground here QT states that with out a commercial license open source code executable code should be distributed as linkablel libraries as opposed to static builds. He was doing this even before doing commercial work from a reference by OR.

dajones, on 02 November 2023 - 07:00 AM, said:

So far I haven't decided to do any of this, mostly because I don't have a Windows machine. I have a DesktopGL version of RunActivity that I created a few years ago and I could modify that. But the DesktopGL version has performance issues and I had remove all window specific features from it. For example that version can't read any of the options settings from the registry. So, I'm not sure I would end up with something others would use.

Doug

IMHO a possible path for OR to follow would be to follow MSTS method of having separate RE, AE, and RGE linked into OR code.

With that being said around April of this year when reading threads that TSRE support was abended. Decided to look at OR Track Viewer, which uses WPF as a GUI. Which had started out as a separate program linked to OR, before being integrated into it. Was able to set up a module hooked into the OR code and able to load directories and files in. However continuing on was not possible for me. Not have enough of a graphics background, complete enough knowledge of MSTS file structure, and no documented API. Would be too over overwhelming a task.