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)
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)
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)