Oculus Rift in Ogre

AshMcConnell · Post by **AshMcConnell** » Sat Jul 13, 2013 12:06 am

Thanks to Kojack for all the hard work. I've got it working

Has anyone got MyGUI working with it at all? Any tips? I don't see any UI at all

Post by **Kojack** » Sat Jul 13, 2013 3:08 am

Cool stuff!

I haven't tried any ui yet. That's something that really needs a rift for testing.

My order went to processing a few days ago, so I'm closer to getting the real thing. Then coding can resume.

AshMcConnell · Post by **AshMcConnell** » Sat Jul 13, 2013 11:10 pm

I don't have mine yet either, but it's on it's way so I thought I'd see how hard it is to add support. I was scratching my head for a long time thinking it wasn't working. It just that my menus weren't showing up. I'm not sure why yet, it's been a while since I fiddled with Ogre stuff (I've been doing non-graphics coding for a long time), so I'm a bit rusty.

scrawl · Post by **scrawl** » Tue Jul 30, 2013 5:09 pm

AshMcConnell wrote: Has anyone got MyGUI working with it at all? Any tips? I don't see any UI at all

MyGUI can only render to one viewport at once. So your best bet would be to render MyGUI to a texture, then put a 3d plane with that texture in your gameworld. The added bonus is that it will even "seem" 3d.

cullam · Post by **cullam** » Thu Aug 01, 2013 2:28 pm

Kojack, which version of Ogre are you using? I've been working with 1.8, but trying to build your Oculus project is giving me a linker error, looking for ogreoverlay_d.lib. I might have mis-read the discussion on this, but I thought that that was an addition in 1.9. Is that correct? Do I need to use 1.9 for this?

Post by **Kojack** » Fri Aug 02, 2013 7:17 am

I used Ogre 1.9, but the code should work fine on 1.8.

Open up the demo project and go to it's properties. In the Linker / Additional Dependencies field right near the end is ogreoverlay.lib for release builds and ogreoverlay_d.lib for debug. Remove that and it should work fine.
(The demo doesn't currently use the overlay system, so removing it won't hurt)

I haven't had any time to play with rift stuff or upgrade the ogreoculus code. Work has been pretty heavy.

xrgo · Post by **xrgo** » Wed Aug 07, 2013 10:12 pm

Kojack wrote:Cool.

I'll try to get an update out soonish (very busy at work, we just started a new trimester and I'm teaching first and second year students) that adds in the new sdk features (chromatic aberation correction and yaw drift correction). I've already got the chromatic aberation shader working.

Hi! can you share the shader with chromatic aberration please!?
thanks in advance!

cullam · Post by **cullam** » Fri Aug 09, 2013 7:47 pm

So, I got the basic demo built and running. I'm now working on integrating the rift into a simulation project we've been working on for a bit. While I won't be able to release much related to that project, I'll be trying to share as much as I can about what I learn about using and programming for the rift.

Anyway, I'm currently have some library issue, wondering if anyone has had this pop up in their own work. I'm getting unresolved externals in libovr64.lib(OVR_Timer.obj). I've gone through all my lib configs pretty carefully, and there doesn't appear to be anything obvious I've missed. Any idea if this an issue in the actual Oculus 64 bit library?

cullam · Post by **cullam** » Tue Aug 13, 2013 3:35 pm

Google did NOT want me to find this information! Had to just start typing in random keywords from the error. Anyway, my issue with the 64 bit library has been resolved. It's something that they mean to fix in future, but for now, if you get linker errors when trying to use the 64 bit library, the solution can be found here:
https://developer.oculusvr.com/forums/v ... f=34&t=473

amartin · Post by **amartin** » Wed Aug 14, 2013 7:12 am

xrgo wrote: Hi! can you share the shader with chromatic aberration please!?
thanks in advance!

This is more or less the chromatic aberation shader. I've skipped the early break out if the blue is outside the visible area but the example code is there. Honestly I can't see a difference between using it and not but most of the demos are pretty simple. Thanks to Kojack for the starting point change the main_fp shader over to this and set the extra param.

Code: Select all

uniform float2 ScreenCenter;
uniform float2 LensCentre;
uniform float2 Scale;
uniform float2 ScaleIn;
uniform float4 HmdWarpParam;
uniform float4 ChromAbParam; // <= this is the new paramater.

