OpenIG Lights

[Milo]

Hi all,

I know that I am venturing in a sloppery slope but I was working on the lights for the the 738 and wondered if there was an alternative to the actual light rendreing on FGFS.
I googled a bit and fell over OpenIG.
I am not a coder at all and it would take too long for me, like trying to implant the light effects on FGFS.
Here is a youtube of how it looks like.

I know that there are people around who could enjoy trying...

[Richard]

This is the link : http://openig.compro.net/

I've worked with Compro on a simulator update and these guys know what they're doing. I think I've seen a commercial version of this IG running.

I'm finding it hard to believe that they've released this as OpenSource.

I'm gradually drifting towards the opinion that maybe it's time to look at changing the scenery tools to generate standard format models.

[Michat]

When FG moved to OSG I did expect to have these advantages at once, but the time shows that still we haven't it. I think coming from A to B is not so easy as I thought.

Having those lights effects in FG should be fantastic.

Any idea about FPS impact using this techno-log-IA?

[Thorsten]

Without any details, it looks like it's doing what Rembrandt in FG is doing.

In general, there's no easy way to do these things (light, shadow,...) - specifically, you can't just 'add' an external package to FG and get lights that way, you have to rip out the whole rendering pipeline and replace it - which means you lose whatever effects we have.

A rendering framework doesn't work like reality in that you can just add an element - it's an elaborate illusion generated by several dozen of effects all working together to maintain the illusion, and if you change one of them, the illusion breaks. And performance is always an issue.

