[2.2]Porting my engine to 2.2

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


xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

1. ow.. I know that, stupid me

its working now thank you!!
at first I was getting that glitchy image when using msaa, but I revisited what you told me:
I suggest you create an explicit MSAA texture, and either directly resolve to the render window, or have your shader read the msaa content directly:
did that and its working!

if anyone is interested, I am resolving the texture in my finalProcessingMat pass quad shader like this:

Code: Select all

uniform sampler2DMS renderSampler;

vec4 textureMultisample(in sampler2DMS sampler, in vec2 texc)
{
   ivec2 ipos = ivec2(floor(vec2(textureSize(sampler)) * texc));
   vec4 color = vec4(0.0);
   for(int i = 0; i < 4; ++i)
   {
       color += texelFetch(sampler, ipos, i);
   }
   color /= 4.0;
   return color;
}

void main()
{
  outColour = textureMultisample( renderSampler, inPs.uv0 );
the next problem:
both eyes renders the same camera :S
I am defining which camera to use on the passes as always..
mPassSceneDef->mCameraName = "CameraLeft";

.......

mPassSceneDefRight->mCameraName = "CameraRight";
Last edited by xrgo on Tue Jan 15, 2019 10:57 pm, edited 1 time in total.
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: [2.2]Porting my engine to 2.2

Post by dark_sylinc »

There haven't been major changes to camera/pass handling, so that bug is odd.

I suggest placing a breakpoint inside CompositorPassScene::execute somewhere around:

Code: Select all

viewport->_updateCullPhase01( mCullCamera, usedLodCamera,
and see if the cameras are the same ptr (check the pass scene definition, check the constructor). If they're not, see why they have the same transform (data breakpoints are your friend).
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

the Cull Camera is the problem, if I comment its usage:

Code: Select all

            mPassSceneDef->mCullCameraName = "CameraCull";
.....
                mPassSceneDefRight->mCullCameraName = "CameraCull";
                mPassSceneDefRight->mReuseCullData = true;
works, but I want that feature... I'll keep looking
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: [2.2]Porting my engine to 2.2

Post by dark_sylinc »

Fixed.

I remembered this.

Due to a problem, Overlays were causing issues because they can make API calls that should not be allowed (legacy stuff... ugh). In particular fireRenderQueueStarted must be called before RenderQueue::renderPassPrepare and I was thus forced to move Hlms::preparePassHash (disguised under RenderQueue::renderPassPrepare) to be called much earlier, inside SceneManager::_cullPhase01.

HlmsPbs::preparePassHash would retrieve the current working camera, which was the cull camera and not the rendering camera.

2.1 would not see this bug because the working camera would be set to the right pointer in _updateRenderPhase02 and afterwards preparePassHash would be called.

Thanks for the info.

Cheers
Matias

PS. Because I have no sample to test, I can't be 100% certain my fix worked flawlessly (i.e. maybe there are wrong side effects from setting mCameraInProgress to the render camera instead of the cull one, but I don't think so).
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

I am getting a crash here:

Image

cachedGrid is null so I checked and is indeed entering getCachedGridFor, but its entering with "CameraLeft" as argument, and inside there's this if:

Code: Select all

 
            if( itor->camera == camera &&
                itor->reflection == camera->isReflected() &&
                Math::Abs(itor->aspectRatio - camera->getAspectRatio()) < 1e-6f &&
                itor->visibilityMask == visibilityMask &&
                itor->shadowNode == mSceneManager->getCurrentShadowNode() )

and itor comes from mCachedGrid which at this point has only one item which has the camera "CameraCull", so it fails at the first part of the if (itor->camera == camera) and never fills outCachedGrid

shouldn't be the other getCachedGridFor be called? the one that if not entry found, it creates one?

thanks!
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: [2.2]Porting my engine to 2.2

Post by dark_sylinc »

xrgo wrote: Wed Jan 16, 2019 3:02 am shouldn't be the other getCachedGridFor be called? the one that if not entry found, it creates one?
No, at that point in time it is already too late. There should be a cached entry.

This crash is happening because

Code: Select all

if( mIlluminationStage != IRS_RENDER_TO_TEXTURE && mForwardPlusImpl )
    mForwardPlusImpl->collectLights( cullCamera );
Is generating a cache with 'cullCamera', but inside HlmsPbs we're calling forwardPlus->getGridBuffer( camera ) with 'renderCamera' (renderCamera comes from SceneManager->getCameraInProgress), so it tries to fetch a cached entry with the wrong key.

There's two cameras that are relevant: renderCamera (2x: left & right eye) and cullCamera (the camera that encloses both eyes for culling). We're generating the grid for one, and retrieving the grid with the other one. That's a bug. Either we use renderCamera on both, or we use cullCamera on both.

I think the correct solution would be to have the call forwardPlus->getGridBuffer( cullCamera ) and thus SceneManager would have to cache the cull camera too (not just the render camera) so HlmsPbs can retrieve it.
But I may be wrong and if if that's the case then we should be calling mForwardPlusImpl->collectLights( renderCamera ); instead.
Try both and see which one looks correct. It is late here, and you're the one who has a repro case :)

Note that mForwardPlusImpl->collectLights is twice in OgreSceneManager.cpp, you would have to modify both.

Cheers
Matias
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

Still stuck, I am really sorry for not being able to solve it myself
I tried this:
dark_sylinc wrote: Wed Jan 16, 2019 5:04 am I think the correct solution would be to have the call forwardPlus->getGridBuffer( cullCamera ) and thus SceneManager would have to cache the cull camera too (not just the render camera) so HlmsPbs can retrieve it.
and I had already tried this before seeing your post
dark_sylinc wrote: Wed Jan 16, 2019 5:04 am But I may be wrong and if if that's the case then we should be calling mForwardPlusImpl->collectLights( renderCamera ); instead.
and in both cases crashes in similar way...

so! I made a repro =) (replace StereoRendering.cpp)


