Few serious questions for Ogre-Next, moving Stunt Rally

[Crystal Hammer]

Can I in one of my RTT top views, force all meshes to render with cull_none? And make them black?
If not, does it seriously mean I need to create all objects twice, set datablock for them as the same new material with cull_none black, diffuse etc.

[dark_sylinc]

Thanks.
Yes I did check out PFX2 branch months ago, and I'm still waiting for merge to master.

Done

into 3.0 since I'm not even using master

Btw it sounds like what's preventing you migrating to master are the Hlms signature changes (the tid parameter).

Make sure to read all of Migrating 3.0 to 4.0 (fair warning: 4.0 aka master could change in the future) but I wanted to specifically bring attention to Multithreaded Shader Compilation because we specifically have the CMake option OGRE_CONFIG_THREAD_PROVIDER to aid in porting.

Can I in one of my RTT top views, force all meshes to render with cull_none? And make them black?
If not, does it seriously mean I need to create all objects twice, set datablock for them as the same new material with cull_none black, diffuse etc.

We have no such functionality but it could be "easily" added to OgreNext:

OgreNext has "StrongMacroblockBits" where internally OgreNext swaps the HlmsMacroblock for another one with a different setting based on SceneManager, RenderTarget or RenderSystem settings.

You definitely want to look at InvertVertexWinding because it does almost what you want to do: it flips the culling mode (e.g. clockwise becomes counterclockwise and viceversa). You'll want to add a new flag so that you can remove culling. And a way for you to set you want this flag, externally (i.e. SceneManager + CompositorPass? SceneManager only?)

Internally an HlmsMacroblock is generated and a new PSO will be compiled, but it is still faster than swapping datablocks on the fly (which is even more expensive).

[Crystal Hammer]

Right, thanks. Well maybe someday. I still have many critical things to fix before.

Bit random now, what's up with this, assert in debug?

Code: Select all

Ogre/ogre-next/OgreMain/src/OgreParticle.cpp:46: void Ogre::Particle::setDimensions(Ogre::Real, Ogre::Real): Assertion width >= 0 && height >= 0 && "Particle dimensions can not be negative"' failed.

Why is this a problem at all, and can't be handled by Ogre?
Is it bad if zero triangle size, why negative is bad, can't it just flip?
If not by Ogre then, how am I supposed to know when it happens? If time to live is random range then negative scaler will hit it sometimes or not depending on random. Do I need to take the worst case then? So it won't scale to 0 for longest time particles, but will nearly reach 0 for shortest?

[dark_sylinc]

Mmmm... this looks like an assert that is too strong.

I can see that a problem would be that if every particle has negative size, ParticleSystem::_updateBounds and mOwnDimensions = true, it may end up with an invalid AABB and cause an assert further on.

But on the other hand this should be relatively easy to fix (just abs() the dimensions).

However on most cases, a negative size particle is an undesired outcome.

If time to live is random range then negative scaler will hit it sometimes or not depending on random. Do I need to take the worst case then? So it won't scale to 0 for longest time particles, but will nearly reach 0 for shortest?

Wouldn't it make more sense for the ScaleAffector to clamp to 0 by default? This will prevent the assert and what it looks like an undesired outcome anyway?

Also btw in case you're interested, notice I added ScaleAffector::setMultiplyMode which has a much saner behavior (multiply_mode in scripts, I just noticed the scripts keyword was missing from PFX1 so I just pushed it) for most cases.

[Crystal Hammer]

Argh damn it.
Ever since I added Refractions (and split just 1 to now 3 rendering passes for them), I'm struggling in getting everything else back to work.

• (fixed) I can't see boost particles, while others are there.
• Glass pipes are just drawn always over water instead of being partly underwater. Car glass is not refracted.
• And now I checked split screen (critical).
  This is before:
  18_19-26-30s.jpg
  and this is now:
  18_19-28-23.jpg

