[SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Threads related to Google Summer of Code
Locked
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Sat Jun 27, 2009 4:56 pm

Good work. And yes, do concentrate on the minimum you need to test your functionality and you can always add the shinies later on :)
0 x

User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by xadhoom » Wed Jul 01, 2009 9:00 am

Hi Noman!

Here is an interesting article about the limitations of DS and Lightgroups. I find it quiet interesting...
http://gameangst.com/?p=167

xad
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1889
Joined: Sun Mar 08, 2009 5:25 am
x 36

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by mkultra333 » Sun Jul 05, 2009 6:35 pm

Hi, just a thought regarding stereoscopic compatibility.

Post processing on games is almost always erroneous when using a stereoscopic system (Such as the Nvidia stereoscopic glasses, or an iz3d monitor). You generally have to turn post processing effects of a game off to get it rendering correctly. According the nvidia paper on stereoscopic rendering, this shouldn't be the case. The main problem seems to be that the textures rendered to prior to the final backbuffer don't have the proper size and don't have some setting enabled, so the nvidia stereo drivers don't render correctly. From http://developer.download.nvidia.com/pr ... eo-web.pdf
Stereo in intermediate
textures
In StereoTextureEnable=1 mode a texture
will have left and right eye representation if
the following two conditions are met:
• Not square (width != height)
• Are of the same size as backbuffer or larger.
This is result of the following considerations:
• Stereo needs to be applied also to offscreen buffers,
so at least some textures should get stereo effect.
• However, not all textures should have it. For
example, shadowmaps (shadows fall the same
regardless of whether you look at them from left or
right eye POV).
Just thought I'd mention this, since it's a common flaw in the post processing of most games.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Praetor » Mon Jul 06, 2009 1:31 am

NVidia's stereo drivers are special and made just for them. You can't really expect everyone to follow their settings unless the application is specifically designed for stereo rendering. So far I've not found it easy to just "turn on" stereo rendering within an application not designed for it. You really need to design it into your application from the start.
0 x
Game Development, Engine Development, Porting
http://www.darkwindmedia.com

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1889
Joined: Sun Mar 08, 2009 5:25 am
x 36

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by mkultra333 » Mon Jul 06, 2009 8:53 am

That's true, but the requirements for being stereo compatible are fairly low. I've got stereo compatability in mind for my project. So far it's running in stereo fine, and I haven't done anything differnet for it than I would if I didn't care about stereo at all. Turning stereo on or off is as simple as going to the nvidia control panel and hitting a button. In fact, most of the ogre sample programs run fine in stereo.

But I know there are a few things I have to avoid at the moment: No deferred rendering and no compositors. The problem, I think, is that Ogre only seems to use square textures for RTT surfaces, you can't make them match the dimensions of the backbuffer and you can't access StereoTextureEnable=1. (AFAIK anyway... I'm far from fluent in what Ogre can and can't do.)

Edit: Actually I just noticed that the StereoTextureEnable thing is a variable in the registry for that program, not something set in-program.
Configuration is saved to HKLM\Software\NVIDIA
Corporation\Global\Stereo3D\GameConfigs\<game
exe name>
• Add DWORD entry StereoTextureEnable: 1
• Add DWORD entry StereoCutoff: 1
And judging by the RTT tutorial you can make the RTT texture the same size as the screen. So maybe it's not ogre's problem, but mine, and it's just that the demos aren't quite setup right for s3d. :)
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Praetor » Tue Jul 07, 2009 4:26 am

Yes but what I'm saying is any application using the compositors will inevitably be harder to make stereo compatible than one that doesn't. That's why the samples run so well in stereo, they are so simple they easily avoid the pitfalls. Few modern games or 3D applications will avoid these issues. Using square textures not the size of the screen is very common and often recommended. And post-processing is the easiest way to conflict with nvidia's requirements. I'd say there is a much better chance of nvidia continuing to refine their stereo system to catch up with modern 3d techniques, than for modern 3d techniques to generally accommodate stereo.
0 x
Game Development, Engine Development, Porting
http://www.darkwindmedia.com

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Wed Jul 08, 2009 12:48 pm

Thanks for the thoughts and insights!

xadhoom - The article is interesting, but is mostly related to certain specifics in deferred rendering implementations. They also proposed solutions, which will all be possible with the framework. I really believe that the improvements I'm making are generic improvements that give the user more flexibility. Deferred shading is an important use case, but its a use case...

As for the stereoscopic rendering, following up with the same idea, I don't see it as a 'core feature of ogre' (to support stereoscopic rendering for everything), but as an application-specific feature that someone might want to add to their application. It will be possible to address such features when using the improvements made to the framework, but the user will have to do the work...
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Thu Jul 09, 2009 10:45 am

