[Implemented] Next compositor improvements
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Proposal : Next compositor improvements
This is great!
@Noman: So with these changes, what's the performance boost like?
@Noman: So with these changes, what's the performance boost like?
- Noman
- OGRE Retired Team Member
- Posts: 714
- Joined: Mon Jan 31, 2005 7:21 pm
- Location: Israel
- x 2
- Contact:
Re: Proposal : Next compositor improvements
I didn't measure properly yet but the gain was not too big, especially when SSAO is on.
When the patch will be properly incorporated I might do some direct benchmarking..
When the patch will be properly incorporated I might do some direct benchmarking..
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Proposal : Next compositor improvements
Alright, me waits patiently.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Proposal : Next compositor improvements
I've commented on the patch, please commit & close once you've addressed the small issues I raised.
- Noman
- OGRE Retired Team Member
- Posts: 714
- Joined: Mon Jan 31, 2005 7:21 pm
- Location: Israel
- x 2
- Contact:
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
Re: [Implemented] Next compositor improvements
I assume this will need changes to the manual, correct?
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
http://www.darkwindmedia.com
- Noman
- OGRE Retired Team Member
- Posts: 714
- Joined: Mon Jan 31, 2005 7:21 pm
- Location: Israel
- x 2
- Contact:
Re: [Implemented] Next compositor improvements
I updated the manual with the new options (compositor content_type and composition pass scoped material schemes) in the original commits.
I tested and the docs compiled fine here. I only updated the sources in SVN, I'm letting sinbad update the compiled docs... (I don't get the exact same result)
I tested and the docs compiled fine here. I only updated the sources in SVN, I'm letting sinbad update the compiled docs... (I don't get the exact same result)
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
Re: [Implemented] Next compositor improvements
Ok. No need to update the online docs until this version is out. I'll take a look at SVN.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
http://www.darkwindmedia.com
- iloseall
- Gremlin
- Posts: 156
- Joined: Sun Sep 14, 2003 3:54 am
- Location: Beijing China
- Contact:
Re: [Implemented] Next compositor improvements
I think content_type compositor should find parent compositor when texture_unit could not found compositor chain on current viewport.
May be change Ogre::SceneManager::_setActiveCompositorChain(CompositorChain* chain) to use a stack?
main compositor render target update
push CompositorChain ptr
....
...
sub render target
push null ptr
...
pop null ptr
pop ptr
so in sub render target update,we can find the parent compositor chain on top of stack.
for example:
river objects material:
May be change Ogre::SceneManager::_setActiveCompositorChain(CompositorChain* chain) to use a stack?
main compositor render target update
push CompositorChain ptr
....
...
sub render target
push null ptr
...
pop null ptr
pop ptr
so in sub render target update,we can find the parent compositor chain on top of stack.
for example:
Code: Select all
refraction
compositor Main
{
tec
{
texture main_buffer;
texture small_buffer_for_refraction;
...
pass //render solid objects
{
target main_buffer
render scene
{
//solid objects
first_id 40
last_id 50
}
}
...
pass //copy main buffer to refraction buffer
{
target small_buffer_for_refraction
render_quad
{
material down_sampler
input
{
main_buffer
}
}
}
pass //render river with refraction buffer
{
target main_buffer
render scene
{
//river objects
first_id 60
}
}
pass //render other transparent objects
{
target main_buffer
render scene
{
// transparent objects
first_id 61
last_id 80
}
}
pass for output
{
render_quad
{
material copy_
input
{
main_buffer
}
}
}
}
}
Code: Select all
texutre_unit
{
content_type compositor "Main" "small_buffer_for_refraction" 0
/*
it don't work. the river is render to Main_buffer's viewport.
but main_buffer (current render target) has not compositor chain .
*/
}
- Noman
- OGRE Retired Team Member
- Posts: 714
- Joined: Mon Jan 31, 2005 7:21 pm
- Location: Israel
- x 2
- Contact:
Re: [Implemented] Next compositor improvements
This is exactly what the "activeCompositorChain" solves.
Once a compositor chain starts, it becomes the active compositor chain until the viewport finishes or until another compositor comes into play (pause/resume rendering etc).
It should work with the current design.
If it doesn't please give me a code example and I'll see why.
Once a compositor chain starts, it becomes the active compositor chain until the viewport finishes or until another compositor comes into play (pause/resume rendering etc).
It should work with the current design.
If it doesn't please give me a code example and I'll see why.