RenderingManager and render ordering

[BabylonUser]

Hey,

I'm implementing an effect and it's brought up some questions about the RenderingManager class

The effect uses a series of draw calls involving the stencil and depth buffers that must be called in a specific order. The only mechanism I've found so far to enforce draw order (other than separate render calls) is to use the mesh renderGroupId property, however this has some interesting limitations:

1. There can only be a fixed number of groups (ids 0-3 by default)

2. Depth is cleared after each group

In the ideal case I'm looking for a mechanism that lets me enforce the draw order. Something like a  'renderOrder' property with arbitrary range (-Infinity -> Infinity). Allowing negative values is important because I want to be able to ensure some object render before everything else (without explicitly setting a render order for everything else)

(as an aside, looks like there's no sorting of opaque objects during rendering - typically sorting so opaque objects are rendered from front to back is faster)

 

[ivan.popelyshev]

Guys, im sorry for intervention, but we have a special approach for that in PIXI - https://github.com/pixijs/pixi-display , you can do something like that for Babylon too, its really simple.

[GameMonetize]

Hey!

1. You can increase this limitation: BABYLON.RenderingManager.MAX_RENDERINGGROUPS = 16

2. Correct

We could think about a way to turn off depth cleaning perhaps?

" typically sorting so opaque objects are rendered from front to back is faster": My tests regarding this tend to prove the opposite

[BabylonUser]

What do you think of a new engine flag 'autoClearDepth' which disables all depth clearing in the engine? To prevent confusion, maybe we could rename autoClear to autoClearColor? If you're happy I'll make a PR

 

Re object sorting: if opaque objects are rendered front-to-back you can save the GPU evaluating wasted fragments that'll get overwritten by foreground objects. If your scene is simple, a few objects with the odd 1 or 2 overlaps and cheap shaders this isn't much of a benefit but when your scene is complex - say you're standing within a building in some first person shooter - without sorting before sending draw calls you could end up having the GPU evaluate fragments for other buildings, sky, clouds, backgrounds etc, which are then all wasted when the walls of the building you're in are rendered.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0555c/BABHAIAD.html

CPU Sorting can be expensive and so it won't fit all cases but it doesn't need to be accurate, just rough camera distance ordering to get the best trade-off between CPU cost and GPU saving

Maybe a new engine flag, sortOpaque? Which defaults to false but a dev can see if flipping to true improves performance in their case?

 

[GameMonetize]

For the sortOpaque flag: good idea, off by default to keep compat, love it

I suggeset also adding a disableDepthClearing property to achieve what you suggest  Happy to valdiate the PR

[BabylonUser]

Great,

Here's a tentative PR to disable depth clearing, I've gone with a single flag to disable all depth clearing rather than separate flags - I'm thinking if a user is disabling one, it probably means they want to manage clearing themselves and so will want to disable all https://github.com/BabylonJS/Babylon.js/compare/master...haxiomic:master

I've removed some checks of depthMask which were unnecessary (if it's false, clear shouldn't affect the buffer anyway)

As an aside, I've been getting errors when setting stencil: true on engine options (to enable the stencil buffer on the gl context), so this commit fixes that https://github.com/BabylonJS/Babylon.js/commit/7b3f0c4400f1936c24aa8f3288a366a177431306

[GameMonetize]

I was not thinking about changing Engine actually (And btw we cannot change clear signature as this is a public function)

I was more thinking about asking the renderingManager to not clear depth buffer automatically between rendering groups

[BabylonUser]

Fair enough, I agree we should avoid adding new things to engine if we can avoid it!

I'm not certain how we should go about adding a flag to rendering manager - the rendering manager instance is private on scene currently so we couldn't set it if there was one, we could add some static setting but I'm not sure this is a good idea. We could make the instance public? Any other ideas?

For future reference, when it comes to changing public method signatures its it a problem to modify one such that it's functionally equivalent in all cases previously used? For example, with adding a stencil clear flag to engine.clear, because we've got a default value set, it'll behave the same in all previous usage

 

Do you have thoughts on the changes to improve typing in the engine constructor? Again it's functionally equivalent, just with new optional fields visible to the type system (there's also a fix for the antialias option)

https://github.com/haxiomic/Babylon.js/blob/master/src/babylon.engine.ts#L391

 

 

 

 

 

[GameMonetize]

I like the typings improvements a lot

@Sebavan is working a solution for the rendering manager