Yes, I think this is the right approach to take Noman. That's not to say that later on, we can't provide helpers on top of the base to make certain use cases easier, that would probably be a good idea, but concentrating on the core featureset that can underpin many use cases is more important, as you are doing.
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Wed Jul 22, 2009 8:28 am

Been quiet for a while, had my finals and all, but they are behind me now, so I'm 100% GSoC until the end of the project (hopefully I won't have to retake any exams...)

Been thinking a lot about the light iteration stage, and I decided to go with the named custom passes idea, because it fits in very nicely with Ogre's current design.
I am going to have to refactor the classes a bit, and there is one unclear issue in the current design. It seems like CompositorInstance was designed to be subclassed in specific implementations (some methods were marked virtual). However, seeing as Ogre's internals create the instances, I don't see how that can work out. If I have a custom target pass, by the time that the script compilers 'know' that there is a custom render pass, the CompositorInstance is already created. So I really don't understand why some methods are marked virtual.

Anyways, my current plan is to introduce a "CustomCompositionPass" class that will register itself in the CompositorManager via a named interface. Ogre's current CompositionPass (which is just a data structure that keeps all the parameters, it doesn't actually have any logic associated) will have a 'custom name' that will be applicable when the PassType is PT_RENDERCUSTOM (new enum value), and then the collectPasses method in CompositorInstance (and similar methods) will delegate the logic to the CustomCompositionPass instance, which will be able to queue CompositorInstance::RenderSystemOperations (which will probably also be subclassed).
CustomCompositionPass is essentially a CompositorInstance::RenderSystemOperation factory. I assume that most of the custom logic will be in the RenderSystemOperation::execute method, but that works out nicely.

Current header looks like this :

Code: Select all

/** Interface for custom composition passes, allowing custom operations (in addition to
	*	the quad, scene and clear operations) in composition passes.
	*	@see CompositorManager::registerCustomCompositionPass
    */
    class _OgreExport CustomCompositionPass
    {
	public:
		/** Create a render system operation.
			@param pass The CompositionPass that triggered the request
			@remarks This call only happens once during creation. The RenderSystemOperation will
			get called each render.
		*/
		virtual CompositorInstance::RenderSystemOperation* createOperation(const CompositionPass* pass);

	protected:
		virtual ~CustomCompositionPass();
	};
At the end of the project (or in the merge with Ogre HEAD) we will have to decide whether these interfaces should remain in files of their own or be merged into existing files, but we'll worry about those problems when we get to them.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Wed Jul 22, 2009 10:53 am

Sounds good. I wouldn't worry about the virtual methods on CompositorInstance, they probably made their way in there during the evolving design of the original compositor system and are not entirely relevant anymore.
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Wed Jul 22, 2009 1:19 pm

Ok, good to know.
I implemented the first part of the custom rendering framework - The interface has been defined, passes can register themselves, and scripts can use this new feature to load it.
I modified the current deferred shading demo to use this infrastructure. The actual composition pass does nothing yet, but it does have access to the MRT textures and the (dummy for now) RenderSystemOperation does get called every frame.

The next part is adding the light/shadow related parameters that we discussed in earler posts. The list of additional parameters were
- iteration
- max lights
- start_light
- render_shadow_textures

The first 3 will be taken pretty much as-is from the material framework, and the last one will be a simple flag indicating if shadow textures need to be rendered before.
This isn't hard to implement, but I'm not confident with this choice yet. Are they really options that can be used in a variety of situations, or will the demo (and perhaps other DS systems) be the only ones that use them? If the latter is the case, then why should this be added to the scripting framework, and not just coded into the CustomCompositionPass ?

I'll probably let this sink in while I clean things up and hopefully get a clear perspective on things...
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Thu Jul 23, 2009 10:08 am

Another day, another update!

I'm starting to be genuinely excited about the results of this project. I finished refactoring the current state of the deferred shading demo to use the new infrastructure.

The result is, that the demo code (the one creating the scene) is not aware of the fact that it is using deferred shading. It now creates normal lights (as opposed to MLights using the DefferedShadingSystem class) and places them in the scene normally. The custom CompositionPass gets the light list from the scene, creates the geometry, pulls in the GBuffer texture from the previous compositor and sets everything up together. Its all connecting perfectly!

I still have some work to do to finish the refactoring - currently there is a lot of duplicate code because I had to keep both versions 'runnable' side by side to compare results. I'll just have to remove the dead code, which will show how the deferred shading system is more pluggable than it was before. The demo code isn't pretty to look at right now, but it does the job..

