Few serious questions for Ogre-Next, moving Stunt Rally

[Crystal Hammer]

So I'm having trouble with getting buffers to SSAO.
I had it working in .compositor setup, with 1 compositor_node, just like in Sample_Tutorial_SSAO.
Since I moved to Refractions setup (like in Sample_Refractions) there are 3 compositor_nodes and they need to pass buffers to each other.
Is there anything special I need to do?
Or is this just a matter of workspace->connect, or also RTV setup and proper Load/Store configs?
I'm checking in RenderDoc and comparing with Sample_Tutorial_SSAO too, but since I while I think I'm going in circle. Any help or advice?

I also now integrated GI methods into SR3 from Tests/Voxelizer sample (why is it Test_Voxelizer not Sample_Voxelizer) so IFD and VCT.
Looks working, and visualizations also show.
But it's not compatible with Terra. I made a github issue.
Is it possible to support?
I am very curious if it could work like I wrote there, by creating just a terrain mesh mock for VCT voxelizer and then removing it (worst case hiding).
Otherwise, what's the use of (VCT) GI if I can't have it for terrain. There are over 200 maps in SR, and all have terrain(s).
If not then I'd add a note in features that GI doesn't work with Terrain, since I'd expect it would. Same as for planar reflections (fixed already) and area lights, etc.

[Crystal Hammer]

All right.
GI with terrrain is missing, and it's not that easy, there is much more detail in that issue. I'm leaving this for now. Didn't see a lot of benefit. SSAO is most important now for me. I need to fade it out with fog too. And fix stuff.

SSAO had a bug and was not working with FSAA, which I realized after like a day of trying to code it other ways. I didn't change FSAA for too long to notice.
This was already fixed on master.
SSAO.compositor changed it is somewhat similar to what's going on in Refractions.

I will be porting this next into SR3, since now SSAO started working, with some limits (no FSAA, Refractions have no depth).
It's kind of working in split screen. Only going bad with different aspect in views (wide bottom view). Likely need to set something per view in SSAO shader or so. Ah and this was Debug, that's why low Fps in red.

10_20-02-19``ss.jpg

[Crystal Hammer]

Yeah for split screen I had to call UpdateSSAO for every view in my CompositorWorkspaceListener, passEarlyPreExecute (I already have it for planar reflections).
UpdateSSAO sets psParams->setNamedConstant( "projection", camera->getProjectionMatrix() ); etc, for current view camera.

But IDK exactly how to fade out SSAO with distance? I mean fog, also height fog.
I'd either need to:

• compute fog(s) my way in SSAO_HS_ps.glsl, but that's old, not .any, it's in .glsl, .hlsl etc. and can't include my fog.any piece either. Also How do I get pixel position for e.g. distToCameraH = length( inPs.pos.xyz );. Sounds way too complex.
• or render just fog(s) to a new RTT and then sample it in SSAO_HS_ps multiplying occlusion there or in SSAO/Apply.
  But I can't just render all materials on scene as white, can I?
  Or maybe output a 2nd color target (MRT) from Pbs? I think gBufferNormals are done similar way.

Ugh another not easy task.
Any hints?

[Lax]

What you describe here, will nobody understand

Its soo deep and complicated!

I had in the past the idea and request for @dark_sylinc to create for Ogre a Blender like program, in which the user can create nodes, connect them and see a final output. Without to deal deeper with C++ compositor system code.
So that the app would produce the resulting compositor script or generate code, in order to load for Ogre applicationetc.
But such an application is also totally complicated to implement.

[Crystal Hammer]

Ah I think somebody will, or at least could try. Since there is knowledge in docs, in OgreNext code comments and then here on forum too.
Well I also liked the idea to have some Gui too for this, not long ago.
But now I actually think it's not even possible, the same goes for .compositor:
It's good for one configuration, maybe 2 or so. E.g. in Samples there are Msaa variants in few places already, since the Msaa buffers e.g. 8x FSAA (screen, or depth) need to be resolved for later stages. And with no Msaa they don't need, they are 1x aready.
This goes exponentially more complex, the more options you give user e.g. toggle HDR, toggle SSAO, Refractions, post effects, Split Screens etc. Each option changes compositor and make more combinations. That's why I left .compositor. I won't do 8 setups there for 2 options. Thus I believe the only way to do it is in C++, we already use it anyway.
A Gui tool would need to have IF blocks (from toggle options) for various routes or configs, and if it had then in the end it would also get complex and less readable. Plus yeah who would have time to code this Gui tool and keep it updated.
Lastly everyone has different needs for this pipeline and effects they want in it. So it's still needed to learn this all and RenderDoc too to check if you did it right.