float4 main_fp(float4 pos : POSITION, 
		float2 iTexCoord : TEXCOORD0, 
		uniform sampler2D RT : register(s0)) : COLOR
{
	float2 theta = (iTexCoord - LensCentre) * ScaleIn; // Scales to [-1, 1]
	float rSq = theta.x * theta.x + theta.y * theta.y;
	float2 theta1 = theta * (HmdWarpParam.x + HmdWarpParam.y * rSq + HmdWarpParam.z * rSq * rSq + HmdWarpParam.w * rSq * rSq * rSq);
	float2 tc = LensCentre + Scale * theta1;

	// Detect whether blue texture coordinates are out of range
	// since these will scaled out the furthest.
	float2 thetaBlue = theta1 * (ChromAbParam.z + ChromAbParam.w * rSq);
	float2 tcBlue = LensCentre + Scale * thetaBlue;

	//todo break out early here note the following lines are hlsl while the rest is in cg
//if (any(clamp(tcBlue, ScreenCenter -float2(0.25,0.5),
	//ScreenCenter+float2(0.25, 0.5)) - tcBlue)

	// Now do blue texture lookup.
	float blue = tex2D(RT, tcBlue).b;
	// Do green lookup (no scaling).
	float2 tcGreen = LensCentre + Scale * theta1;
	float green = tex2D(RT, tcGreen).g;
	// Do red scale and lookup.
	float2 thetaRed = theta1 * (ChromAbParam.x + ChromAbParam.y * rSq);
	float2 tcRed = LensCentre + Scale * thetaRed;
	float red = tex2D(RT, tcRed).r;

	return float4(red, green, blue ,1);
}

To get the chromatic aberation you will want to look it up from the device.

Code: Select all

Ptr<HMDDevice>		pHMD;
OVR::HMDInfo devinfo;
pHMD->GetDeviceInfo(&devinfo);

ChromAb = Ogre::Vector4(devinfo.ChromaAbCorrection[0],
						devinfo.ChromaAbCorrection[1],
						devinfo.ChromaAbCorrection[2],
						devinfo.ChromaAbCorrection[3]);

pParamsLeft->setNamedConstant("ChromAbParam", ChromAb);

For correcting for drift if I read the docs correctly you just need to call the calibrate function on the SDK then make the user look 4 different directions after that it should correct for drift internally. Finally the good old tutorial look around the place serves a purpose.

amartin · Post by **amartin** » Sat Aug 17, 2013 8:53 am

Is anyone else seeing distortion towards the top and bottom of the view using the Y FOV value provided by the sdk. The default value I'm getting is 125 degrees but that gives me some visible distortion towards the top and bottom objects tend to stretch and appear closer if they are at the edges of the screen. I tried manually performing the cals from the docs for Y FOV but that came up with a different answer and distortion in the opposite direction. At the moment I'm using a magic number of 1.9 radians (110 degrees) which pretty much removes the distortion but has no basis in any of the provided numbers. I would like to know if anyone else is seeing this issue I'm trying to figure out if I'm missing some steps or Ogre just handles things differently to some of the systems that already have integration.

xrgo · Post by **xrgo** » Fri Aug 23, 2013 3:47 am

Thanks amartin for the shader =) it works!

alonzo · Post by **alonzo** » Mon Sep 09, 2013 10:46 am

Hi All,

I've gotten my Oculus yesterday and have had a frustrating time getting ogreoculus to work on Fedora, so I wanted to share this code with the forum in the hopes it helps someone, and of course to thank rajetic for doing it in the first place!

My fork: git://gitorious.org/ogreoculus/ogreoculus.git
See README.Fedora for rebuliding ogre with Cg support (since Cg is non free it isn't in feora but only in rpmfusion, but luckily it's just a single line change in the spec file).
The changes should not break windows, everything is ifdefed on WIN32, but I didn't check.

I tested on Fedora with an intel graphics card, it worked fine. I was surprised Cg doesn't require AMD/Nvidia graphics cards. The cathedral is awesome!

Alon

bullale · Post by **bullale** » Fri Sep 20, 2013 6:37 am

amartin wrote:Is anyone else seeing distortion towards the top and bottom of the view using the Y FOV value provided by the sdk. The default value I'm getting is 125 degrees but that gives me some visible distortion towards the top and bottom objects tend to stretch and appear closer if they are at the edges of the screen. I tried manually performing the cals from the docs for Y FOV but that came up with a different answer and distortion in the opposite direction. At the moment I'm using a magic number of 1.9 radians (110 degrees) which pretty much removes the distortion but has no basis in any of the provided numbers. I would like to know if anyone else is seeing this issue I'm trying to figure out if I'm missing some steps or Ogre just handles things differently to some of the systems that already have integration.

