Well, at the moment is a mix of changes in the Babylon source and in my project because it was easier to make the rendertargettexture in my project and hold it there then pass it into Babylon, as a massive hack… how could I make a PG with modified Babylon.js, would that help you?
Well not a lot 
Maybe you can share a repo on github?
Let me mess with this some more, I might just need a bit of sleep then I can refine this make an incomplete PR that you can work with and I can provide a sample that will as far as I got it with the PR
1 Like
One way you can think of what I’m doing is if a renderGroup is marked as cachable only ever render that group to a cache when dirty, so right now my cache is a RenderTargetTexture, and when the cache is not dirty only render the RenderTargetTexture as if everything is all calculated already and the size of the engines canvas…
If you think I need to gather a second RenderTargetTexture for depth from the rendergroup so it gets placed correctly please give me a nod in that direction if not I can look into other problems.
The only problem I see is that we cannot reuse depth values. This is a PITA. To have your cache to work, you will need to restore the depth buffer before rendering next groups.
Ideally:
- render cache for group 0
- restore the depth buffer for group 0 (not technically possible
) - render group 1
- render group 2
etc…
You mean you cant cache the depth buffer for group 0, and just reset it?
Yes. This is not possible with webgl
However, my thought is the rendering groups seem to be layered over each other and depth doesn’t matter… so if I rendered an image as group 0, then shouldn’t group1 render on top of that anyway? This is where I’m at, group 0 is over group 1 instead
yes it will render on top of it
that’s what I thought, then seems something else might be the problem, I’ll debug through it
1 Like
Well, I figured that issue out earlier… didn’t make sense before, but now makes perfect sense…
var pp = new RenderGroupCachePostProcess(“rgc”, 1, scene.activeCamera)
^ that attaches the post process to the camera, so ends up processing last as an actual post process, now I know lol… changed it to attach to the engine instead worked like a charm…
Now the proof of concept is working, some other issues for me to iron out, I’ll update here when I’m able to work on it again.
I got another idea for you to ponder about, while debugging the scene.render() pipeline, there are a lot of functions, and checks called every iteration, I know a lot of these checks are fast but at the same time 80% of these checks my scene isn’t using at all, ever. Might be warranted to do something interesting to squeeze more performance, like scene.renderPipelineFreeze() and custom builds the render pipeline to only calls actually used either using eval() or an array of functions to call… then every time scene.render() is called when its frozen it continuously reuses that custom compiled version of the pipeline… just a nice over the top optimization that popped in my head 
Did you try scene.freezeActiveMeshes()? This will reduce the number of function calls by…A LOT 
yep, I’m thinking about all these observers and different mesh types, ordering of meshes, target checking and things like that as well
I probably could have used one of these observers for this feature, if I was able to specify in the observer actionHandled = true so it doesn’t call the section between the observations.
Honestly I apply the 80/20 rule: Only optimize if it optimize more than 20% in 80% of the use case
If you do a perf measure I’m pretty sure you will see that all that code is not even measurable
Well, unfortunately on my i7 laptop it has trouble lol, and various phones so leave no rock unturned! I even got a lot of reduced cpu usage by removing the repeated sprite buffer updates when they don’t change using a dirty flag, gained a few fps there, and will save device battery overall.
But yes, not everything needs to be optimized away, sometimes it can be a hassle that’s where I draw the line.
1 Like
For what ever can be pushed to framework, please feel free to do a PR:)
I plan on it, in the end, after I stop hacking everything 
to find out what works and what doesn’t.
1 Like
@Deltakosh hey, what should I look into when I set the bindBuffer to a texture, the format of the texture is the default RGBA, but when I call engine.clear(new Color4(1,0,0,0), true, true, true) instead of painting transparent, it actually clears with the red color, ignoring the alpha
I am sorry I do not understand your previous sentence at all. What are you trying to achieve ?
engine.clear with red and alpha 0 would look red if the gl context options are disabling alpha.