[Crystal Hammer]

Ok I did fade SSAO with own RTT for output fog, value set in 3rd color MRT in Pbs.
Details on how here: https://github.com/stuntrally/stuntrall ... f5e792357e
Was actually easier than I thought.
I'm glad this becomes now more a progress blog, than unanswered questions list.
Now I get fog and height fog fading SSAO, as it should be, looks right.

[Crystal Hammer]

Wow I got SSAO working. The way I wanted, so it ignores glass pipes, water, fades out with fog(s) etc.
Only missing is that it doesn't get lit fully with car front lights. IDK, probably not possible or difficult.
So SSAO, Reflections (planar and dynamic cube), Refractions and Split Screen are working fine now.
I made a new node for SSAO that renders: color (not needed), normals, depth, and fog. At half screen res., no msaa, and with somewhat different setup (only opaque). And I feed these outputs into main render where ssao/Apply is, later I do like in Refractions demo for water etc.
This way I won't split my main render, which got bad. And I don't need another node to resolve. But I render more.

Works with no FSAA and FSSA too. I needed that if switch just like in Refractions demo, but in demo there are 2 setups in .compositor and if in C++. And for me, only in C++, it's just 2 if-s and that's it. So obviously I like C++ way more.

But I have to say, I am not covering the case of SSAO w/o refractions. And yeah C++ will get too complex with many combinations so it may be better to just duplicate some code instead of making it more unreadable with too many if-s etc. Still, it's less of it in C++, and I got my consts and defines, go to definition, comments in Ogre sources, help for possible values, etc. You don't have any of that when editing just .compositor.

Details and main code here:
https://github.com/stuntrally/stuntrall ... or.cpp#L43
It has a draft of what compositor nodes are now, inputs, outputs, targets etc. It helps to not get lost.
I will try HDR and bloom next. Wonder if it will mess up all tracks light setup.

[Crystal Hammer]

Pics or it didn't happen, so I think (screen)shots are in order. It's not perfect but really cool already.

0690``s.jpg

0705`s.jpg

1294`s.jpg

[Crystal Hammer]

Yeah I had to split my main render to another pass, I need to render road glass pipes, vegetation crystals, and particles after refracted fluids.

Do particles need to have depth_write off always, is that like a requirement? Is it because they have 1 depth per emitter not real vertex depth per each particle?
I think I managed to get my rendering order fixed now, but there is at least one issue left, with particles.

So if I have far particles like a waterfall or dust cloud, and I'm inside a near glass pipe, I see those particles rendered last, overwriting glass pipe (depth). This is wrong, particles should be rendered first then glass pipe, so they get dimmer because of it. Hmm I actually have them like so in Render Queue Groups: RQG_PipeGlass = 80 +2, RQG_Weather (Particles) = 105 +5
But RQGs are okay so if depth write is on, they can still switch order, as I show on video first with waterfall.

I made a video showing these particle issues also the other one having 2 emitters and switching which is first.

Are these limits by particle system. Is it not possible to get this right?
I guess Particle Universe did have those too? I don't think v2 particles change this since they don't blend, just hash alpha right? (so I'd be trading these issues for that hash grain noise).
Do GPU gpu particles fix this, but limit parameters? Is sorting each particles across all emitters a nightmare? Maybe I should do volumetric clouds instead, if I can even get to implementing that )
Any idea how this looks like with particles in other enigines, Godot etc?

[Crystal Hammer]

Hmm why am I seeing this, and what may not look right?

Code: Select all

WARNING: PBS Datablock 'Water_blue' enabling transparency but forcing a blendblock to avoid alpha blending. Results may not look as expected.

Code: Select all