Hi amartin,
I'm having the same issues and setting it to 110 degrees helped. Thank you.

BTW, I don't know if this is relevant, but I'm using Python-Ogre 1.7.2 and a Python wrapper for a dll of a C-wrapper from the SDK and my Python-Ogre implementation fails to load Plugin_CgProgramManager.dll.

bullale · Post by **bullale** » Fri Sep 20, 2013 7:29 am

I forgot to add, the SDK is returning distortion values of [1, 1, 1, 1] so I am using Kojack's default distortion values. That might be part of the problem.
I'm also using Lens B.

bullale · Post by **bullale** » Mon Sep 23, 2013 7:27 am

Hi again.

Because I made my own application and knew what it looked like on a flat screen, the distortion problems were glaringly obvious when I reproduced that application inside the rift. Then, upon re-examining the ogreoculus project, I was better able to notice the same distortion problems. For example, look directly at a pillar top then notice how the pillar appears to stretch as you pitch your head down toward the center of the pillar.

I've identified some inconsistencies between the Oculus SDK samples and this ogreoculus project but I'm not quite good enough with C++/Ogre/shaders to resolve them to determine if they are indeed the source of the distortion problems. I hope others here can help.

First, not related to the distortion, the camera movement might seem more natural if we model the head. Our axis of rotation is the base of our head so we might want to add some y (base of head to eye level) and -z (center of head to eye protrusion) to the camera positions. This is done in the samples in the SDK but I don't know how to translate that to Ogre.

Next, the fragment shader program has the following variables:

Code: Select all

uniform float2 LensCentre;
uniform float2 Scale;
uniform float2 ScaleIn;
uniform float4 HmdWarpParam;

Notice that LensCentre, Scale, and ScaleIn are 2-element float arrays.
Inside OgreOculus.cpp Oculus::setupOgre implementation:

Code: Select all

pParamsLeft->setNamedConstant("HmdWarpParam", hmdwarp);
pParamsRight->setNamedConstant("HmdWarpParam", hmdwarp);
pParamsLeft->setNamedConstant("LensCentre", 0.5f+(m_stereoConfig->GetProjectionCenterOffset()/2.0f));
pParamsRight->setNamedConstant("LensCentre", 0.5f-(m_stereoConfig->GetProjectionCenterOffset()/2.0f));

m_stereoConfig->GetProjectionCenterOffset() returns a single float, so the second entry in the LensCentre parameter is not set. Maybe this is OK because the second element in the parameter is for the y-coordinate and is always 0.5?

The next problem is that the Scale and ScaleIn parameters are never changed from the defaults in ogreoculus but they are in the Oculus SDK examples.
From the Oculus SDK RenderTiny_Device.cpp void RenderDevice::FinishScene1()

Code: Select all

float w = float(VP.w) / float(WindowWidth),
        h = float(VP.h) / float(WindowHeight),
        x = float(VP.x) / float(WindowWidth),
        y = float(VP.y) / float(WindowHeight);

float as = float(VP.w) / float(VP.h);
pPostProcessShader->SetUniform2f("LensCenter",
                                 x + (w + Distortion.XCenterOffset * 0.5f)*0.5f, y + h*0.5f);
pPostProcessShader->SetUniform2f("ScreenCenter", x + w*0.5f, y + h*0.5f);
float scaleFactor = 1.0f / Distortion.Scale;
pPostProcessShader->SetUniform2f("Scale",   (w/2) * scaleFactor, (h/2) * scaleFactor * as);
pPostProcessShader->SetUniform2f("ScaleIn", (2/w),               (2/h) / as);
pPostProcessShader->SetUniform4f("HmdWarpParam",
                                 Distortion.K[0], Distortion.K[1], Distortion.K[2], Distortion.K[3]);

Notice that both elements of the parameters are being set. I added some std::cout << lines to the above and got the following:

Code: Select all

w: 0.5, h:1, x:0.5, y:0, as: 0.8
LensCenter: 0.712006, 0.5
ScreenCenter: 0.75, 0.5
scaleFactor: 0.583225
Scale: 0.145806, 0.23329
ScaleIn: 4, 2.5
HmdWarpParam: 1, 0.22, 0.24, 0

I plugged these numbers into oculus.material. They are crazy wrong for the x-direction, they aren't so bad for y. They certainly alleviate the y-distortion.

It would be nice to know how to set these numbers in code, and also how to calculate the x numbers properly for ogreoculus.

amartin · Post by **amartin** » Mon Sep 23, 2013 1:15 pm

