porting 1.9 to 2.0 viewport

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
User avatar
ghiboz
Goblin
Posts: 205
Joined: Wed Apr 25, 2007 9:47 pm
Location: Centallo (I)
x 2
Contact:

porting 1.9 to 2.0 viewport

Post by ghiboz »

hi again!
now the problems are relative to the viewport: how can I set and get the camera viewport?
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: porting 1.9 to 2.0 viewport

Post by al2950 »

Viewports are now designed only to be really used internally by the compositor system, and they, like scene nodes, have been simplified.

You control cameras, and in the compositor node you describe how/where it should render that camera. The compositor node will automatically create a viewport if one with the correct settings does not exists, or re-use an already created one.

I guess the question is, what are you trying to do which requires you to set/get a viewport camera?
User avatar
ghiboz
Goblin
Posts: 205
Joined: Wed Apr 25, 2007 9:47 pm
Location: Centallo (I)
x 2
Contact:

Re: porting 1.9 to 2.0 viewport

Post by ghiboz »

I'm trying to update my project, that contains also caelum, in depth:
https://code.google.com/p/caelum/source ... er.cpp#398
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: porting 1.9 to 2.0 viewport

Post by al2950 »

Ah yes, I used Caelum in the early days of my engine and it is still technically part of it although disabled via CMAKE at the moment. I have not had a chance to have a proper look at it with regards to converting it to Ogre 2.0, but I am doing ParticleUniverse and it has a similar things involving a depth texture.

Basically for the depth texture code and precipitation controller code, you are going to want to do it quite differently to how it is done currently. You should create a 'DepthPass' compositor node, probably in code, which you add to its own workspace, or allow the user to plug it into there own workspace somehow. Currently caelum works by attaching 'caelum' to a viewport, which it copies settings from. I am not sure the best way to do this in Ogre 2.0, you could pass it the settings manually, or maybe pass the compositor node that it should copy settings from, although it would actually need a specific pass that it should copy settings from....... Hmmmm, best to wait for Dark_Sylinc's view on this one! Sorry!
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: porting 1.9 to 2.0 viewport

Post by dark_sylinc »

Yes,

Either Caelum creates a Node that the user can add to his workspace to obtain the depth texture,
or Caelum creates its own Workspace (instead of creating its own Viewport) and manually updates that workspace.

The second option would resemble very much to the current code, except that the code calls myOwnWorkspace->update() instead of getDepthRenderTarget ()->update ();
plus some code outside that function to create the workspace.
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: porting 1.9 to 2.0 viewport

Post by Thyrion »

how can i get the "viewport/camera" width?

Ogre::Ray mouseRay = mView.mCamera->getCamera()->getCameraToViewportRay(mMousePos.x / (Ogre::Real)mView.mViewport->getActualWidth(), mMousePos.y / (Ogre::Real)mView.mViewport->getActualHeight());
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 216

Re: porting 1.9 to 2.0 viewport

Post by scrawl »

If you've only created one viewport filling the whole window, then the viewport width will be the window width.

Code: Select all

Ogre::RenderWindow* mRenderWindow;
...
Ogre::Ray mouseRay = mView.mCamera->getCamera()->getCameraToViewportRay(mMousePos.x / (Ogre::Real)mRenderWindow->getWidth(), mMousePos.y / (Ogre::Real)mRenderWindow->getHeight());
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: porting 1.9 to 2.0 viewport

Post by Thyrion »

and if not? i need a split screen. Each controller has a camera(viewport).

Code: Select all

{
					Ogre::CompositorPassSceneDef *passScene = static_cast<Ogre::CompositorPassSceneDef*> (targetDef->addPass(Ogre::PASS_SCENE));
					passScene->mShadowNode = Ogre::IdString();
					passScene->mVpWidth = 0.5;
					passScene->mVpHeight = 0.5;
					passScene->mVpLeft = 0.0f;
					passScene->mCameraName = camName.str(); // "LeftCamera";
				}
			
				//{
				//	Ogre::CompositorPassSceneDef *passScene = static_cast<Ogre::CompositorPassSceneDef*>
				//		(targetDef->addPass(Ogre::PASS_SCENE));
				//	passScene->mShadowNode = Ogre::IdString();
				//	passScene->mVpWidth = 0.5;
				//	passScene->mVpHeight = 0.5;
				//	passScene->mVpLeft = 0.5f;
				//	passScene->mCameraName = "RightCamera";
				//}
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: porting 1.9 to 2.0 viewport

Post by al2950 »