...
		"Blendblock_2" :
		{
			"alpha_to_coverage" : false,
			"blendmask" : "rgba",
			"separate_blend" : false,
			"src_blend_factor" : "one",
			"dst_blend_factor" : "zero",
			"src_alpha_blend_factor" : "one",
			"dst_alpha_blend_factor" : "zero",
			"blend_operation" : "add",
			"blend_operation_alpha" : "add"
		}
...
		"Water_blue" :
		{
			"macroblock" : "Macroblock_0",
			"blendblock" : "Blendblock_2",
			"shadow_const_bias" : 0.01,
			"workflow" : "specular_ogre",
			"refraction_strength" : 0.7,
			"transparency" :
			{
				"value" : 0.17,
				"mode" : "Refractive",
				"use_alpha_from_textures" : true
			},
			...

As far I see it: Refractive is not real transparency, it needs to blend full always, it does become transparent only because it draws from pre rendered screen texture. I even do it the same on borders where it fades, not by blending, by using that texture.
PS. I wonder if you (again) don't read this at all @dark_sylinc, it's been over 2 months again with no comment at all

[dark_sylinc]

Very late response but:

Do particles need to have depth_write off always, is that like a requirement? Is it because they have 1 depth per emitter not real vertex depth per each particle?
I think I managed to get my rendering order fixed now, but there is at least one issue left, with particles.

The short answer is yes. Depth write must be off.
In order to be able to enable it, all transparents (not just particles) would have to be rendered in perfect order, with no triangle overlapping.

The longer answer:

Any idea how this looks like with particles in other enigines, Godot etc?

There is a joke in gamedev that says "The bug transparency bug was fixed. The cup of water made of glass the character drinks was replaced with a mug". The solution is to simply avoid transparency as much as possible, and hide the artifacts whenever they pop up. Sadly, you've chosen to use transparent loops for your tracks which is a nightmare situation.

The ultimate solution is to use OIT (order independent transparency):

1. Linked Lists and UAV. This is an advanced algorithm, quite expensive. I have no time to implement it sadly.
2. WBOIT an approximation hack. It sorta works. I wanted to implement it, but I've found no time of my own. Ogre1 did implement it though, and has a sample.
3. Alpha Hashing and A2C (alpha to coverage): Implemented for OgreNext 4.0 since the PFX2 plugin did not have particle sorting. Alpha Hashing is a material property that can be used for anything (including your loops) not just the PFX2 plugin. This may be a viable solution for you if using MSAA (since A2C + Alpha Hashing looks quite decent).

Hmm why am I seeing this, and what may not look right?

This is an OgreNext bug. The JSON syntax does not allow to force mIsTransparent for opaque blendblocks. As a workaround you can remove the blendblock line:

Code: Select all

"blendblock" : "Blendblock_2",

If you do not set it, OgreNext will create one for you that satisfies the blending requirements.
This bug will cause the Refractive objects to be deprioritize sorting by depth, which you want to be priority for Refractive materials, to minimize artifacts. If you're already tightly controlling the water render order through render queue IDs, this bug may be harmless.

Just remove the line until OgreNext adds the necessary JSON syntax.

[dark_sylinc]

One more thing: OgreNext tries to rough sort MovableObjects by distance to camera, using its AABB.

Each Particle System Instance should have its own AABB, and your loop should have a proper AABB too.

What I see here at 1:09 looks off because the camera is inside the loop. If the particle system has particles around the whole map, then its AABB would be bigger than your loop's and cause this problem (because your camera is considered inside both the loop and the particles, and closer to the particles, so they're rendered last).

But if the particle systems are localized with a smaller AABB, then the particles should be rendered first, since the camera is closer to the loop. This is what you want to happen, so this case is rendered correctly.
However for this to work, the loop and the particle FXs must be in the same Render Queue ID.
If PFXs are in a higher RQ ID than the track loops, the PFXs will always be rendered last (causing this glitch).

Like I said, your scene requirements are a nightmare for any gamedev.

Are you able to place the transparent sections of the tracks in the same RQ ID as the PFX?

[Crystal Hammer]

Thanks for explanations. I really enjoy reading and learning from these.

Are you able to place the transparent sections of the tracks in the same RQ ID as the PFX?