bullale wrote: First, not related to the distortion, the camera movement might seem more natural if we model the head. Our axis of rotation is the base of our head so we might want to add some y (base of head to eye level) and -z (center of head to eye protrusion) to the camera positions. This is done in the samples in the SDK but I don't know how to translate that to Ogre.

This is the easy part simply adjust the y and z values when positioning the camera in addition to setting the x for each camera.

Code: Select all

mCamera->setPosition(mStereoConfig->GetIPD() * -0.5f, 0.075f, 0.045f);

You then apply the orientation from the Oculus to the parent node of the cameras and they will rotate around it happily.

bullale wrote: I've identified some inconsistencies between the Oculus SDK samples and this ogreoculus project but I'm not quite good enough with C++/Ogre/shaders to resolve them to determine if they are indeed the source of the distortion problems. I hope others here can help.

...snip

I plugged these numbers into oculus.material. They are crazy wrong for the x-direction, they aren't so bad for y. They certainly alleviate the y-distortion.

It would be nice to know how to set these numbers in code, and also how to calculate the x numbers properly for ogreoculus.

I think the problem with the x direction stems from the fact they are using a square texture for their shader which we are not. You are correct though we were not setting the scale in Y properly and this was causing the distortion vertically. You can try

Code: Select all

	float scaleFactor = 1.0f / mStereoConfig->GetDistortionScale();
	float aspectRatio = mCamera->getAspectRatio();
	Ogre::Vector2 scaleIn = Ogre::Vector2(2.0f, 2.0f /aspectRatio);
	Ogre::Vector2 scale = Ogre::Vector2(0.5f* scaleFactor, 0.5f * scaleFactor * aspectRatio);

	pParamsLeft->setNamedConstant("Scale", scale);
	pParamsLeft->setNamedConstant("ScaleIn", scaleIn);

This seems to resolved the vertical distortion when using the default Y field of view from the SDK. The downside is that it appears to make the colour distortion worse so I'll have to have another look at the colour distortion shader to see if I can fix that.

The distortion value you reported from the sdk example matche mine either way here are the values I'm getting for both of the distortions the don't change so you can set them as material defaults.

Code: Select all

HmdWarpParam = {x=1.0000000 y=0.22000000 z=0.23999999 0.0}
ChromAbParam = {x=0.99599999 y=-0.0040000002 z=1.0140001 0.0}

bullale · Post by **bullale** » Mon Sep 23, 2013 2:01 pm

Great, thank you for that. I didn't know Ogre had a Vector2 class.

I tried using the chromatic aberration shader you posted above and then set its param to what I pulled from the device but it didn't seem to do anything. I guess you're looking into this, and you're more capable than I am, so I'll leave it to you.

Since this project is the only Ogre + Oculus Rift sample code that I know of, I think it's worth it to update it with the changes that we've made. Once you've figured out the chromatic aberration shader, can you make a pull request on bitbucket (in addition to posting it here)? Or, if you're not familiar with git and you don't want to be, then let me know and I'll do it.

amartin · Post by **amartin** » Tue Sep 24, 2013 12:43 am

I'll look into it. The repo is mercurial which I am not familiar with which is why I didn't automatically start working that way. I've got my code in a public repo but I won't post a link to that till after I've forked ogre otherwise nobody would be able to build it.

I'm neck deep in the Directx 11 render system at the moment so work on the shader will wait till I need a distraction from that. I'm not really sure what is wrong with it at the moment but I'm guessing it is due to the difference in X axis values we are seeing in the Scale and ScaleIn paramaters.

Post by **Kojack** » Tue Sep 24, 2013 1:11 am

Unfortunately work hit me pretty hard, I haven't even plugged my oculus in for a month or so.
One thing I need to do is rewrite most of the way the compositors and shaders are handled, so real time changes to properties like ipd is possible. Ogre's compositors don't like that. I've had it working in the past, but I didn't like it. Looks like there's no choice though.

bullale · Post by **bullale** » Tue Sep 24, 2013 3:21 am

Kojack wrote:Unfortunately work hit me pretty hard, I haven't even plugged my oculus in for a month or so.

I managed to make one of my work projects require the Rift, otherwise I'm right there with you.

Kojack wrote:One thing I need to do is rewrite most of the way the compositors and shaders are handled, so real time changes to properties like ipd is possible. Ogre's compositors don't like that. I've had it working in the past, but I didn't like it. Looks like there's no choice though.