In addition to that, I've started hunting for art for the uber-demo which will showcase the new system properly, hopefully someone will donate a closed static scene to ogre...

I'm still undecided about adding the iteration/shadow related directives to the composition passes. They are only useful for the render_scene directive (as the render_quad can use the directives in the material definition, where they already exist), and I do feel like I will be bloating the scripting / parameter system. *Sigh*
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Thu Jul 23, 2009 4:18 pm

Noman wrote:This isn't hard to implement, but I'm not confident with this choice yet. Are they really options that can be used in a variety of situations, or will the demo (and perhaps other DS systems) be the only ones that use them? If the latter is the case, then why should this be added to the scripting framework, and not just coded into the CustomCompositionPass ?
This is a valid line of thought. The primary issue is (I think) that the iteration here requires behaviour that strictly is out of scope of the custom pass itself, such as rendering a shadow texture, and this functionality needs to be common and standard so that future updates to core Ogre will be reflected in it too. I guess the question is whether that's best encapsulated by driving that behaviour in the surrounding algorithm, or whether the custom pass should be iterating itself and calling utility functions. Provided these utility functions can be implemented in such as way as to not duplicate functionality already in Ogre, and fit well within the standard rendering setup, then I guess there's no reason why the custom pass can't do it, and it could potentially be more flexible this way. There are a few complications such as having to interrupt the rendering on one target to render another (shadow texture update) which would have to be managed in the custom pass if it drove things, but if it can be done cleanly then I'm open to that. You might just want to expose some parameters to the custom pass itself if there are options that a user might want to control without changing the code.
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Fri Jul 24, 2009 10:17 am

I agree that I shouldn't give the custom pass 'full responsibility' of doing everything, without aid. Probably going to use this weekend to research the current possibilities.
I will probably have to add a method to SceneManager that renders a light's shadow texture either way - even if I add a directive to the composition system, that will be the natural way to implement it.
Once that is in place, I might have an easier time making the decision...
If I eventually decide not to add them, I'll definitely add a 'custom_parameter' directive, so that the scripts will be able to pass whatever information they want to the code. It might be a good idea regardless...
I'll also explore the current DS implementing projects, try to see if someone went for calculating shadow maps later on, and thus not needing a shadow texture per light.

In the background, I've cleaned up the code for the deferred shading demo, so its more readable and understandable (IMO it already shows why the new additions make things more explicit, and thus clearer) and I modified the compositor demo to use CompositorLogics instead of hard-coding the compositor listeners to the compositors that require them. Should make it a lot easier for people to use them (HDR, Gaussian Blur, Heat Vision) in their programs, especially since it tells them that something is missing if they don't take the code as well.
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Fri Jul 24, 2009 4:29 pm

Thinking out loud time!

I've looked into how Ogre actually carries out compositor rendering - if I'm not mistaken, all the "To side RTT" passes are performed during CompositorChain::preRenderTargetUpdate, while the "to proper output" (usually render window, but not necessarily) is in CompositorChain::renderQueueStarted, as things happen.

In order to be able to cast shadow textures iteratively, we would need to be able to 'nest' CompositorInstance::RenderTargetOperations, possibly creating a "RenderShadowOperation" that the custom one will be able to call recursively. The challenge will be state handling - after each shadow texture is rendered, we will need to revert to the previous state, to render the light geometry to the main output, and then continue to the next one. Should be possible.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Fri Jul 24, 2009 6:23 pm

Yes, that's right. I've never been entirely happy with the way the compositors hook into the overall render process to be honest, it causes some state management complications (and the compiled ops also make things more complicated) which frequently bite us. But, it was the best solution at the time and it does the job, no-one's come up with a better way yet.

Yes, so the main deviation from this in your case is that you'll have 'full' renders to different targets going on in the renderQueueStarted area, which right now doesn't happen (just simple quad, clear & stencil operations on the same target). I sort of alluded to this when I mentioned the begin/end issues and switching targets. You'll effectively need to stop rendering to the current target, perform a full (shadow) render to another target, then continue rendering to the previous target, which as you say has some state issues all of its own.
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Sat Jul 25, 2009 10:45 am

Digging, digging, digging.

My current aim is to make it possible to render shadow textures for a light on demand.
So, just to start testing it out, I created a copy of SceneManager::prepareShadowTextures called SceneManager::prepareShadowTexturesPerLight, which currently does the same, but is public.

In addition, I created the following composition pass :