Sadly I can't. Particles are v1 (> 100), and my roads and pipe glass sections are in v2 (< 100).
So I think this is the 2nd reason to have roads as v1 meshes. 1st was not doing v2->v1->v2 to compute tangents which is slower to load and edit.
AABBs should be fine, those were small emitters, size was of that white cursor. Even if I merge road sections to be larger, which I don't when editing, still.
I think somehow it would be better to have more options of emitting. Like to still have 1 "emitter" for drawing but actually more emitters possible inside (so it's still 1 batch and sorting for all particles), would be great to have for car wheels. And having more params, e.g. uv (other textures) per such emitter, colors etc. Well this is still limited by CPU sorting so can't do any crazy count like with GPU particles. There was though one method of brute sorting on GPU I saw on some video.

Isn't it better to just disable that transparency warning if "Refractive" is used there? Since Refractive is done its own way. I think I'll do that in Ogre code.

[dark_sylinc]

Sadly I can't. Particles are v1 (> 100), and my roads and pipe glass sections are in v2 (< 100).

Ahhh!!! You're right!

OK two simple solutions (+ 2 more variants):

1. If you are able to easily detect if the camera is inside the pipes, swap the RenderQueue IDs so that pipes are rendered last. If you're outside the pipes, well, that "depends".
2. Set the glass pipes to alpha hashed with A2C and depth writes on. It should look very decent. The particles leave them as is with alpha blending and depth writes off. Make sure the particles are rendered after the pipes (set the particles' RQ ID to be higher than the pipes).
3. The inverse of 2: Use alpha hashing + A2C w/ depth writes on for the particles, alpha blending w/ depth writes off for the glass pipes. Make sure glass pipes are rendered after the particles (set the particles' RQ ID to be lower than the pipes). I think this might present some issues, so I'm not fully convinced. Try option 2 before 3.
4. Use alpha hashing + A2C w/ depth writes on for everything. Render Queue ID order no longer matters.

Isn't it better to just disable that transparency warning if "Refractive" is used there? Since Refractive is done its own way. I think I'll do that in Ogre code.

No, because we want mIsTransparent to be set so that RenderQueue prioritizes sorting by depth for these objects.

[Lax]

Hi @Crystal Hammer,

Could you please explain/write an instruction, how did you implement Splitscreen? Code example would be appreciated.
I now have some more time and I would like to start a new round, but still have no idea how.

You splitted the rendered texture? How about shadows and hdr, quat passes? What about the split screen parameters like mExecutionMask, mViewportModifierMask etc.

I would like to try to integrate it to my whole workspace code.

That would be really really great. Maybe that could also be added to the Ogre-Docs?

Best Regards
Lax

[Crystal Hammer]

Hi Lax
I think I already wrote twice, mainly here: viewtopic.php?p=556795#p556795
and here: viewtopic.php?p=556774#p556774
but okay, here is a summary full guide.

Start with basic rendering for one view, comment out or drop all else for clarity. Check that it works okay.
In the case of one view your compositor outputs to render window, full size (e.g. 1920 x 1080).
End of that case. Code should be reusable, so you can create it again from cpp, and as it really gets less complex than in .compositor.
I made myself many utility methods so it is shorter for me, all are here
https://github.com/stuntrally/stuntrall ... il.cpp#L66
My code is GPLv3, but if yours is too, then you can use it if you want. A credit or donation would be appreciated of course.

Now going into split screen, you have this code that renders one view, use it.
It stays the same, but it needs to render to a RTT (instead of window) and its size is smaller.
As an example let's assume the case of 2 views vertical split here.
This RTT will be 960 x 1080 size.
And you create this compositor twice, one for each view. I am also adding numbers so everything (NodeDefs, WorkspaceDefs, Workspace) has own name and is duplicated.

Shadows are the same always, just set:
pass->mShadowNode = "to your shadow node name";
for each pass being CompositorPassSceneDef* that needs to use shadows, first will render them only.
Set pass->mShadowNodeRecalculation = SHADOW_NODE_REUSE; in later pass(es) if you have them.
(I have 3 total, 1st for opaques, terrain etc, 2nd for refracted fluids only, and later 3rd for glass and particles etc.)

You now need to create and add a new workspace, I call it Combine.
It does not render scene (no pass scene here). This is now the only workspace that renders to window.
It does have a pass quad with shader and for 2 views it will have 2 inputs, these RTT textures from above workspaces.
Shader code is here: https://github.com/stuntrally/stuntrall ... 2v_ps.glsl
That shader just reads those input textures at needed offsets and scales to put them finally in real place on screen.
That's it.

As for mExecutionMask, mViewportModifierMask, this is not used at all.

Now, as for effects, like SSAO, HDR, etc. This is changed in that first one view compositor code. It simply gets more textures, targets, quad passes etc.
My code starts here and it has first a text guide in comment, with all my nodes, targets and passes (for both 1 view and split screen):
https://github.com/stuntrally/stuntrall ... or.cpp#L36

It probably is quite complex now. It has refractions, SSAO, lens flare, sunbeams, and all can be toggled. But for simplicy refractions are needed for those effects.
I also have my own node s0 with stuff to prepare for ssao, it's half view size. Extra render but at least I have control of what to render (e.g. not glass) and it returns normals and my fog texture for ssao to use later.
I also use all that code to create 2 extra RTTs in my Track Editor. Only few places change, so that editor knows later in workspace listener to turn off fog for e.g. terrain top preview, and fog back on again for 3D preview and for normal 3d view.

So yeah like I posted yearlier, you can see the main, first commit when it started working
https://github.com/stuntrally/stuntrall ... 8934be4554
it was less complex.

[Lax]

Thanks for your explanation.

So do you create the split texture at last and merge all prior textures into it? Or do you create for each effect (hdr, reflections, etc.)?

Best Regards
Lax

[Crystal Hammer]

No I create the texture and RTT before workspace, nodedef etc. here:
https://github.com/stuntrally/stuntrall ... r.cpp#L264
in AddSplitRTT, its code here:
https://github.com/stuntrally/stuntrall ... l.cpp#L123
That is the RTT output for 1 view in split screen.
I don't create the final, because that is render window, it is already done by Ogre.
And all effect textures just have addTextureDefinition in cpp, like in .compositor with texture keyword. Not created by my code probably by Ogre.

[Lax]

Hi @Crystal Hammer,

I'm trying to create a simple splitscreen workspaces, but I just see the mygui and black screen. I orientated a bit at your code and creating 3 workspaces (not sure, why 3). Here is the code:

Code: Select all

Ogre::TextureGpu* WorkspaceBaseComponent::createSplitRenderToTexture(const Ogre::String& textureName, Ogre::Real width, Ogre::Real height)
{
	auto* texMgr = this->gameObjectPtr->getSceneManager()->getDestinationRenderSystem()->getTextureGpuManager();

// Check if the texture already exists
Ogre::TextureGpu* existingTexture = texMgr->findTextureNoThrow(textureName);
if (existingTexture)
{
	return existingTexture; // Return the existing texture
}

// Create the base texture
auto* tex = texMgr->createTexture(textureName + "_Tex", Ogre::GpuPageOutStrategy::SaveToSystemRam, Ogre::TextureFlags::ManualTexture, Ogre::TextureTypes::Type2D);

tex->setResolution(
	Core::getSingletonPtr()->getOgreRenderWindow()->getWidth() * width,
	Core::getSingletonPtr()->getOgreRenderWindow()->getHeight() * height);
tex->scheduleTransitionTo(Ogre::GpuResidency::OnStorage);
tex->setNumMipmaps(1); // None
tex->setPixelFormat(Ogre::PFG_RGBA8_UNORM_SRGB);
tex->scheduleTransitionTo(Ogre::GpuResidency::Resident);

// Create the RTT (render-to-texture)
auto flags = Ogre::TextureFlags::RenderToTexture;
auto* rtt = texMgr->createTexture(textureName, Ogre::GpuPageOutStrategy::Discard, flags, Ogre::TextureTypes::Type2D);

rtt->copyParametersFrom(tex);
rtt->scheduleTransitionTo(Ogre::GpuResidency::Resident);
rtt->_setDepthBufferDefaults(Ogre::DepthBuffer::POOL_DEFAULT, false, Ogre::PFG_D32_FLOAT);

return rtt;
}

void WorkspaceSplitComponent::internalCreateCompositorNode()
{
	// Create a texture for this camera's split view
	Ogre::String splitTextureName = "rt" + Ogre::StringConverter::toString(cameraComponent->getEyeId());
	this->splitTexture = this->createSplitRenderToTexture(splitTextureName, 0.5f, 1.0f);

// Create a compositor node for this split view
Ogre::CompositorNodeDef* nodeDef = this->compositorManager->addNodeDefinition(splitTextureName);

// Add split texture as input
nodeDef->addTextureSourceName(splitTextureName, 0, Ogre::TextureDefinitionBase::TEXTURE_INPUT);

// Configure the rendering pass
Ogre::TextureDefinitionBase::TextureDefinition* texDef = nodeDef->addTextureDefinition(splitTextureName + "_RTV");
// texDef->width = 0;
// texDef->height = 0;
texDef->format = Ogre::PFG_RGBA8_UNORM_SRGB;

Ogre::RenderTargetViewDef* rtv = nodeDef->addRenderTextureView(splitTextureName + "_RTV");
Ogre::RenderTargetViewEntry attachment;
attachment.textureName = splitTextureName;
rtv->colourAttachments.push_back(attachment);

// Clear and render the scene for this split view
nodeDef->setNumTargetPass(1);
Ogre::CompositorTargetDef* targetDef = nodeDef->addTargetPass(splitTextureName + "_RTV");
targetDef->setNumPasses(2);

{
	auto pass = targetDef->addPass(Ogre::PASS_CLEAR);
	Ogre::CompositorPassClearDef* passClear = static_cast<Ogre::CompositorPassClearDef*>(pass);
	passClear->mClearColour[0] = Ogre::ColourValue(0.2f, 0.4f, 0.6f);
	passClear->setAllStoreActions(Ogre::StoreAction::Store);
}

{
	auto pass = targetDef->addPass(Ogre::PASS_SCENE);
	Ogre::CompositorPassSceneDef* passScene = static_cast<Ogre::CompositorPassSceneDef*>(pass);
	passScene->mCameraName = this->cameraComponent->getCamera()->getName();
	passScene->mIncludeOverlays = false;
	passScene->setVisibilityMask(this->cameraComponent->getOwner()->getMaskId());
}

this->createFinalRenderNode();
}

void WorkspaceSplitComponent::createFinalRenderNode(void)
{
	if (cameraComponent->getEyeId() < 1)
	{
		return; // Only create the final node after all splits are defined
	}

if (this->compositorManager->hasNodeDefinition(this->finalRenderingNodeName))
{
	this->compositorManager->removeNodeDefinition(this->finalRenderingNodeName);
}

Ogre::CompositorNodeDef* finalNodeDef = this->compositorManager->addNodeDefinition(this->finalRenderingNodeName);

// Add render window as the first input
finalNodeDef->addTextureSourceName("rt_renderwindow", 0, Ogre::TextureDefinitionBase::TEXTURE_INPUT);

// Add all split textures as inputs
for (int i = 0; i <= this->cameraComponent->getEyeId(); ++i)
{
	Ogre::String splitTextureName = "rt" + Ogre::StringConverter::toString(i);

	// Check if texture already exists
	Ogre::TextureGpu* texture = this->createSplitRenderToTexture(splitTextureName, 0.5f, 1.0f);
	if (!texture)
	{
		OGRE_EXCEPT(Ogre::Exception::ERR_INVALIDPARAMS, "Failed to create texture: " + splitTextureName, "WorkspaceSplitComponent::createFinalRenderNode");
	}

	finalNodeDef->addTextureSourceName(splitTextureName, i + 1, Ogre::TextureDefinitionBase::TEXTURE_INPUT);
}

// Render target is the window
finalNodeDef->setNumTargetPass(1);
Ogre::CompositorTargetDef* targetDef = finalNodeDef->addTargetPass("rt_renderwindow");

// Quad pass to merge split views
{
	auto pass = targetDef->addPass(Ogre::PASS_QUAD);
	Ogre::CompositorPassQuadDef* passQuad = static_cast<Ogre::CompositorPassQuadDef*>(pass);
	passQuad->mMaterialName = "SplitScreen_2h";
	passQuad->mProfilingId = "Split_Quad_Pass";

	// Add split textures as inputs to the quad
	for (int i = 0; i <= this->cameraComponent->getEyeId(); ++i)
	{
		Ogre::String splitTextureName = "rt" + Ogre::StringConverter::toString(i);
		passQuad->addQuadTextureSource(i, splitTextureName);
	}
}

// MyGUI pass
{
	auto pass = targetDef->addPass(Ogre::PASS_CUSTOM, "MYGUI");
	pass->mProfilingId = "Split_MyGUI_Pass";
}

// Render scene pass
{
	auto pass = targetDef->addPass(Ogre::PASS_SCENE);
	Ogre::CompositorPassSceneDef* passScene = static_cast<Ogre::CompositorPassSceneDef*>(pass);
	passScene->mIncludeOverlays = true;
	passScene->mFirstRQ = 254;
	passScene->mLastRQ = 255;
	passScene->mProfilingId = "Split_Scene_Pass";
}
}

bool WorkspaceSplitComponent::internalCreateWorkspace(Ogre::CompositorWorkspaceDef* workspaceDef)
{
	if (cameraComponent->getEyeId() == 1) // Assuming this is the last camera
	{
		workspaceDef->connectExternal(0, this->finalRenderingNodeName, 0); // Render window
		for (int i = 0; i <= this->cameraComponent->getEyeId(); ++i)
		{
			workspaceDef->connectExternal(i + 1, this->finalRenderingNodeName, i + 1); // Split textures
		}

	this->addWorkspace();
}
return this->workspace != nullptr;
}

void WorkspaceSplitComponent::addWorkspace()
{
	for (int i = 0; i <= this->cameraComponent->getEyeId(); ++i)
	{
		Ogre::CompositorChannelVec externalChannels;
		Ogre::String splitTextureName = "rt" + Ogre::StringConverter::toString(i);

	if (false == WorkspaceModule::getInstance()->getCompositorManager()->hasWorkspaceDefinition(this->workspaceName + "_" + splitTextureName))
	{
		Ogre::ColourValue color(this->backgroundColor->getVector3().x, this->backgroundColor->getVector3().y, this->backgroundColor->getVector3().z);
		this->compositorManager->createBasicWorkspaceDef(this->workspaceName + "_" + splitTextureName, color, Ogre::IdString());
	}

	externalChannels.push_back(this->createSplitRenderToTexture(splitTextureName, 0.5f, 1.0f));

	this->compositorManager->addWorkspace(this->gameObjectPtr->getSceneManager(), externalChannels, this->cameraComponent->getCamera(), this->workspaceName + "_" + splitTextureName, true, 0);
}

Ogre::CompositorChannelVec externalChannels;
externalChannels.push_back(Core::getSingletonPtr()->getOgreRenderWindow()->getTexture()); // Render window
for (int i = 0; i <= this->cameraComponent->getEyeId(); ++i)
{
	Ogre::String splitTextureName = "rt" + Ogre::StringConverter::toString(i);
	externalChannels.push_back(this->createSplitRenderToTexture(splitTextureName, 0.5f, 1.0f));
}

this->workspace = this->compositorManager->addWorkspace(this->gameObjectPtr->getSceneManager(), externalChannels, this->cameraComponent->getCamera(), this->workspaceName, true, -1);
}

Maybe you see, what is going wrong here. I call those functions 2 times, one for each eyeId. So the first camera has the eyeId = 0 and the second camera has the eyeId = 2.

createSplitRenderToTexture is called for "rt0" and "rt1" -> eyeId each time and texture is only created, if does not exist, else the existing texture is delivered.

Any help is appreciated!

Best Regards
Lax

[Crystal Hammer]

IDK but you have this

Code: Select all

void WorkspaceSplitComponent::addWorkspace()
{
	for (int i = 0; i <= this->cameraComponent->getEyeId(); ++i)
...
		externalChannels.push_back(this->createSplitRenderToTexture(splitTextureName, 0.5f, 1.0f));

and then you have it also

Code: Select all

	for (int i = 0; i <= this->cameraComponent->getEyeId(); ++i)
	{
		Ogre::String splitTextureName = "rt" + Ogre::StringConverter::toString(i);
		externalChannels.push_back(this->createSplitRenderToTexture(splitTextureName, 0.5f, 1.0f));

It seems to me like you createSplitRenderToTexture( for both eyes to render views into them,
and then you again createSplitRenderToTexture( inside externalChannels.push_back(, why? are those new textures if so they won't render anything. Why not just use the name or pointer from created earlier.

Also you can check in RenderDoc what inputs go into "Split_Quad_Pass" that last workspace. If they are black (seems so) while earlier you saw both eyes rendered to some other textures it means you are feeding something else instead.

[Lax]

Boy, I'm not able to get it working. I'm struggling for days at costs of my vacation.
I'm not able to understand, how this should working. Your code is for you well structured, but for anyone else not really well readable. But thats fine, its your project. I get no error nothing. Just see mygui pass, but inside a black screen.

I tried with renderdoc, but really. Its not my favorite topic, i'm not able to see what is going on.

And even, I would get it working. I would have no idea how to add hdr and all other effects... I have not that time and energy anymore with child.

I think, I have to give it up.

I have no energy anymore and lots of knots in my brain, the whole Ogre compositor system is just a mess for me.

I think, if @dark_sylinc, cannot get it working via mExecutionMask, mViewportModifierMask at the generic place in OgreViewport, I'm doomed.

[Crystal Hammer]

Please don't take my response too personally, I'm not trying to attack you, just being very honest as always.

Boy, I'm not able to get it working. I'm struggling for days at costs of my vacation.

Well, I'm not a boy since a long time, I'm 42
I've put all of those 8 years into SR from my vacation and free time, while also sometimes struggling, so I don't really see an alternative. It's definitely more rewarding like that.

Your code is for you well structured, but for anyone else not really well readable. But thats fine, its your project.

Yes, true. I'm pretty sure you like your code best too. I did have to auto format it first to read it and couldn't look for too long. So yeah I surely like mine most.

What matters is your: programming skills, developing, debugging skills, exprience, how much time you spend on it, determination, learning, IQ, etc.
Obiously it took months or years, but I can now debug, check in OgreNext code, debug in it too if needed, check what happens in RenderDoc if I get what I meant, learn if I don't etc.

This is what it means that OgreNext is an advanced engine.
If you have a complex pipeline or project and you can't do this, then don't use it. You will fail, and likely get frustrated.
Obviously noone will do it for you, it's not Godot etc with plenty of popularity, contractors, active forum users, etc.

I tried with renderdoc, but really. Its not my favorite topic, i'm not able to see what is going on.

It wasn't mine either, but there are tutorials for it and one can learn.

I'm not able to understand, how this should working.
I think, I have to give it up.
I have no energy anymore and lots of knots in my brain

Then just give it up. No need to mention it so many times. I wish you all the best for future.

I think, if dark_sylinc, cannot get it working via mExecutionMask, mViewportModifierMask at the generic place in OgreViewport, I'm doomed.

I'm almost sure it is not possible. And I'm pretty sure he won't and we know how to do it other way, since 10th Sep. (there viewtopic.php?p=556543#p556543).

Now, could you please post in your topic (since you have it anyway), not in mine, which is for all Stunt Rally related issues, not just for Split screen or compositor advice.

Lastly, honestly you are pinging dark_sylinc way too often. Seems like once each month or even once in 2 weeks, since June.
I'm pretty sure he won't fix it for you, and neither will I.
It's pretty obvious for me since a while, that he has a regular job, then paid project(s) with OgreNext, and doesn't want to spend his free time on it too. And lately (since years) most OgreNext contributions and bigger features were paid for.
I'm not complaining, it is still MIT license. And I like this project most, the more I know it, the better it feels.

[Lax]

Oh sorry, I did not mean to insult you, by "boy" I meant, its just a phrase.

You are right. I'm also dealing with Ogre vor more than 10 years. I will stop ping you guys with this topic. Will concentrate on other topics and bury split screen.

Thanks anyway for all you tips and patience.

Best Regards
Lax