This was the point I was hoping dark_sylinc may have shed some light on. As far as I can work out what you really want is to extract those settings from the main scene pass. Viewports are meant to be basically hidden from the a standard dev, and cameras do not hold that info. The only place that info is made public is within the compositor node, and specifically the main render_scene pass. The fact there is not a defined 'viewport' is appearing to be a bit of an issue, albeit fairly minor, perhaps some more thought is needed to make that info more easily accessible. It would be nice to be able to mark/tag passes with some finite set, which could be used in code to work out things like this. Although reading that back to my self sounds very messy! Hmmm

@dark_sylinc
To put simpler, in Ogre 1.x you had to instantiate viewports when setting up Ogre. These were clearly defined and so was easy, from a dev point of view, to fetch the main scene render 'area'. In Ogre 2.0 this has been made a bit 'woolly' as the viewports are generated automatically. How should we (the devs) go about getting the main scene render 'area'?
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: porting 1.9 to 2.0 viewport

Post by al2950 »

After some further thought on this I think we should do the following;

At the moment you can assign a custom id to a pass, however it is only used by the CUSTOM_PASS type. This could be extended so that it is read and stored in the base compositor pass class. Furthermore we can add some helper functions to the compositor node or even the workspace to find a pass from its custom id. Once you have the correct pass you can get hold of the generated viewport and use as you would in Ogre 1.x, (As long as you dont try to modify it)

Any thoughts?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: porting 1.9 to 2.0 viewport

Post by dark_sylinc »

al2950 wrote:After some further thought on this I think we should do the following;

At the moment you can assign a custom id to a pass, however it is only used by the CUSTOM_PASS type. This could be extended so that it is read and stored in the base compositor pass class. Furthermore we can add some helper functions to the compositor node or even the workspace to find a pass from its custom id. Once you have the correct pass you can get hold of the generated viewport and use as you would in Ogre 1.x, (As long as you dont try to modify it)

Any thoughts?
That's the point of CompositorPassDef::mIdentifier :) ; which is also documented in the manual I believe (if it's not, ping me).

The main differences between the CUSTOM_PASS' id and CompositorPassDef::mIdentifier are:
  • The script syntax is slightly different (D'oh!)
  • CUSTOM_PASS uses IdString which means it can expressed as a user-readable string in the scripts, and in the Debugger in non-release builds; whereas mIdentifier is just a number.
  • You can have two CUSTOM_PASS with the same IdString but with different mIdentifier.
al2950 wrote:This was the point I was hoping dark_sylinc may have shed some light on.
I'm not sure what needs to be clarified. May be I don't understand the problem being described.
I agree, indeed in 1.x retrieving existing viewports was straightforward (although a lot of 3rd party code had the tendency to break when they suddenly faced a RenderTarget with more than one viewport and the main one didn't happen to be the first one).
Node setups can get quite complex, so it's probably best if the user sends the right Node/Pass to extract the dimensions.

Something that also works quite well if the code runs during the rendering phase is to get the current viewport from SceneManager::getCurrentViewport or from Camera::getLastViewport.
It shall be noted that in Ogre 1.x there was a Camera::getViewport function. This function in 2.x got renamed to Camera::getLastViewport. Nothing really changed. It is just a rename.
The rename happened because this new name reflects much more what it does; as Ogre 1.x users had the tendency of thinking that there was a 1:1 relationship between cameras and viewports. This was never true. Hence getLastViewport is more clear about this.

If your old code calling Camera::getViewport used to work perfectly fine, then there's a very high chance that just Find & Replace those calls with getLastViewport will solve the problem.
Thyrion wrote:and if not? i need a split screen. Each controller has a camera(viewport).
I'm afraid you'll have to create two pass definitions (or two different nodes); each with a different viewport. Basically duplicate the node def, change dimension parameters.
In Ogre 2.0 Final I made a couple enhancements to easily support split screen rendering (and other similar things, like stereo rendering).
It all boils down to creating 2 workspaces (one for each side of the screen); and a couple of extra parameters allow offsetting and scaling the viewports of the nodes contained in the workspace, with a pair of bitmasks:
  • The first bitmask decides which nodes will be offsetted and scaled, and which nodes will remain unaffected.
  • The second bitmask allows to prevent the execution of a particular pass.
This is coming soon, and not available at the time. But rest assured, this concern has been addressed and taken seriously :)
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: porting 1.9 to 2.0 viewport

Post by al2950 »

dark_sylinc wrote: That's the point of CompositorPassDef::mIdentifier :) ; which is also documented in the manual I believe (if it's not, ping me).
Ah.... I completely missed that, sorry! However it does not appear to be in the manual
dark_sylinc wrote:
al2950 wrote:This was the point I was hoping dark_sylinc may have shed some light on.
I'm not sure what needs to be clarified. May be I don't understand the problem being described.
Sorry, I never asked a direct question, it was just something I thought you may have mentioned in the context of this thread as it was in the back of my mind. I did not mean any offence :oops:
dark_sylinc wrote: Something that also works quite well if the code runs during the rendering phase is to get the current viewport from SceneManager::getCurrentViewport or from Camera::getLastViewport
Yes this is a good point, however I was trying to avoid suggesting this to people as it caused some confusion in Ogre 1.x, especially as some 3rd party plugins would steal the main rendering camera to use for its own RTT's.

