Wishlist: Enhanchment: Dual-head rendering...

[afarlie]

Currently Open BVE has a single render pathway, Whilst for most applications this is for performance reasons highly desirable, for others it is a limitation.

Some use cases for having more than one render pathway have been identified.

Currently Open BVE renders either a cab view, or various tracked external views dependent on user choice, on a single display device.

1. In some applications such as the London Transport Museum 'cab' simulations, it would be advantageous to have more than one output screen, representing views from different cab windows.

2. Proffesional simulators , tend to have multiple screens, in addition to those in the simulator for "instructor" and third party viewing of the simulation.

3. A 'composited' texture in the cab-view which could be enabled to simulate an on-train CCTV system, (like that on modern metro stock).

I'm not sure if any of these use cases could be easily supported in the forked version you are developing.

[cwfitzgerald]

This is a response to both this and #1.

Thy are both very possible. The problem becomes how do we express the intent in the current file structure in a way that is sane. That will be a question that I will deal with later.

Remember this isn't a fork of OpenBVE. I'm rewriting it from the ground up.

[afarlie]

In my view uses cases 1, 2 above no changes would be needed to the current file structure as I see it. The provision of additional 'views' would be based on the current file structure.

Use case 3 is more complicated, as essentially an object ( typically CSV or .animated) would need a Composite Texture command. I'm not sure how Open GL handles this, but Direct3D used to have the concept of surfaces, which were rendered first, and then said surfaces were applied as textures.

(It is of course noted that to do this well would need reasonably powerful CPU/GPU which may be condiderd outsider the typical consumer use of the engine to date.)

[cwfitzgerald]

OpenGL has a very similar idea with render-to-texture. This is actually how modern rendering engines are implemented. I'll keep that feature in mind going forward. It shouldn't be to taxing on the hardware when combined with modern opengl rending techniques. --- Connor Fitzgerald Sent from my Phone. Please excuse my brevity.

…

On March 8, 2018 4:16:54 AM EST, afarlie ***@***.***> wrote: In my view uses cases 1, 2 above no changes would be needed to the current file structure as I see it. The provision of additional 'views' would be based on the current file structure. Use case 3 is more complicated, as essentially an object ( typically CSV or .animated) would need a Composite Texture command. I'm not sure how Open GL handles this, but Direct3D used to have the concept of surfaces, which were rendered first, and then said surfaces were applied as textures. (It is of course noted that to do this well would need reasonably powerful CPU/GPU which may be condiderd outsider the typical consumer use of the engine to date.) -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #2 (comment)