I noticed the SDK updates the shader parameters on every frame. That seems terribly inefficient for parameters that rarely change. I think it would be more efficient to set a IsDirty boolean and only update when the user manually changes some settings. Even then, I think a better model would be to rely on the user to use the official utilities to set IPD and other settings then assume the values obtained from the device upon start-up are accurate.

Why do you think it's necessary to update the IPD in real-time?

amartin wrote:I've got my code in a public repo but I won't post a link to that till after I've forked ogre otherwise nobody would be able to build it.

Based on my recent experience learning msvc++, mingw, python, ogre, and python-ogre: When releasing something open-source, please do not bother with automatic build scripts. You'll have several types of people downloading, including those that just want sample code, those that just want the binaries to try it out, and those that are just starting out (like me). The former two types of people only need the project source files and the binaries. People like me do not benefit from automatic build scripts, especially since those scripts tend to be system-specific and they age quickly. Instead, consider providing instructions on where to find the necessary headers and compiled libraries and what needs to be included and linked. If you want to host the necessary SDK elements because you are worried that particular version might not be available to download in the future then that's good, but not at the expense of instructions. This kind of documentation can be tedious but I can write most of it if you want.

amartin wrote:I'm not really sure what is wrong with it at the moment but I'm guessing it is due to the difference in X axis values we are seeing in the Scale and ScaleIn paramaters.

I don't know if this is helpful, but the chromatic aberration was only in the x-direction (blue shifted +x), not in the y.

amartin wrote: You can try

Code: Select all

	float scaleFactor = 1.0f / mStereoConfig->GetDistortionScale();
	float aspectRatio = mCamera->getAspectRatio();
	Ogre::Vector2 scaleIn = Ogre::Vector2(2.0f, 2.0f /aspectRatio);
	Ogre::Vector2 scale = Ogre::Vector2(0.5f* scaleFactor, 0.5f * scaleFactor * aspectRatio);

	pParamsLeft->setNamedConstant("Scale", scale);
	pParamsLeft->setNamedConstant("ScaleIn", scaleIn);

Unfortunately setNamedConstant does not allow inputs of type Ogre::Vector2. This alternative may work but I don't know how to do it in Python http://www.ogre3d.org/docs/api/html/cla ... d10cc2101e.

dermont · Post by **dermont** » Tue Sep 24, 2013 4:28 am

If you are using python-ogre I think you may have to use ctypes, something like this.

Code: Select all

class CustomShader4(object):
    def __init__(self):

        s = " void customColourVp(float4 position : POSITION,"
        s+= "out float4 oPosition : POSITION,"
        s+= "uniform float4x4 worldViewProj)"
        s+= "{"
        s+= "   oPosition = mul(worldViewProj, position);"
        s+= "}"

        customCasterMatVp = s

        s = " void customColourFp(\n"
        s+= " uniform float4 MyColour,"
        s+= "out float4 oColor : COLOR)"
        s+= "{"
        s+= "   oColor = MyColour;"
        s+="}"

        customCasterMatFp = s

        grpName = ogre.ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME

        vp = ogre.HighLevelGpuProgramManager.getSingleton().createProgram(
              "CustomColourVp",
              ogre.ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME,
              "cg", 
              ogre.GPT_VERTEX_PROGRAM)
        vp.setSource(customCasterMatVp)
        vp.setParameter("profiles", "vs_1_1 arbvp1")
        vp.setParameter("entry_point", "customColourVp")
        vp.load()

        fp = ogre.HighLevelGpuProgramManager.getSingleton().createProgram(
              "CustomColourFp",
              ogre.ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME,
              "cg", 
              ogre.GPT_FRAGMENT_PROGRAM)
        fp.setSource(customCasterMatFp)
        fp.setParameter("profiles", "ps_1_1 arbfp1")
        fp.setParameter("entry_point", "customColourFp")
        fp.load()
      
        mat = ogre.MaterialManager.getSingleton().create(
               "CustomColour",
               ogre.ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME)
        p = mat.getTechnique(0).getPass(0)
        p.setVertexProgram("CustomColourVp")
        p.getVertexProgramParameters().setNamedAutoConstant("worldViewProj",
           ogre.GpuProgramParameters.ACT_WORLDVIEWPROJ_MATRIX)
        p.setFragmentProgram("CustomColourFp") 
        colours  = [0.2,0.2,0.2,0.2 ]

        ## Python vs C++ difference-- we use ctypes buffers
        storageclass = ctypes.c_float * (1*4)
        colours=storageclass(1.1)
        ctypes.memset ( colours , 0, 1*4 )
        colours[0] = 0.35
        colours[1] = 0.38
        colours[2] = 0.16
        colours[3] = 0.2
        p.getFragmentProgramParameters().setNamedConstantFloat("MyColour", ctypes.addressof(colours), 1)

        #p.getFragmentProgramParameters().setNamedConstant("MyColour", ogre.Vector4(0.2,0.2,0.2,0.2))


    def update(self):
        pass