Here is some example code to show how I think it should be used; (NB This example is over simplified, and not tested! )

Code: Select all

compositor_node MainSceneRender
{
	in 0 rt_output
	target rt_output
	{
		pass render_scene
		{
			identifier 101	
		}
	}	
}

workspace LeftEye
{
	connect_output MainSceneRender 0
}

Code: Select all

//Initialise workspaces left & right eye
....
IdString mainSceneNodeId = "MainSceneRender";
const CompositorPassVec &passes = leftEyeWorkspace->findNode(mainSceneNodeId);
CompositorPassVec::const_iterator itPasses = passes.begin();
CompositorPassVec::const_iterator enPasses = passes.end();
Viewport* leftSceneViewport = nullPtr;
while( itPasses != enPasses )
{
    if ((*itPasses)->getDefinition()->mIdentifier == 101)
    {
        leftSceneViewport = (*itPasses)->getViewport();
        break;
    }
    ++itPasses;
}
Admittedly its not the nicest code, and its a little complicated to get what we want. But it should work :)
dark_sylinc wrote: This is coming soon, and not available at the time. But rest assured, this concern has been addressed and taken seriously :)
I have seen you use the word 'Soon' far too much now :P, perhaps there is an Ogre Christmas gift :D
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: porting 1.9 to 2.0 viewport

Post by Thyrion »

I rethought the need of the viewport access.
Currently i need only the size of the viewport.
But the size of the viewport is exactly the same size as the window, without titlebar and border (or am i wrong?).
So i could calculate the size of the viewport with the window size and don't need access to it.

Or does it lead to problems that i'm currently unaware of? :)
User avatar
ghiboz
Goblin
Posts: 205
Joined: Wed Apr 25, 2007 9:47 pm
Location: Centallo (I)
x 2
Contact:

Re: porting 1.9 to 2.0 viewport

Post by ghiboz »

hello again!
I've completed the first steps to port my code but in my mind is not clear now how the viewport works:
in ogre 1.x you create the renderwindow, after add the viewport to the renderwindow and finally set a camera to the viewport.
in ogre 2.x how works the compositor (i wish understand a simple sample how to create a window 800x600 and render the camera view into the window...

thanks :)
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: porting 1.9 to 2.0 viewport

Post by al2950 »

ghiboz wrote:hello again!
I've completed the first steps to port my code but in my mind is not clear now how the viewport works:
in ogre 1.x you create the renderwindow, after add the viewport to the renderwindow and finally set a camera to the viewport.
in ogre 2.x how works the compositor (i wish understand a simple sample how to create a window 800x600 and render the camera view into the window...

thanks :)
I think the first point to understand is that viewports are created and managed automatically by the compositor system, so you do not create them any more.

Understanding the new compositor system is critical for creating a working application with Ogre2.0, so I suggest you look at the porting manual here;
https://bitbucket.org/sinbad/ogre/src/b ... dt?at=v2-0

And look at the sample_compositor and relating scripts, eg Media\materials\scripts\Examples.compositor

If you have already done that than please can you be a bit more specific with your question!
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: porting 1.9 to 2.0 viewport

Post by Thyrion »

for what do you need the viewport access?
User avatar
ghiboz
Goblin
Posts: 205
Joined: Wed Apr 25, 2007 9:47 pm
Location: Centallo (I)
x 2
Contact:

Re: porting 1.9 to 2.0 viewport

Post by ghiboz »

now i've added this and something start to be visible in the window:

Code: Select all

Ogre::CompositorManager2 *compositorManager = m_pRoot->getCompositorManager2();
const Ogre::IdString workspaceName("my_Workspace");
if (!compositorManager->hasWorkspaceDefinition(workspaceName))
{
	compositorManager->createBasicWorkspaceDef(workspaceName, ColourValue(0.527f, 0.527f, 0.527f, 1.0f), Ogre::IdString());
}
cmpWks = compositorManager->addWorkspace(m_pSceneMgr, m_pRenderWnd, m_pCamera, workspaceName, true);
Post Reply