setViewPort() and setRenderTarget()

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
Post Reply
heda
Posts: 10
Joined: Mon Jul 16, 2012 3:28 pm
Location: The Netherlands

setViewPort() and setRenderTarget()

Post by heda »

Hi there,

I've been trying to get my code up and running with irrlicht-1.8.0-alpha (rev4306) and I noticed a small difference compared to irrlicht 1.7.3 in the void COpenGLDriver::setViewPort(const core::rect<s32>& area) function that prevents me from using multiple viewports in combination with multiple render targets.

In bool COpenGLDriver::setRenderTarget(video::ITexture* texture, bool clearBackBuffer, bool clearZBuffer, SColor color) the viewport is automatically set to: glViewport(0,0,ScreenSize.Width,ScreenSize.Height) when I render to screen. To render to the correct viewport, I have to manually call setViewPort(const core::rect<s32>(my_x,my_y,my_width, my_height)) after caling setRenderTarget();

Code: Select all

 
void COpenGLDriver::setViewPort(const core::rect<s32>& area)
{
    if (area == ViewPort)
        return;
    core::rect<s32> vp = area;
    core::rect<s32> rendert(0,0, getCurrentRenderTargetSize().Width, getCurrentRenderTargetSize().Height);
    vp.clipAgainst(rendert);
 
    if (vp.getHeight()>0 && vp.getWidth()>0)
    {
        glViewport(vp.UpperLeftCorner.X,
                getCurrentRenderTargetSize().Height - vp.UpperLeftCorner.Y - vp.getHeight(),
                vp.getWidth(), vp.getHeight());
 
        ViewPort = vp;
    }
}
 
However, since the viewport stored by the OpenGl driver (ViewPort) wasn't changed, setViewPort returns immediately without making the glViewport call. Right now I use a workaround to first set the viewport to some other (dummy) value and then set it to the correct values, but that is sub-optimal.

I would like to propose to either remove these lines from setViewPort():

Code: Select all

 
//    if (area == ViewPort)
//        return;
 
or, maybe better, in setRenderTarget(), call setViewPort() instead of calling glViewport directly. I've tested both solutions and they both work fine.

I hope this can be implemented in irrlicht 1.8 :-)
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: setViewPort() and setRenderTarget()

Post by hybrid »

Yeah, the second choice sounds better. I need to check what was the actual cause for the change in setViewPort, but I guess we can get this into Irrlicht 1.8.
ataxxdog
Posts: 5
Joined: Thu Jan 23, 2014 4:50 am

Re: setViewPort() and setRenderTarget()

Post by ataxxdog »

Hi,

I'm using Irrlicht 1.8.1 and I have the same problem. I have two textures for ping-pong rendering to do a box blur. The procedure is like this:

setRenderTarget(texture1)
setViewPort(view)
...draw stuff...
setRenderTarget(texture2)
setViewPort(view)
...draw stuff...

Because the viewports are the same in both textures, after calling setRenderTarget() to switch textures, setViewPort() does nothing the second time (and instead the viewport defaults to the entire texture). I'm using the same workaround of setting the viewport to a dummy value first, then setting it back.

Will this bug be addressed in the next release?

EDIT: Forgot to say that I'm also using OpenGL.
Prototype game engine: https://github.com/thyau/lib50s
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: setViewPort() and setRenderTarget()

Post by hybrid »

Yeah, I had tested several things for the viewport things, basically in order to give some more possibilities of usage for the VP. However, I found some inconvenient differences between DX and OGL, which prevented an easy solution. So I postponed those changes and forgot about the minor bugs which could have been fixed.
ataxxdog
Posts: 5
Joined: Thu Jan 23, 2014 4:50 am

Re: setViewPort() and setRenderTarget()

Post by ataxxdog »

Ok cool. The workaround is simple enough, though of course I would like to get rid of it eventually. From a user's perspective this bug can be baffling when encountering it for the first time, so it would be nice to have it fixed.
Prototype game engine: https://github.com/thyau/lib50s
Post Reply