Code: Select all

	#include <OgreCustomCompositionPass.h>

	class ShadowTestRenderOperation : public Ogre::CompositorInstance::RenderSystemOperation
	{
		Ogre::Viewport* mVP;
	public:
		ShadowTestRenderOperation(Ogre::CompositorInstance* instance) {
			mVP = instance->getChain()->getViewport();
		}
		
		/** @copydoc CompositorInstance::RenderSystemOperation::execute */
		virtual void execute(Ogre::SceneManager *sm, Ogre::RenderSystem *rs)
		{
			sm->_prepareShadowTexturesPerLight(mVP->getCamera(), mVP, 0);
		}
	};

	class ShadowTestCP : public Ogre::CustomCompositionPass
	{
	public:
		/** @copydoc CustomCompositionPass::createOperation */
		virtual Ogre::CompositorInstance::RenderSystemOperation* createOperation(
			Ogre::CompositorInstance* instance, const Ogre::CompositionPass* pass)
		{
			return OGRE_NEW ShadowTestRenderOperation(instance);
		}
	};
An, as expected, since this composition pass is called during a frame update, we are already inside a _renderScene block, meaning that _beginFrame has been called, but the shadow rtt wants to render a scene itself, which of course, causes an exception.
So, our target right now is to be able to 'pause' rendering and 'resume' it later. It actually makes sense, as doing lighting this way really does require flipping back and forth between the shadow texture as the target (for generating it) and the final scene output as the target (for applying it to the scene), so any solution doing this requires this functionality.

So, i set out to explore how this could happen. Besides a few render calls that can be reorganized to be called on demand, I think the most critical object that would get lost in the process is the render queue, since a pretty heavy process goes into generating it.
So, I think that it will be necessary to remove the one-to-one scenemanager-to-renderqueue relationship. It should be possible, mid rendering, to extract the render queue, put it aside, pause rendering (endScene and all), start a new render sequence (with a different render queue), and when it finishes, inject the original render queue, and resume rendering (beginScene and all the initial calls).

I guess that the best way to do this is to create a temporary object, that upon pausing rendering, will be created and filled with all the information needed to resume rendering (like the render queue, projection matrix etc), and then it will be possible to resume rendering, using this object. The birth of Ogre::RenderContext ?

Afterwards, the code would probably look like : (schematically)

Code: Select all

		virtual void execute(Ogre::SceneManager *sm, Ogre::RenderSystem *rs)
		{
			Ogre::RenderContext* currentContext = sm->pauseRendering();
			sm->_prepareShadowTexturesPerLight(mVP->getCamera(), mVP, 0);
			sm->resumeRendering(currentContext);
			//Apply shadow and light to scene
		}
My only problem with this solution, is that I did not intend to make structural changes to Ogre's core (SceneManager class), and I do feel that I need to be extra careful when making changes to central classes like that.
I'll probably start working on it (mostly experimenting, still) soon. This will probably make the merge back into the main branch harder, but I think that it is a necessary step in this GSoC project, and perhaps, in the evolution of ogre.
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Sat Jul 25, 2009 2:56 pm

That was easier than I expected it to be. The current context code looks like this (again, very hacky ATM, but can be worked out into something nicer)

Code: Select all

struct SceneManager::RenderContext {
	RenderQueue* renderQueue;
	Viewport* viewport;
	Camera* camera;
};

SceneManager::RenderContext* SceneManager::_pauseRendering()
{
	RenderContext* context = new RenderContext;
	context->renderQueue = mRenderQueue;
	context->viewport = mCurrentViewport;
	context->camera = mCameraInProgress;
	
	mDestRenderSystem->_endFrame();
	mRenderQueue = 0;
	return context;
}
//---------------------------------------------------------------------
void SceneManager::_resumeRendering(SceneManager::RenderContext* context) 
{
	if (mRenderQueue != 0) 
	{
		delete mRenderQueue;
	}
	mRenderQueue = context->renderQueue;

	setViewport(context->viewport);
	mCameraInProgress = context->camera;
	mDestRenderSystem->_beginFrame();

	// Set rasterisation mode
    mDestRenderSystem->_setPolygonMode(mCameraInProgress->getPolygonMode());

	// Set initial camera state
	mDestRenderSystem->_setProjectionMatrix(mCameraInProgress->getProjectionMatrixRS());
	
	mCachedViewMatrix = mCameraInProgress->getViewMatrix(true);

	if (mCameraRelativeRendering)
	{
		mCachedViewMatrix.setTrans(Vector3::ZERO);
		mCameraRelativePosition = mCameraInProgress->getDerivedPosition();
	}
	mDestRenderSystem->_setTextureProjectionRelativeTo(mCameraRelativeRendering, mCameraInProgress->getDerivedPosition());

	
	setViewMatrix(mCachedViewMatrix);
	delete context;
}
It's currently mostly a mashup of code segments from renderScene().
Suprisingly, it works!
I was able to pause rendering, render a shadow map, and resume rendering. I didn't use the shadowmap yet, but I did check that it gets generated properly.

