Talk:Project Rembrandt

Hi.

Like I mentioned in my email, I have made modifications to CameraGroup to allow much more camera options in preferences.xml. Currently supporting: multiple cameras & render orders, render to texture, multiple render targets, binding of render target textures for other cameras, floating point textures, post processing & chaining of effects.

So basically I think most your stuff could be handled with this system (though it still has some bugs and seems to cause crashes in libGL...)

Anyways, when you think you have the system running well enough, so that it would be time for cleanup, please give me a message and let's see if this work can be combined. Meanwhile, if you're interested, my git repo is at gitorious repository.

What I wonder about your work, is how you handle the separation of geometry, i.e. that the geometry pass does not draw transparent objects like clouds? I was trying to add this to my system, and got it to sort of work (via pre-render callbacks) but it was ugly. I'm going to add an option in preferences.xml to select, which geometry (either render bin numbers or transparent/opaque etc) to render, which would allow multiple lights easily.

Zan 04:36, 20 December 2011 (EST)

Also see here (forum thread).--Hooray 07:13, 20 December 2011 (EST)

The cloud and the sky were removed from the main scenegraph (in renderer.cxx) and added as simple group nodes in the lighting camera (the stage before the display stage) before applying the ambient pass. I put banners in CameraGroup so it is easy to spot the different structures for each stage (CameraGroup::BuildGBufferCamera - a bit misnamed now).

Also don't forget most of state attributes are set in terrain-default.eff and model-default.eff

--Fredb 16:01, 20 December 2011 (EST)

You write about the transparent objects: In a cull callback attached to the Geometry camera, after the scenegraph traversal, the transparent bins are removed from the render stage and saved in a temporary collection. I have to tell you, when I made my modifications to the cameras, I was also thinking about deferred shader, and ended up with the exactly same method what you seem to be using! I just never found time to correctly implement it. I'm impressed that we both separately ended up with this same method! Zan 15:58, 15 January 2012 (EST)

So now I know I am on the right track ;-)

Regards

--Fredb 08:32, 16 January 2012 (EST)

Models modification log

Change KSFO_light.xml to apt-light.xml — Fredb

Why that? KSFO_light.xml is a special model, made for KSFO by Don Lavelle. Just like EHAM also has custom light poles. And EDDF. There are quite some actually...

Gijs 15:04, 3 January 2012 (EST)

Hi Gijs. Could you explain in what they are different and why there are only ten of then while there are more than 50 apt-light in KSFO ?

--Fredb 15:30, 3 January 2012 (EST)

They are two completely different models. Just compare them in Blender (or whatever editor). The KSFO_light ones match better with the real ones at KSFO (one of the differences is that the KSFO ones are grey/brown, rather than red/white striped). I don't know why only a few are placed, the red/white ones should be replaced (will talk to Jon on IRC in a minute).

Now that you're working on spot lights, it's important to realize that we (will) have many light pole models, simply because there are many variants in real life... ;)

Gijs 17:42, 3 January 2012 (EST)

Because of this: "Add a spot light animation" - testing real lights now? That would be great!

--HHS 15:09, 3 January 2012 (EST)

feed back on models

Howdy Fred, wonderful work. There are still plenty of thing to do, plenty about which modelers will rant, as usual, but let me tell you how much I appreciate what you have done with rembrandt. Now some rants comments:

• I worked on the f-14b cockpit and added 3 point lights to enlighten the space. No problem there, I managed (more or less) to keep the light volume inside the cockpit and this wasn't easy, and I linked the lights intensity to the instruments lights slider. the instruments have (since a long time) their own emission (material animation) but they just lose the color, so instead of being red lighted, they are now white. http://www.maison-capestang.com/fg/f-14b/f-14-inside-lighting-20120517.png
• The bloom effect is a bit too much IHMO. will it be settable per object ? (In my case it was too much because of bad and avoidable interaction between legacy emissiveness and rembrandt lights)
• SSAO is also a bit strong, it would be nice to test several strength on different models before settling a default value. Seen the rendering dialog with a SSAO effect slider. Well done Fred.
• No major problems with converting of referencing the transparencies, but the sky is much darker than the terrain horizon when seen through the propellers with transparency (material animation). http://www.maison-capestang.com/fg/E-2C/through-the-propellers.png
• Found some problems with transparent layers partially disappearing when yawing or pitching the view direction. If you like to test (an can stand the tomcat) try launching the f-14b, check that the HSD screen in on and displays the TID (radar) symbology. you'll see the radar sweep angle displayed with dashed lines, pitch the view, or move it to the side and you should see the lines disappear.
  • http://www.maison-capestang.com/fg/f-14b/radar-20120603a.png What is expected.
  • http://www.maison-capestang.com/fg/f-14b/radar-20120603b.png The sweep angle border lines and some of the aircrafts symbology (differents objects with transparent textures) disappear. Note at the bottom of the screen a piece of aircraft symbology, not overlaying the green and emissive background).

BTW: the f-14b in git has now plenty of nice light effects, try the switch and dimmers on the right console: http://www.maison-capestang.com/fg/f-14b/f-14b-right-console-light-panel.png note also the power switches on the DISPLAY panel (3 switches on the bottom row labeled POWER) for HUD, HSI and HSD.

Xiii 17:44, 17 May 2012 (EDT)

Interesting: If you register an emissive object as transparent, it keeps its colored config. The following works with rembrandt: green emissive opaque object.

 <effect>
   <inherits-from>Effects/model-transparent</inherits-from>
   <object-name>screen-bkg</object-name>
 </effect>
 <animation>
    <object-name>screen-bkg</object-name>
    <type>material</type>
    <emission>
      <factor-prop>sim/model/f-14b/controls/VDI/contrast</factor-prop>
      <red>0.0</red>
      <green>0.7</green>
      <blue>0.0</blue>
    </emission>
 </animation>

And it is realy cool news. But, but.... there are zbuffering issues (I suppose so because some overlaying transparent objects appears and disapear when the view pitch or yaw change).

Xiii 03:57, 20 May 2012 (EDT)

Mac issues, or not ?

Is it ever useful to blindly pull stuff out of context, just to add to the already "wall of text" that part of the page has become? I don't think anyone would bother to read the whole thing, nevermind that none of the issues mentioned are Mac specific, and that they could be related to a combination of various factors, of which the OS is the least significant.

I4dnf 23:12, 20 June 2013 (UTC)

glad to see you back, feel free to improve/revert my edits if you disagree. However, there are a bunch of Rembrandt issues, many related to ATI/AMD on Apple/Mac OSX, which was the reason for the section originally. Admittedly, not everything I added recently applies just to Macs. I'd rather keep feedback where it belongs than keeping it in different places, even though the issue tracker would definitely be the best place. But it is obvious that the Rembrandt developer is actively maintaining this article, so ... and it's not like we are expecting end-users to read such stuff, right - you also seem to have read it, for different reasons :) --Hooray 03:44, 21 June 2013 (UTC)