porting 1.9 to 2.0 viewport
- 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
hi again!
now the problems are relative to the viewport: how can I set and get the camera viewport?
now the problems are relative to the viewport: how can I set and get the camera viewport?
-
- 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
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?
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?
- 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
I'm trying to update my project, that contains also caelum, in depth:
https://code.google.com/p/caelum/source ... er.cpp#398
https://code.google.com/p/caelum/source ... er.cpp#398
-
- 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
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!
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!
- dark_sylinc
- 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
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.
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.
- Thyrion
- Goblin
- Posts: 224
- Joined: Wed Jul 31, 2013 1:58 pm
- Location: germany
- x 8
Re: porting 1.9 to 2.0 viewport
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());
Ogre::Ray mouseRay = mView.mCamera->getCamera()->getCameraToViewportRay(mMousePos.x / (Ogre::Real)mView.mViewport->getActualWidth(), mMousePos.y / (Ogre::Real)mView.mViewport->getActualHeight());
-
- OGRE Expert User
- Posts: 1119
- Joined: Sat Jan 01, 2011 7:57 pm
- x 216
Re: porting 1.9 to 2.0 viewport
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());
- Thyrion
- Goblin
- Posts: 224
- Joined: Wed Jul 31, 2013 1:58 pm
- Location: germany
- x 8
Re: porting 1.9 to 2.0 viewport
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";
//}
-
- 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
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'?
@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'?
-
- 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
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?
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?
- dark_sylinc
- 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
That's the point of CompositorPassDef::mIdentifier ; which is also documented in the manual I believe (if it's not, ping me).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?
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.
I'm not sure what needs to be clarified. May be I don't understand the problem being described.al2950 wrote:This was the point I was hoping dark_sylinc may have shed some light on.
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.
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.Thyrion wrote:and if not? i need a split screen. Each controller has a camera(viewport).
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.
-
- 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
Ah.... I completely missed that, sorry! However it does not appear to be in the manualdark_sylinc wrote: That's the point of CompositorPassDef::mIdentifier ; which is also documented in the manual I believe (if it's not, ping me).
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 offencedark_sylinc wrote:I'm not sure what needs to be clarified. May be I don't understand the problem being described.al2950 wrote:This was the point I was hoping dark_sylinc may have shed some light on.
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.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
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;
}
I have seen you use the word 'Soon' far too much now , perhaps there is an Ogre Christmas giftdark_sylinc wrote: This is coming soon, and not available at the time. But rest assured, this concern has been addressed and taken seriously
- Thyrion
- Goblin
- Posts: 224
- Joined: Wed Jul 31, 2013 1:58 pm
- Location: germany
- x 8
Re: porting 1.9 to 2.0 viewport
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?
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?
- 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
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'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
-
- 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
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.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
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!
- Thyrion
- Goblin
- Posts: 224
- Joined: Wed Jul 31, 2013 1:58 pm
- Location: germany
- x 8
Re: porting 1.9 to 2.0 viewport
for what do you need the viewport access?
- 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
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);