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.