dark_sylinc wrote: Wed Jan 16, 2019 5:04 am I think the correct solution would be to have the call forwardPlus->getGridBuffer( cullCamera ) and thus SceneManager would have to cache the cull camera too (not just the render camera) so HlmsPbs can retrieve it.
if I am using a cullCamera, wouldn't be better just to cache the grid buffer JUST for the cull camera, and the reusing it for the camera that reuseCullData? (performance optimization)

edit: wow, didn't know pastebin looks this good in the forums

edit2: btw with your las commit at least I see the correct image on each eye.... if I disable forwardPlus so it doesn't crash
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.2]Porting my engine to 2.2

Post by al2950 »

Hi Due partly to this post, partly to reverse depth buffers and partly because of some gentle prodding from Rujialiu :lol: , I have spent the last 2 days updating my production engine to 2.2.

It has mostly gone very well, and the new texture system is very nice to work with, plus I believe have got some free performance boosts, which is always nice.

Now, I have a solution that will fix Xrgo's issues, just coding and testing now. For Dark_sylinc info I am going to update SceneManager::getCameraInProgress to return a struct with the 3 different cameras in it (ie Rendering, culling and lod cameras).(Oh and rename function)

I will also fix another thing that has been annoying me for VR, and that is the camera for shadows uses the rendering camera which means (thanks to drak_sylinc making shadow camera frustrums super tight) when rendering right eye, some shadows get clipped. So shadow cameras should actually use the culling camera for reference, not the rendering camera
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

yeah! welcome to the 2.2 world, I am also happy with the porting, also the shader refactor made customization easier, for most things just is now a matter of @undefpiece() and defining it again with the modifications

and thank you sooo much for the solution and improvement! can't wait!
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.2]Porting my engine to 2.2

Post by al2950 »

Testing done all seems to work, ill sort out a PR V. sooon

@dark_sylinc
Compute shaders have been disabled in Dx11 by this commit. Was this an accidental commit or is there something else going on?
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: [2.2]Porting my engine to 2.2

Post by dark_sylinc »

Whoa! No, that was an accident!!!
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.2]Porting my engine to 2.2

Post by al2950 »

Pull request submitted

Currently 3 fixes
- CMAKE SDK install fix for HLMS components
- Fix crash caused by hlmsPbs using different camera than sceneManager with regard to forward+
- Fix shadow culling issue when re-using shadow cameras but using different rendering camera
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: [2.2]Porting my engine to 2.2

Post by dark_sylinc »

Your PR looks great.

I will wait if you're still testing it. Let me know when you think it's good to go.

