Unity’s Scriptable render loops – Revolution!


I recently heard about unity’s new “Scriptable render loops” feature which is currently in experimental state available, and so far it looks to me like the “rendering revolution” unity needs to finally have proper support for custom rendering effects.

The current problem in my opinion is that the unity rendering pipeline is ways too fixed and badly needs more flexibility.
There are a lot of things in unity which are really annoying to me regarding their rendering.

If you are trying to implement custom rendering that doesnt follow the rendering patterns of forward or deferred rendering on unity you are basically out of luck as soon as you want lighting integration.
The tressfx renderer is a very good example for why unity is so bad in this situation.

It is very hard to get lighting data out of unity and make sense of it, the best example most likely is the shadow map.
In order to retrieve the shadowmap of a light, you can use LightEvent.AfterShadowMap and copy the current render target into a render texture (See this example: https://docs.unity3d.com/ScriptReference/Rendering.CommandBuffer.SetShadowSamplingMode.html).

This works great and in case you just want to get the shadow map it’s perfect, but usually when you want a shadowmap you want to use it in order to render shadows, which isnt possible without knowing the shadow matrices, which are (surprise!) not exposed by unity so the shadowmaps you can copy are pretty much useless.

There is (apparently, i haven’t tested it) a workaround to this solution described here.

What Avol from the unity forums suggests is basically rendering a quad into a 7×7 texture and outputting the matrix encoded into it’s colors(On LightEvent.AfterShadowMap the shadow matrix should still be set as view / projection matrix, on LightEvent.AfterScreenspaceMask it should be bound as actual shadow matrix, i guess).
Then reading it back on the cpu and decoding the color values, but seriously i shouldnt have to even think of a solution like this in a modern game engine.

So, in case of the tressfx renderer i had to render my own shadow maps (which doubles the amount of time needed to render scene shadows, which is not acceptable at all).

All this madness will change with the new scriptable render loops!

Unity will allow us to implement own “render loops” which essentially control all draw calls the unity engine does in order to render the final image, by giving us an api that can be used to cull and render sets of objects from C#.
This way we will be able to setup any kind of rendering behaviour we want, without having the unity black-box around it and not knowing what’s going on.

Also they will introduce a new rendering pipeline (basically a reference implementation of a AAA rendering pipeline implementation by unity), which is open-sorce (here: https://github.com/Unity-Technologies/ScriptableRenderLoop).

I am really looking forward to testing the stable version of this system, it could give unity’s renderer the same flexibility as the rest of the engine has finally!

Here are some links you might want to read about the scriptable render loops:
Google doc: https://docs.google.com/document/d/1e2jkr_-v5iaZRuHdnMrSv978LuJKYZhsIYnrDkNAuvQ/edit
Aras’ presentation from GDC 2017: http://aras-p.info/texts/files/2017_GDC_UnityScriptableRenderPipeline.pdf

As a sidenote, the game i am working on just entered public alpha phase on 31st May and is now available on www.itch.io.
You can get a copy here: https://dapperpenguinstudios.itch.io/rise-of-industry

Have a nice day!

New TressFX Version


I just start pusing my current tressfx code to github :>

The new version of tressfx is now publicly available for anyone. It is a complete rewrite of the old version which got better editor integration, more stability and better performance.
Here is some general info on how to use the new version:

  • Make sure, the TressFX folder is in your Assets root. The current asset importer relies on the assetconverter being located in Assets/TressFX/assetconverter.exe. This will change in future version (My own importing system is in development).
  • When importing hair files from ASE make sure your hair strands __ALWAYS__ contain 16 vertices if you want to use simulation. You can let tressfx normalize them on import, under Window > TressFX you can configure the importer (Normalize vertex count to 16 if you want simulation).
  • You can also configure follow hair generation on import. Follow hairs are additional hairs generated to your imported geometry. Simulating them is cheap, because they follow their master (the hair in your input geometry).
  • Do not use scaling. It is unusable at the moment and creates very strange behaviour.
  • After importing the hair, make sure you configure the physics properties on the hair asset (Check the examples).
  • Check the example scene for an example on how to configure the hair rendering game object

Feel free to report bugs in github and / or fork the code. I will accept pull requests aswell :->

This is the base version of tressfx, the renderer i wrote about in the last post will be release at a later point, because it’s far away finished 😛
The rendering is abstracted, you can easily implement own renderers with some coding-fu and there is an example renderer with an example surface shader included.
It supports shadow receiving / casting aswell (but only directional lights at the moment).

Currently it only supports DirectX >11 / Windows, Portation to linux (and mac os) is planned 😉

That’s it for today, anyone have fun testing TressFX for unity and happy new year! 😀