• I'm also having this weird depth buffer garbage issue.
  Once in wireframe (if I toggle it), some squares not getting back to normal until quit (I guess this is my smooth alpha from depth code with that inverse matrix, but why).
  And I can't really get water surface (2nd mesh) made because it also shows this. I had 2nd mesh for water top, viewed from inside. Can't do it now, it will mess up water view from top to this, even if it's culled.
  18_17-11-34`c.jpg

Looks like .compositor is now my new worst enemy . HLMS seems kind of nice in comparison.
Any help? How do I even deal with these issues (except one at a time, and with lots of patience)?

[Crystal Hammer]

• Terrain edit cursor isn't just a green circle, but filled with random holes (in like 16x16, 8x8, etc. (depth buffer) garbage patterns).
  Also visible on Hud stuff, that minimap on right and brush preview on left.

  17_11-30-47`.jpg

• Ah and I think I lost anti aliasing, IDK when, I see pixels not smooth lines (even with FSAA=8).

• Also IDK what to do if I have one fluid inside other fluid, they freak out and blink, with random order even if not refracting I think. I did separate render queues, got better.

I can give you more info on how to check for these issues in SR3, but I really doubt I'd be able to replicate in my terrain demo or ogre samples.
My main compositor file is here. It'd be great if you could look and check, if there aren't any obvious errors inside.
And I thought about getting it all into only C++, since that file is way too big, repeated, has constants from my .h file, and it doesn't even have SSAO nor HDR (yet).

[Crystal Hammer]

I made a video about that depth buffer garbage wireframe from terrain, water, sky etc.
With my shader code using depth buffer for water.
Water is only okay with no macro and blendblocks in json.
It is very bizzare to me, any idea why it happens?

[Crystal Hammer]

So I need to drop .compositor file and create all that in cpp right?
Pity almost all OgreNext samples have all in .compositor then .
Thing is I have now Refractions as option and this needs 2 compositor versions, I believe I will have SSAO soon (finally ), this means 4 versions, let's say I will add HDR someday, that's 8 compositor versions (each combination is another x 2 here). In cpp that will be just some added if here and there I suppose.
I'm adding 2 things in cpp already: Gui pass and shadows, which means knowing magic numbers for target and pass where to add etc.

And I'm not sure really if split screen needs something custom in .compositor?
I have 1 to 6 player views, with toggable vert/horiz split in some cases. This changes dimensions, but I'm using just one .compositor with target_width target_height etc.
I'm not sure because it got messed up completely now, since I added refractions, it had 1 pass w/o and worked. And now each pass seems to have wrong render sizes or such (shown on screen above.
And I got few RTTs in editor, one with terrain and (refract) water for minimap, and camera preview (same as main view just 1k x 1k) also with water etc. Which simply mean I need to duplicate stuff in .compositor.

[Crystal Hammer]

Ok this is far less important, but maybe easy to answer.
I started with SSAO now.
I got few issues with it:

• I have SSAO rectangles on my sky dome, which is just a mesh. Obviously sky mesh should not be SSAO-ed. How to exclude sky?
• SSAO is still visible in fog, it should fade out. Probably same under water. I guess I need to add my fog code to SSAO shader?
• If I turn on car front lights, then it should lit SSAO too. I.e. I should actually have completely white SSAO buffer there because of my lights. E.g. that grass in front should be white.
• Anything possible to control how much grass (alpha test), or glass (transparent) will make SSAO lighter? It should be less dark than from opaque objects.
• Is it possible and not difficult to have 2nd SSAO added, with diffrent radius and scale? Probably needs more stuff in compositor.

Here is a screen with all these:

24_10-26-20`.jpg

Can I fix these (mainly first 2 bold), how?
I see in SSAO sample there is scene rendered first as RTT, for SSAO and later used for normal view too.
I suspect I would have to render them separately right? More GPU needed but probably no other way to fix above issues and pick what goes into SSAO and what not?

BTW can we have a 400KB attachment limit for screenshots on forum, 256 is never enough for complex screen in full hd. Even resized to 1280x800 barely fits that size. No, other sites are meh, they never keep images long.

[Lax]

Cool that you are working on SSAO. I gave it up. I have tried to transform the compositor code for SSAO in C++ but its getting to complex trying to unify all compositor features like:

• Hdr
• Screenspace reflection
• Splittscreen
• Distortion
• Postprocessing (Blur effects, black&white, etc.)

The compositor system is really powerful and nice implemented, but for extentions really really hard suitable.
I already thought, about using another architecture, but its to complex.

[Crystal Hammer]

I see. Right, it is getting complex with compositor combinations.
I saw you did all in C++. I wish I started it earlier so too.
I don't use screenspace reflection, don't like it. I have a dynamic cubemap for main vehicle and other stuff (even metal terrain in one scenery) and planar reflections for all reflecting water (fluids). They both need Fps, and can drop it fast. I usually render just 1 or 2 cube faces at once (so cube reflect updates slower) and I usually reduce to have only 1 or 2 reflecting fluids on scene, especially when there are lots of trees.

Will see if I manage to convert SSAO and use it with recently added fluid refractions too.
Pity samples like SSAO and HDR are in .compositor not C++. But it seems they are just different languages for same thing.
Yeah, I can hardly get what is in HDR. No idea if I try to convert or add it too. I wonder if I could get only bloom from it.

[Lax]

ah ok, good to know.

I think for your car driving scenario using .compositor files seems ok.
I needed C++ because I'm creating a Scene Editor in which the user may change parameters/features of compositors on the fly.

Yeah, I can hardly get what is in HDR. No idea if I try to convert or add it too.

You could orientate on my code. But the code is currently a mess, because a lot of experiments with SSAO and splitscreen.

[Crystal Hammer]

@Lax thanks.
I found your code for SSAO here: https://github.com/Laxx18/NOWA-Engine/b ... .cpp#L1296
It will be helpful when I get back to converting my .compositor to .cpp. But this is for later.

@dark_sylinc
Ok. I think it's time for a summary of my issues, if you had any time to look at them or answer my questions.

• So the compositor issue and splitscreen is already answered in another topic at end of post viewtopic.php?p=556543#p556543, I will try this later.
• depth buffer garbage / wireframe
  Started in second half of post here (screen is there): viewtopic.php?p=556432#p556432
  and mentioned also in later 2 posts
  with video of the problem.
  My main question is: why it happens if I put any of this in my material:

  Code: Select all

  "macroblock" : "Macroblock_2",
  "blendblock" : "Blendblock_0",

  If I leave my "Water_blue" in fluid.material.json without any macroblock or blendblock (like I forgot them ) which I assume uses defaults then water is rendered fine.
  Even if it is related to my shader code that does that inverse and depth buffer use, I see no reason why it would behave like above and only render water on wireframe lines .
• (low priority) a few questions regarding SSAO posted here: viewtopic.php?p=556452#p556452

[dark_sylinc]

I have SSAO rectangles on my sky dome, which is just a mesh. Obviously sky mesh should not be SSAO-ed. How to exclude sky?

You could apply SSAO before rendering the sky.
But I think a more sensible solution (in many ways) is to customize the sky dome's vertex shader so that the depth is always the same value and farthest aways:

Code: Select all

@property( hlms_no_reverse_depth )
    outVs_Position.z = outVs_Position.w - 1e-6f; // Do not set it to exactly .w or else some pixels may have holes due to how GPUs interpolate z / w, causing w / w > 1 for some pixels.
@else
    outVs_Position.z = 0.0f;
@end

The benefits of doing this extend beyond SSAO, because every effect that relies on the depth buffer would sooner or later be affected by the same problem (because otherwise the sky isn't "infinitely far away" but rather it's just big giant bowl hovering over the camera).

• depth buffer garbage / wireframe
  Started in second half of post here (screen is there): viewtopic.php?p=556432#p556432
  and mentioned also in later 2 posts
  with video of the problem.
  My main question is: why it happens if I put any of this in my material:

  Code: Select all

  "macroblock" : "Macroblock_2",
  "blendblock" : "Blendblock_0",

I can't see the definition of "Macroblock_2" (which is... kind of important ) but one absolute constraint you must respect is that depth write must be off.
This is because planar refractions is sampling from the depth buffer. If you try to write into it at the same time, you get GPU-specific glitches.

If you really want depth writes enabled, one solution would have to copy/clone the depth buffer's contents, so that the depth buffer that refractions are sampling from is different from the depth buffer being written to.
The Refraction sample does this only when using MSAA (since it must resolve the depth buffer). However it'd be possible to use texture_copy pass to simply copy the depth buffer into another depth buffer.

Code: Select all

compositor_node RefractionsNonMsaaDepthCopy
{
	in 0 gBufferDepthBuffer

texture copiedDepthBuffer target_width target_height PFG_R32_FLOAT depth_pool 0

//We need to clone the depth buffer so refractions can use depth write.
target copiedDepthBuffer
{
	pass texture_copy
	{
		in	gBufferDepthBuffer
		out copiedDepthBuffer
		profiling_id "Copy / Clone depth buffer for Refractions"
	}
}

out 0 copiedDepthBuffer
}

// Set it up the same way Refraction samples does with RefractionsMsaaDepthResolve:
workspace RefractionsWorkspace
{
	connect	RefractionsRenderingNode 1 RefractionsNonMsaaDepthCopy 0
	connect	RefractionsRenderingNode 0 1 RefractionsRefractionsNode 0 1
	connect	RefractionsNonMsaaDepthCopy 0 RefractionsRefractionsNode 2
	connect_output RefractionsRefractionsNode 3
}

It's possible the problem is elsewhere, but due to this potential for race conditions (if using the same depth buffer), refractions are very sensitive to macroblock settings.

You can start from is to open in RenderDoc and compare good vs bad version and see the difference in settings here:

[Lax]

@Lax thanks.
I found your code for SSAO here: https://github.com/Laxx18/NOWA-Engine/b ... .cpp#L1296
It will be helpful when I get back to converting my .compositor to .cpp. But this is for later.

@Crystal Hammer You're welcome, but keep in mind, that I never got SSAO working and never found out why, but maybe you can build on my snippets and find out, what I had wrong

Best Regards
Lax

[Crystal Hammer]

Okay thanks.

Yes this was the issue, I now used a copy from sample Refractions .compositor that has:
RefractionsRenderingNode, RefractionsMsaaDepthResolve and RefractionsRefractionsNode
and with this setup SR3 works well.
I skipped it since I thought it is only needed for FSAA, but turns out it disables FSAA itself, and doesn't allow depth write by refracted objects, which I need for water etc.
It seems the same as that you suggested and it somehow works for no FSAA too.

I am now rewriting .compositor into cpp code. Have to say comments in ogre-next headers are very helpful. I almost rewrote the setup too, but now I have this crash:

Code: Select all

An exception has occured: OGRE EXCEPTION(2:InvalidParametersException): RenderPassDescriptor depth attachment 'depthBuffer[Value 0x00000001]' is not a depth format! in RenderPassDescriptor::entriesModified at /home/ch/_sr/Ogre/ogre-next/OgreMain/src/OgreRenderPassDescriptor.cpp (line 257)

I'm unsure how to translate some parts. I probably did some rtv depth buffer config(s) wrong.
How do I translate this rtv part to cpp from here?

Code: Select all

compositor_node RefractionsRefractionsNode
{
	in 0 rtt_first
	in 1 depthBuffer
	in 2 depthBufferNoMsaa
	in 3 rt_renderwindow

	// rtt_first & rtt_final MUST share the same depth buffer.
	// Depth pools already take care of that. But just to be sure, we make it explicit
	texture rtt_final	target_width target_height target_format msaa_auto

	rtv rtt_final
	{
		depth_stencil	depthBuffer
	}

or this depth_pool 0 to cpp:

Code: Select all

texture copiedDepthBuffer target_width target_height PFG_R32_FLOAT depth_pool 0

And is this really PFG_R32_FLOAT not D32, so it's a color texture after this Ogre/Resolve/1xFP32_Subsample0 ?
I found some help in Ogre/ogre-next/OgreMain/src/OgreScriptTranslator.cpp but it's really long and complex. Also in WorkspaceComponents.cpp from Lax's repo.

My wip code went here:
https://github.com/stuntrally/stuntrall ... 0bb00a61da
first rtv is here, IDK if okay, early in AppGui::CreateCompositor():
https://github.com/stuntrally/stuntrall ... b42fff9R92

Wow, I think I have the same issue as Lax has with SSAO here:
viewtopic.php?p=553973#p553973

[Crystal Hammer]

Okay I fixed the crashes.

So I had to use format for depthbuffer, not depthBufferFormat, seems ignored:

Code: Select all

	auto* td = nd->addTextureDefinition( "depthBuffer" );
	//td->depthBufferFormat = PFG_D32_FLOAT;
	td->format = PFG_D32_FLOAT;
	td->fsaa = "";  // auto
	td->textureFlags = TextureFlags::RenderToTexture;  // no discard

and rtv is done so:

Code: Select all

	auto* rtv = nd->addRenderTextureView( "rtt_first" );  // rtv
	RenderTargetViewEntry at;
	at.textureName = "rtt_first";
	rtv->colourAttachments.push_back(at);
	rtv->depthAttachment.textureName = "depthBuffer";
	rtv->depthBufferId = 0;  // depth_pool 0

More in commit
https://github.com/stuntrally/stuntrall ... e5f714b835

I see water but it has wrong / no depth, and depth shading is dark and I have no soft border.

I checked it in RenderDoc and after "Resolve Depth Buffer" I see only 0.0 values everywhere, not those like 0.001 etc.
I'm comparing bad vs good there and I saw that bad has this extra step:
glInvalidateFramebuffer(Framebuffer 1709)
while good didn't have it.

I see this is only done here: /Ogre/ogre-next/RenderSystems/GL3Plus/src/OgreGL3PlusRenderPassDescriptor.cpp

Code: Select all

        if( numAttachments > 0 && hasArbInvalidateSubdata )
        {
            OCGE( glInvalidateFramebuffer( invalidateTarget, numAttachments, attachments ) );
        }

Seems to be triggered by store of color attachment. Hmm.
How to set it to get rid of it?

[Crystal Hammer]

Woah. I fixed it.
Man I learned a lot BTW. I now consider myself someone who knows compositor .. that is OFC until I post again with some issue, probably SplitScreen or SSAO .

Okay so here is what I needed, for this step:

Code: Select all

compositor_node RefractionsMsaaDepthResolve
{
	in 0 gBufferDB

	texture resolvedDB target_width target_height PFG_R32_FLOAT depth_pool 0

	// We need to "downsample/resolve" mrtDepthBuffer because the impact
	// performance on Refractions is gigantic.
	target resolvedDB
	{
		pass render_quad
		{
			load { all dont_care }
			material Ogre/Resolve/1xFP32_Subsample0
			input 0 gBufferDB

			profiling_id "Resolve Depth Buffer"
		}
	}

	out 0 resolvedDB
}

so now in .cpp:

Code: Select all

		auto* nd = mgr->addNodeDefinition("DepthResolve");
		
		nd->addTextureSourceName("gBufferDB", 0, TextureDefinitionBase::TEXTURE_INPUT);

		nd->setNumLocalTextureDefinitions(1);  //* textures
		{
			auto* td = nd->addTextureDefinition( "resolvedDB" );
			td->format = PFG_R32_FLOAT;  // D32 -> R32
			td->fsaa = 1;  // off

			auto* rtv = nd->addRenderTextureView( "resolvedDB" );  // rtv
			RenderTargetViewEntry at;
			at.textureName = "resolvedDB";
			rtv->colourAttachments.push_back(at);
		}
		nd->mCustomIdentifier = "2-resolve";

		nd->setNumTargetPass(1);  //* targets
		td = nd->addTargetPass( "resolvedDB" );
		td->setNumPasses(1);  //* passes
		{
			auto* pq = static_cast<CompositorPassQuadDef*>(td->addPass(PASS_QUAD));
			pq->setAllLoadActions( LoadAction::DontCare );
			pq->setAllStoreActions( StoreAction::DontCare );
			pq->mStoreActionColour[0] = StoreAction::StoreOrResolve;

			pq->mMaterialName = "Ogre/Resolve/1xFP32_Subsample0";
			pq->addQuadTextureSource( 0, "gBufferDB" );  // input
			pq->mProfilingId = "Resolve Depth Buffer";
		}
		nd->setNumOutputChannels(1);  //  out
		nd->mapOutputChannel(0, "resolvedDB");

have to define rtv in cpp, even if not in .compositor, and this R32 is color not depth.

So honestly .compositor is bad, it's a trap, I'd rather have everything in .cpp now, where I can use my const defines from .h, graphics settings, use if blocks, go to comments in ogre headers, etc.
Maybe .compositor is easy for start and only for samples or simple demos, where user can't even change one graphics option.

[Crystal Hammer]

Aah so @dark_sylinc I'm reading your suggestion again:
viewtopic.php?p=556543#p556543

Strong Suggestion for everyone: Your use cases are getting complex. Instead of doing split screen directly on the final target, just render every player into its own TextureGpu.
Then use a custom pixel shader that composites all players into the final target and then apply shared UI on top.

Hmm. Is that the only way? I'm a bit lost. Could you give me some draft of what I should do the new way?
Do I need to create TextureGpu's on my own in cpp? And then a custom shader that takes them all as inputs and it can only sample those and put them with correct offsets on final (full) screen?
Do I need then like 6 or 8 custom shaders for all of my split screen configurations? Shown there:
https://github.com/stuntrally/stuntrall ... im.cpp#L39

So let's say I have 2 views/players, vertical split screen (just like VR) on 1920x1200.
I should have 2 RTTs: 960x1200, I could do that after addTextureDefinition( by widthFactor = 0.5f; right?

But I can't later just use a PASS_QUAD for each, and tell it to copy 1st view RTT 960x1200 with offset 0,0 and then 2nd view RTT with offset 960,0, onto the final 1920x1200 screen, right? That'd be easy, ugh..

For this I'd need a new custom shader, which would be in a material (that old v1 long syntax), and then something like this would use it?

Code: Select all

		pass render_quad
		{
			load { all dont_care }
			material SplitScreenCombine
			input 0 Screen1
			input 1 Screen2
			// more .. if needed

			profiling_id "Combine all player screens"
		}

Am I close?

Or should I just create views on final screen as minimap rectangles, like in my editor, heh.
I think split screen will now need a lot of work.

[Crystal Hammer]

Okay I did it (split screen with RTT for each view and combining in shader).
OFC I have to create a TextureGpu and then an RTT for it, like I did for editor RTTs, minimap etc.

Code: Select all

			TextureGpu* tex =0, *rtt =0;
			tex = texMgr->createTexture( "GTex" + si,
				GpuPageOutStrategy::SaveToSystemRam,
				TextureFlags::ManualTexture, TextureTypes::Type2D );
			
			tex->setResolution(
				mWindow->getWidth() / 2, mWindow->getHeight());
			tex->scheduleTransitionTo( GpuResidency::OnStorage );
			tex->setNumMipmaps(1);  // none

			tex->setPixelFormat( PFG_RGBA8_UNORM_SRGB );
			tex->scheduleTransitionTo( GpuResidency::Resident );

			auto flags = TextureFlags::RenderToTexture;
			rtt = texMgr->createTexture( "GRtt" + si,
				GpuPageOutStrategy::Discard, flags, TextureTypes::Type2D );
			rtt->copyParametersFrom( tex );
			rtt->scheduleTransitionTo( GpuResidency::Resident );
			rtt->_setDepthBufferDefaults( DepthBuffer::POOL_DEFAULT, false, PFG_D32_FLOAT );  //?

Then workspace isn't rendering to window but passing this rtt

Code: Select all

			//  external output to rtt
			CompositorChannelVec one(1);
			one[0] = rtt;

			const IdString wsName( str );
			CompositorWorkspace* w =
				mgr->addWorkspace( mSceneMgr, one,

Afther this I create another node, and workspace that has:
pass quad "combine", pass for Hud and pass for Gui (one, common for all player/splitscreen views).
And this "combine" is like so:

Code: Select all

				//  copy combine split views
				auto* pq = static_cast<CompositorPassQuadDef*>(td->addPass(PASS_QUAD));
				pq->setAllLoadActions( LoadAction::DontCare );

				pq->mMaterialName = "CombineSplitscreen";
				pq->addQuadTextureSource( 0, "rtt_FullIn1" );  // input
				pq->addQuadTextureSource( 1, "rtt_FullIn2" );
				pq->mProfilingId = "Combine to Window";

I made CombineSplitscreen by copying some other .material. So last part is below and I added another texture (this is for 2 views, vertical split screen:

Code: Select all

...
fragment_program CombineSplitscreen_ps_GLSL glsl
{
	source SplitScreen_ps.glsl
	{
		param_named tex1 int 0
		param_named tex2 int 1
	}
}
...
material CombineSplitscreen
{
	technique
	{
		pass
		{
			depth_check off
			depth_write off
			
			cull_hardware none

			vertex_program_ref Ogre/Compositor/Quad_vs
			{
			}

			fragment_program_ref CombineSplitscreen_ps
			{
			}

			texture_unit tex1
			{
				filtering none
				tex_address_mode clamp
			}
			texture_unit tex2
			{
				filtering none
				tex_address_mode clamp
			}
		}
	}
}

Lastly in SplitScreen_ps.glsl:

Code: Select all

#version ogre_glsl_ver_330

vulkan_layout( ogre_t0 ) uniform texture2D tex1;
vulkan_layout( ogre_t1 ) uniform texture2D tex2;

vulkan( layout( ogre_s0 ) uniform sampler sampler1 );
vulkan( layout( ogre_s1 ) uniform sampler sampler2 );

vulkan_layout( location = 0 )
in block
{
	vec2 uv0;
} inPs;

vulkan_layout( location = 0 )
out vec4 fragColour;

void main()
{
	vec2 uv = inPs.uv0, uv1 = uv, uv2 = uv;
	uv1.x *= 2.0;
	uv2.x -= 0.5;
	uv2.x *= 2.0;

	fragColour =
		uv.x < 0.5
		? texture( vkSampler2D( tex1, sampler1 ), uv1 )
		: texture( vkSampler2D( tex2, sampler2 ), uv2 );
}

[Crystal Hammer]

Allright I can't believe it, it's working. I updated code above.

So the questions remain.
I'm now doing splitscreen views comibining in shader, and in that old v1 syntax.
So this means I need at least:
SplitScreen.material, SplitScreen_ps.glsl, SplitScreen_ps.hlsl, SplitScreen_ps.metal (not really).
and this set multiplied by the number of views I have.
Which is 8, for 6 players max.

Seems nuts . Isn't there a better way, to not copy this all 8 times, changing only few places?
Internaly only ps code for uv reading, sampling and material textures change.

Also, what do I do if user resizes window? I need to recreate RTTs and all compositors.

I think doing scene nodes like for minimap rectangle in my editor, would need less effort, at least all would be in cpp only. But seems worse for GPU.

[Crystal Hammer]

Well I did it already with shaders.
But I wonder why is my refraction depth gone when rendered to RTT not to main window. Do I need anything special for depth buffer in this case?

[Lax]

Hi,

so you managed to get splitscreen working by not using the official approach, but tiling screen into texture chunks and passing the rendered screens of each split to the corresponding texture?

Boy, I'm afraid to do that. I have no idea, how that would work with shadows, quad passes, hdr, and what about performance...

Best Regards
Lax

[Crystal Hammer]

Hi Lax
So I managed to do Split Screen, the way dark_sylinc recommended, so by rendering each view into its own RTT (need to create TextureGpu manually and RTT on it too, if I get it right).
Then a new workspace that has a quad pass with shader gets those RTT textures as inputs and a custom _ps shader does sample them where they need to be on screen.

Since SR3 has 8 Split Screen view configurations for up to 6 players ther IS 8 shaders and 8 materials. Only glsl now, and possibly vulkan could work IDK, but that's my target.

This started working in SR3 in ths commit: https://github.com/stuntrally/stuntrall ... 8934be4554
previous could be useful too, I mean if that code is readable even.
But I still don't have Refractions depth in split screen fixed.

Yes there is additional copying, but I create those RTTs with needed view dimensions, so there is no scaling.
From what I understood, this is the way to do it. Since hardware doesn't even support viewport offsets (or could not).

Shadows work okay, I don't see any problem. HDR I think should too, you'd just add it to that workspace that does 1 view for RTT.
I didn't yet check performance much, versus the old way in previous SR 3.2. But from what I see it's not bad. I get 60 Fps mostly, and 45 Fps for 6 views on a test map.

But after seeing your big code so far, I undestand how much work that'd be. I basically started from Refractions sample with 3 taget setup and did add split screen. I still have it without RTTs for just 1 player view and editor.

And I'm now adding SSAO, I'm already seeing something just doesn't look right.
Any Idea if I really need target depthTextureCopy and material Ogre/Depth/DownscaleMax? It is target_width_scaled 0.5 BTW. But I'm now just using depthBufferNoMsaa from Refractions.

[Lax]

Hi,

I'm glad you made such an immens progress.
I think I will wait, (maybe forever), if dark_sylinc does find out, whats wrong the the split and quad in the other topic. I really have no nerves in re-creating the whole compositor system

For SSAO, I will also take a closer look, thanks for the information. I just stupidily tried to transform the compositor code to C++ code and maybe made some mistakes.

Best Regards
Lax