...
        self.customShaders = []
...
        s = CustomShader4()
        self.customShaders.append(s)
        ent = sceneManager.createEntity( "robot", "robot.mesh" )
        ent.setMaterialName("CustomColour")
        node = sceneManager.getRootSceneNode().createChildSceneNode()
        node.attachObject( ent )

amartin · Post by **amartin** » Tue Sep 24, 2013 12:52 pm

bullale wrote: Based on my recent experience learning msvc++, mingw, python, ogre, and python-ogre: When releasing something open-source, please do not bother with automatic build scripts. You'll have several types of people downloading, including those that just want sample code, those that just want the binaries to try it out, and those that are just starting out (like me). The former two types of people only need the project source files and the binaries. People like me do not benefit from automatic build scripts, especially since those scripts tend to be system-specific and they age quickly. Instead, consider providing instructions on where to find the necessary headers and compiled libraries and what needs to be included and linked. If you want to host the necessary SDK elements because you are worried that particular version might not be available to download in the future then that's good, but not at the expense of instructions. This kind of documentation can be tedious but I can write most of it if you want.

I've got build instructions, a dependency list and I have no intention right now of making a custom build script. The reason I want the fork available is that I am making modifications to Ogre in order to add features I need so it will no longer compile with the SDK or the main ogre source. I'm too early in my project for a binary release to be usable and it's probably more useful if I push my changes to the oculus example than post mine at the moment.

bullale wrote: Unfortunately setNamedConstant does not allow inputs of type Ogre::Vector2. This alternative may work but I don't know how to do it in Python http://www.ogre3d.org/docs/api/html/cla ... d10cc2101e.

setNamedConstant supports Ogre::Vector2 just fine in 1.9.1 any code I post is copied directly from my running project where I have tested it first. pyogre on the other hand may not have support for it you can try using a vector 4 in that case and seeing if it is smart enough to just pass what it needs. using a vector4 instead seems to work fine for me but I can pass in Vector2s.

Most of the shader paramaters seem to be pretty static currently though I have no idea if they will stay that way. I'm just setting mine once when I create the camera and that seems to work fine. I have been tempted to write a config wizard for playing with the settings till they look right but for now I've other things to focus on.

Post by **Kojack** » Tue Sep 24, 2013 1:04 pm

bullale wrote: Why do you think it's necessary to update the IPD in real-time?

So we can have something like a slider or other controls so the user can adjust the settings in real time and see the change.

The problem is that ogre's compositors hide the material from you (clones it and removes the clone from the materialmanager so you can't find it), so any shader parameters can only be set once at the start, then never changed. There was no way to change them only when needed. The only way I found around that was to have a listener (think it was a viewport listener, can't remember now) which gets called every frame. I need to see if I can find a better way to trick the compositor system into doing what I need.

bullale · Post by **bullale** » Wed Sep 25, 2013 2:54 am

While this thread has the attention of a few people that are quite capable with Ogre, I would like to point you to a thread on mtbs3d.
http://www.mtbs3d.com/phpBB/viewtopic.p ... 659ee8e9e5 which links to a blog which links to this (very short) research paper: http://www.qwrt.de/pdf/Improved-Pre-War ... splays.pdf

Their goal is to decrease the blurriness caused by the barrel distortion and chromatic aberration correction. They compared the following techniques:

Bicubic texture interpolation in the pixel shader (instead of bilinear texture lookup).
Barrel-warping the scene (vertex-space).
Over-sampling.

They also mentioned some chromatic aberration correction techniques that I don't understand.

Barrel-warping the scene seems to work the best but it requires the ability to specify how the scene is sampled (i.e., not using a typical rectilinear grid). They describe this as warping the rays that are cast from the camera to the scene. Is this is something that could be implemented in Ogre? One thing that wasn't clear to me was whether or not this warping had to be done separately for each color channel. If so, it may be too slow.

*Edit* The mtbs3d thread has a link to the following which is definitely worth a look and has some sample code for barrel warping in the vertex shader: http://github.prideout.net/barrel-distortion/

Ogre Forums

Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre

Re: Oculus Rift in Ogre