I'm going to use this hacky solution for development purposes currently, and start the new deferred shading demo (cg shaders, perhaps linear depth, shadow support, hopefully transparency support). Carrying out this demo will prove that deferred shading is an easier task with the new improvements, and the framework that will be implemented will be usable in real world projects. (Not 100% pluggable, but much closer to that than the current one).

[edit]
This feature (pausing rendering) might be useful for the compositor<->material bridge that was discussed earlier in the thread. If many objects require this pass (enough that you don't want a separate helper texture for each instance), this option can be used to pause main rendering, render the side-pass to an rtt and resume rendering, referencing that texture.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Sat Jul 25, 2009 6:24 pm

Nice solution, this sounds like it fits in quite nicely.
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by tuan kuranes » Sun Jul 26, 2009 6:54 am

Great Work !
The Rendering Context seems indeed the right way.

The compositor-material bridge would use it. But it also could help getting more understandable API mechanics on the renderScene code. (removing all the recursive calls 'if shadow pass', compositor hooks, getting smaller function code...).

Perhaps a "RenderContextQueue" with optionnal sorting/dependency API might also prove useful, using a sharable "RenderState" description of the RenderContext. Should help not only in material-compositor bridge,resource sharing/reuse, batching, etc., but also going even further in term of API clarification while getting more flexibility, allowing better render state handling ?
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Sun Jul 26, 2009 12:39 pm

Thanks!

To be honest, while I think this (RenderContext) option is a good one, I wish I didn't have to make it. I'm really trying to refrain from changing Ogre's core classes, so I probably won't go and add a bigger layer of sequence control to ogre's core.
I have an easier year next one (the first one is always the most exhausting) so I intend to help with the merge of this branch into the main development one, which will include a (design) decision on how to handle this option.

In the meantime, I started working on the big deferred shading demo. Currently working on a GBuffer material/shader generator, to get rid of the huge pile of shaders that were required for the previous one. The shaders will be CG, and the generator will support most of the common rendering options (single texture, normal map, vertex colors), and will be extendible for anyone wishing to use the deferred shading infrastructure presented in the demo in their application.

When that is done, I'll have the deferring shaders to go, and by then I'll hopefully have enough art to build a cooler scene.
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Sun Jul 26, 2009 3:50 pm

Noman wrote:Currently working on a GBuffer material/shader generator,
Just out of curiosity, why do you need a generator for this?
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Sun Jul 26, 2009 7:39 pm

nullsquared wrote:
Noman wrote:Currently working on a GBuffer material/shader generator,
Just out of curiosity, why do you need a generator for this?
I want to create a system where the art (or at least, almost all of it) does not have to be specifically prepared for deferred rendering.
So, the system will wait for the 'handleSchemeNotFound' calls, inspect the material that did not have a GBuffer technique defined (for example, find out that it has a texture, a normal map and uses skinning) and build the correct material/shaders for the operation.

If a certain material requires something not supported in the automatic system, it can always come with a predefined technique for the GBuffer scheme, which will mean that the handler will not get to the material.

This solution has its drawbacks (like having to implement it) but has advantages as well (easier to make changes to the GBuffer structure as theres only one central point that needs to be changed, less shaders to have to manage).

I think its a good idea to demonstrate such a possibility in a framework.
My implementation won't be super sophisticated, as I won't support all of the possibilities that exist. But I will support a lot of the main ones, and it will be possible to add more to make it a more robust solution...
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Sun Jul 26, 2009 8:41 pm

I see. That actually sounds pretty interesting - good luck :mrgreen:
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Sun Jul 26, 2009 9:09 pm

Thanks!

I know that it is a bit (maybe more than a bit :) ) overkill if I just wanted to create a demo that shows 5-6 different objects in a deferred scene with many lights.

However, I do feel that Ogre's samples have an... educational value rather than just a showcase value. Some of ogre's more advanced features don't really have usage examples, which is bad IMO. The documentation is good, but lots of people are lost when trying to do something, or try to add bits and pieces from samples they find in order to achieve what they want. This might cause them to overlook things ogre can do but aren't demonstrated.

When I finish the demo, I will also write a wiki article, explaining the ideas and motives behind this framework. It will hopefully give less experienced users a start if they have ideas they want to implement but aren't immediately available in ogre..
0 x

Locked