(Apart from a technical perspective that it's interesting to see that many lights defined and rendered, I'm not impressed by the actual lighting in the video, I think it's much overdone).

[curt]

I think it might be more appropriate to say that the lighting is impressive, but there are some things that could be tweaked and improved to be more like real life.

[Thorsten]

I am impressed on a technical level - though not on an aesthetic one

I think there's a lesson there as well (feel free to follow me on that one or not) - which is that careful balancing and composition works often better than technically impressive design.

[Michat]

Agree with last two opinions by Curt and Thorsten. Balancing, tweak, composition to match real life. And if you see guys what other sims are doing, I'll said even cheating the user's scene with some strange trick-effect, not matching the real life but users experience.

I'm thinking now in Pre3D that represents the night terrain textures illuminated by some light, which is very unreal. Same Mfs and Pre3d that both illuminates de aircraft by night, so if you are in outer view you'll see the aircraft beauty. They call it realism (like a painting style), but not in the sense of physics, convincing the user, but confusing me.

In some cases FGFS could tweek some things to get better visual experience to the user. Maybe not with visible at night terrain textures but with the scene illumination of the aircraft by night. Well there are a lot of visual tricks in other simulators which they sell like realism but there aren't.

FGSomebody should consider some other visual techniques. Soon, later, or never, it will resides in your organization, the human components.

Congrats to Milo for his demo.

[MIG29pilot]

What sim was that?

[Hooray]

Somebody should consider some other visual techniques. Soon, later, or never, it will resides in your organization, the human components.

A number of core developers have been wanting to unify the FGRenderer infrastructure so that different rendering schemes (think fixed-function vs. Rembrandt vs. ALS) can be prototyped/implemented and maintained: http://wiki.flightgear.org/Supporting_m ... _renderers

A few years ago, even prior to Rembrandt, Zan was experimenting with the whole CameraGroup code to make it entirely XML-configurable:

Subject: Improved camera configuration options

I've been working on improving the camera configuration system in FG. It is almost done, but needs some cleanup before I can put up a merge request. Here is the list of new features:

• Support for setting the rendering order of cameras
• Can set the clear mask (color, depth and stencil buffer separately)
• Can set the texture format in render-to-texture (which already was there, but had almost no use before this update), rgb, rgba, depth or depth-stencil at the moment.
• Can set the texture type (normalized 2d or rectangle)
• Support for multiple render targets, via just specifying multiple texture targets. This needs modification to shaders though, but works.
• Can set whether camera uses scene data or a custom model (e.g. screen aligned quad)
• Can bind render target textures to texture units for rendering to screen. (In the future should allow using these in models by specifying the texture name...)

Maybe I forgot something, but those are the main points. And what this allows:

• Rendering a different view to texture, then binding that to a texture unit to be used in a model on another camera:
  
  (Rear view is rendered first, then cube has an effect/shader which draws that view on all sides of the cube. The view updates when moving, so could be used in aircraft models etc.)
• "Real" reflections on aircraft. Might work with some tuning?
• Distorted views etc. (which are used in simulators with multiple projectors) without the need to change source code and compile for editing.
• Post processing effects, here is an example of blue filtering the scene. Everything is rendered to texture, and then a filter is applied to that texture in post processing:
  
• Chaining of post processing effects.

Note though that the camera settings need to be done in preferences.xml, so an aircraft model cannot define any new views. Also, the camera positions are relative to the current view (i.e. cockpit, chase etc) and cannot be fixed on the aircraft itself. And rendering to texture while using that texture in the scene has undefined result.

I'm trying to expand this so that cameras could select which parts of scene they render. For example opaque objects to a texture, then do something with it, render to screen and then render transparent objects. And after that some post processing, like bloom, to whole scene maybe. Or deferred lighting allowing multiple lights...

Maybe someone finds this interesting. I'm not sure if this should be under "Effects and Shaders" though...

Back then, Mathias, Fred and Tim were contemplating to use Zan's code as the foundation for features like Rembrandt:

http://sourceforge.net/p/flightgear/mai ... /28946515/

I was not aware of your work. But given what you write here, this looks pretty
promising. Fred mentioned your name in an offline mail.

IMO the complexity of this kind of rendering method in terms of requirements
to the driver makes me frighten a bit when I think that we have currently no
fallback to the old style renderer. Even back to the fixed function pure oldest
style stuff which is still the fastest thing we have.
Keep in mind that plenty of people will likely trade speed/deterministic frame
rates for any eye candy. And beyond that all people that cannot see anything
with rembrandt but a black window will love to have something that at least
shows the old style stuff (may be just fixed function?).

So, wherever we end, I would highly apprechiate that we do not lock out low
end graphics boards by not having any fallback.

May you both should combine forces?

Something like this would allow schemes like Rembrandt to be entirely prototyped/configured and implemented using XML, properties and effects/shaders - without requiring any major C++ changes.

For the full discussion, see: http://sourceforge.net/p/flightgear/mai ... /28939805/

At some point, it is likely that this will be overlapping with ongoing Canvas developments, simply because Canvas encapsulates the whole concept of RTT/FBO by providing a SGPropertyChangeListener-based subsystem on top of OSG RTT/FBO functionality, so that it would make sense to adapt Zan's newcameras and Fred's Rembrandt code accordingly.

For a more technical explanation, see: viewtopic.php?f=37&t=24288&p=221229&hilit=#p221229

Or just search the forum for: "FBO + Rembrandt + Canvas + OSG: search.php?st=0&sk=t&sd=d&sr=posts&keywords=OSG+Rembrandt+FBO+Canvas

When searching the devel list archives, you will primarily want to look for postings from Mathias, Tim, Fred and James.

[I-NEMO]

Hi all,

Thanks to Milo for the news.
From a Modeller point of view, I like the possibility of getting more realistically looking lights.

I do agree with Thorsten and Curt, though: those effects look a bit 'overpumped' (the Rway lighting effects on the plane are way too strong and harsh) and the terrain night lighting is poor. But I suppose that those effects can be tweaked to better simulate reality (it seems they can be controlled by .xml?).

BUT ... if it would be possible to 'adopt' OpenIG, or to just 'emulate' some of those features, would be a nice perspective.
Looking at the site's gallery I see that the platform could offer some promising plug-ins to play with.
I also like the image where the plane flyes in the fog: again, it's not the real thing, but it looks credible and interesting.
Also: Thorsten is perfectly right; to achieve something like that could imply a drastic change into the core code.

Best regards,

I-NEMO

[Thorsten]

BUT ... if it would be possible to 'adopt' OpenIG, or to just 'emulate' some of those features, would be a nice perspective.

I'm fairly sure Rembrandt does this (and has done it for a couple of years) - according to FredB, rendering multiple lights was one of his main motivations. And I think he mentioned testing a couple of hundred once.

(There's just no way of getting so many lights outside a deferred renderer).

But say you put a light into the scene - you have to supply a minimum amount of information:

* what color
* how strong is it, i.e. how quickly does it fade with distance
* what maximal volume is illuminated (so that the deferred renderer can skip the computation anywhere else)
* where does the light point

Once you enter this in xml, you pretty much end up configuring Rembrandt lights.

So I'm not sure what the additional feature requested actually is.