Regarding the "const Camera" changes, normally I like const correctness, it's just that I've been avoiding dealing what to do when it comes to the Camera class because it feels a bit of a lie, given how many mutable variables it has inside.
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.2]Porting my engine to 2.2

Post by al2950 »

dark_sylinc wrote: Wed Jan 16, 2019 6:47 pm I will wait if you're still testing it. Let me know when you think it's good to go.
I managed to test most things. But my PC hard crashed before I got a chance to test the following:
- VR MSAA
- Reverse depth buffers (need a bit more work on my engine before I can test this)
- Reflection probes
- decals

As I was at work when my PC crashed, I decided to take that as an opportunity to finish work for the day!
dark_sylinc wrote: Wed Jan 16, 2019 6:47 pm Regarding the "const Camera" changes, normally I like const correctness, it's just that I've been avoiding dealing what to do when it comes to the Camera class because it feels a bit of a lie, given how many mutable variables it has inside.
Yeah, I can appreciate that! One way or another I had to change the const'ness of some functions, or add a bunch of const_casts which always feels wrong. So went with the approach that felt more correct :)

@Xrgo
If you could pull and test my branch that would be very usefull
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

al2950 wrote: Wed Jan 16, 2019 7:54 pm @Xrgo
If you could pull and test my branch that would be very usefull
thanks for the link, I had to fix line 1153 and 1978 in OgreHlmsPbs.cpp, because I use planar reflections (fix are quite obvious), but apart from that it seems to be working!! thanks!!!!!
al2950 wrote: Wed Jan 16, 2019 7:54 pm - VR MSAA
- Reverse depth buffers (need a bit more work on my engine before I can test this)
- Reflection probes
- decals
I have MSAA Working and reflection probes also seems to work fine, I tested up to 3, but in open spaces, I have yet to test in rooms to see if they fit nicely =D

I am currently having some trouble with terra, but most is shader related which I can solve and make a PR later
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.2]Porting my engine to 2.2

Post by al2950 »

Thanks. I have updated the PR with reflection planes working

@dark_sylinc
There was a crash in Dx11 only that took a bit of digging, could you please check my fix is sensible
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.2]Porting my engine to 2.2

Post by al2950 »

All tested my end, please merge PR when you have a chance :D
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

is posible that the last changes broke point light shadows? I am getting broken shadows (mostly shadowed, some parts fine) on big objects (walls, floor, ceiling) but looking good on small objects, it was working 2 days ago, I'll keep looking
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.2]Porting my engine to 2.2

Post by al2950 »

xrgo wrote: Thu Jan 17, 2019 7:46 pm is posible that the last changes broke point light shadows? I am getting broken shadows (mostly shadowed, some parts fine) on big objects (walls, floor, ceiling) but looking good on small objects, it was working 2 days ago, I'll keep looking
In VR, normal or both?
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

al2950 wrote: Thu Jan 17, 2019 7:49 pm In VR, normal or both?
checked normal for now, but I am guessing both
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: [2.2]Porting my engine to 2.2

Post by al2950 »

Dont have point light shadows setup in my engine, but tried to re-create your issue in an Ogre sample, but all looks fine. The only thing I noticed is the ESM filtering does not work with point light shadows, but I believe that might be by design (Without the last fix ESM shadow would crash in Dx11)
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: [2.2]Porting my engine to 2.2

Post by dark_sylinc »

ESM is supposed to work with point shadows. I'll have to take a look.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

Ok I know were the problem is... the thickness, my walls and floor are just one faced polygons, if I extrude them the problem is gone, but I dont want to extrude them so I guess I have to play with biasing or find why it was working before (same settings, same scene). Going to check if was the reverse depth feature that broke it..
btw, thanks for the report al2950

edit: that made me think I have to also check setShadowMappingUseBackFaces
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: [2.2]Porting my engine to 2.2

Post by dark_sylinc »

Yes, it's most likely caused by Reverse Depth.

Could be:
1. Bad math (my mistake)
2. A sideeffect of the calculations (I doubt it)
3. The depth bias calculation is wrong (i.e. wrong direction) or too different, like in a different space. (my mistake, also this is most likely the reason)
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.2]Porting my engine to 2.2

Post by xrgo »

I can confirm that before the reverse depth its working fine
Post Reply