Plane9

The wonderful world of bloom

Mon, 25 Feb 2013 21:02:00 Z

Bloom is a very powerful and useful effect when used in moderation. It's the simulation of very bright lights. Your monitor can only represent a light intensity that goes from 0.0 to 1.0. So say you render a forest scene with a average brightness of 0.7. Now you want to simulate that the user is looking at the sun in this scene. The brightness of the sun compared to your forest is many orders of magnitude larger but you can only set it to 1.0 so it looks white like a white circle in the sky. But that is all. It wont overshadow the forest as it would if you looked at the sun in real life.

What bloom does to help in this is that it simulates how the bright light floods over to other part of the scene. This is done using a (large) blur. So you set your sun, can be just a few pixels, to a brightness of 100000.0. Then blur the scene to spread out the brightness over the scene. Here is the problem with bloom. This blur needs to be very wide to be effective. In this example the radius on a 1920x1080 screen needs to be 960 pixels wide if the sun is in the center of the screen.

So I have tried to find a good way to solve this problem for quite a while and the simplest and best I could come up with was to downscale the screen then blur it. This system is used in a few scenes and it works somewhat. The blur wont be of a large radius and it will also show aliasing artifacts. It can furthermore quickly become square shaped. But now I finally found a way to do it quickly in a old GDC paper from 2004 by Masaki Kawase and what put the pieces together was the technical paper 'Unreal 4 - The Technology Behind the Elemental Demo'. Using the approach outlined in those papers I can go from this

to this

using about 1.5ms/5% of frame time on a NVidia Geforce 670

Here are a few more practical examples. The first one shows what the effect can do to a simple dull looking cube.

This next one show how easy it is to create a night sky by just placing some random pixels and applying the effect

The road to v2.0

Thu, 04 Oct 2012 14:51:00 Z

Work has been progressing along for the v2.0 release. It has however taken a bit longer than I hoped. The main feature of the release was going to be a completely rebuilt GUI using Qt 5.0. This is so I can remove the dependency on .Net and the commercial GUI control library I used with it. That however relied on that Qt 5.0 actually got released and it has been postponed since Nokia, the previous owner, sold it. Luckily it is progressing and what I have tested so far from the beta that got release not too long ago looks very promising.

I started to rebuild the gui in WPF first but then Microsoft couldn't give a clear response on how they saw the future and what technology they though should be used for real desktop applications (WinForm, WPF, Silverlight, 'Metro'). So I started to look around for a alternative that should be supported for the foreseeable future. That is where I found Qt and comparing QML (Qt) with XAML (WPF) it just boggles the mind of how complicated Microsoft did it's control setup and how simple and easy it could be to create a gui. Qt really succeeded there and used a javascript engine as a base. Something a lot of developers already know or have use for in other projects.

While waiting for the official Qt 5.0 release I have however added some new features to the engine that looks very promising. I'll do some separate posts about these new changes in the future.

As it looks now so will there be breaking changes in the scene format and I want to get as many breaking changes in as possible in v2.0 so I don't have to break the scene format again in some other future release.

New scenes & website updates

Sun, 16 Oct 2011 15:24:00 Z

I'm currently working on v2.0 of the visualizer and it will be a while longer until it can be launched since its a complete rewrite of the configuration and scene editor. Because of this I will start to upload a few new scenes as a normal user and eat my own dog food so to speak by going though the real scene upload system. I have found and fixed a few issues so far and if I find any more I'll correct them too. So if you have a nice scene feel free to upload it.

The front page has received a 'new scenes' section. It should help when trying to quickly see if any new scenes has been uploaded. The scenes page have received a few extra tabs also to filter the existing scenes and quickly find scenes that are not included in the installer.

Since new scenes are now uploaded to the site you have to go to the site and download the scenes manually if you like one. The visualizer already captures the scene specific file extension so it should be a quite streamlined experience. The process should works something like this.

Click to download scene
Go to the folder where the scene was placed or double click on it in the browsers file download window
Answer yes that you want to import the scene
Answer yes that you want to open the configuration window
Go to the scenes tab and you should find the new scene under the 'Imported' branch

The website have also received a few visual tweaks however you need a fairly modern browser to see them.

Lastly the statistics page have been updated with a few new values including memory and core counts.

Plane9 v1.8 has been released

Sun, 05 Jun 2011 18:43:00 Z

The main features in this release is distance field fonts and ColorNext output port.

The distance field fonts creates much nicer font using the same installer size and performance as before. It also allows for creation of outline effect and the like.

The render to texture node now has a 'ColorNext' output. It contains the next buffer to be rendered to. The texture can be used as a texture input further down the graph and thus create mirror effects, 'life' simulations, 2d fluid effects and the like.

Added

Engine: 30 new scenes
Engine: RenderToTexture has a ColorNext that contains the texture that will be reused in the next frame. Can be used for 'ping-pong' effects
Engine: Shatter node
Engine: Added font type to clock node
Engine: Clock uses shader port for font shader
Engine: TextWriter uses shader port for font shader
Editor: Select a template when creating a new scene
Editor: Strings delay port updates for 0.5s before updating the engine. Helps when quickly writing in large shaders
Editor: FPS lock toggle
Engine: CopyToTexture added effect ports to allow filtering during the copy
Engine: Auto skip slow scenes after 5 seconds
Engine: A scene now knows what other scenes it will fit well/not well with

Modified/fixed

Engine: Much improved font rendering using distance fields
Engine: numchars doesn't work in the textwriter expression
Engine: Changed default font size to 1.0 Breaking change
Engine: Clock/Textwriter color port has been renamed to color1 Breaking change
Engine: Updated to Cg Feb 2011 Release
Config: Monitors that didn't exists was shown on the render tab

Statistics

Wed, 11 May 2011 20:57:00 Z

Previously I had to use the steam hardware survey to try to get an idea of what users actually have for machines. But their survey is from gamers that play games. To help in dealing with this lack of screensaver/music visualizer oriented information the anonymous usage statistics was added to the visualizer.

I though I share some of these findings for others to use. So if you want to create a demo, music visualizer or screensaver this information should hopefully match your intended target audience better than the steam hardware survey does.

The statistics are updated once a day and shown on the plane9 statistics page.

Statistics is also gathered on what scenes are most viewed and this did really have a few surprises for me.

The top 10 scenes are as follows

Scene name	Run count	Run time	Average FPS	Number of installations
things\android.p9s	200702	237 days	15	22.93 %
misc\matrixtrails.p9s	493544	179 days	24	24.47 %
particle\starfield.p9s	470176	126 days	28	28.56 %
nature\galaxy.p9s	463027	125 days	22	28.64 %
text\crimescene.p9s	242669	122 days	29	23.68 %
demoscene\metaice.p9s	215094	118 days	20	24.85 %
abstract\colorstorm.p9s	288543	114 days	25	24.22 %
particle\particlespray.p9s	339066	113 days	29	25.10 %
demoscene\totheroadofribbon.p9s	229125	112 days	20	24.74 %
demoscene\chasingthedream.p9s	229974	109 days	20	24.78 %

Run count is counted as anytime the scene is viewed.
Average fps is the average frames per second.
Number of installations is the amount of installations that have viewed the specific scene.

Seems like there is a lot of android users out there since it tops the list. I have to thank Simon green again for allowing me to use his shader for that scene. 15 fps for average fps on a realtime raytraced scene is rather good. It's interesting to see starfield in the top 3. I guess nothing beats the old classics. But what surprised me is that the crimescene scene is in the top 5. Its a scene I was very close to removing since I though it to be quite pointless. But I'm happy to have been proven wrong on that.
We also have 3 demoscene related scenes that got their shaders from various intros. This is exactly what I hoped for. That great intros that would have been viewed once or twice and then forgotten now are running on monitors across the world for all to see. Totheroadofribbon & metaice are created by XT95/FRequency. Chasingthedream is just a slight modification I did on totheroadofribbon.

Now all I need to do is to figure out how to create a scene featuring a android in a crimescene in the matrix while flying though a starfield... then again. Maybe not.

Lastly we have the run count for the various applications

Application name	Run count	Run time	Average FPS
Config	5140	17 days	-
Editor	1863	30 days	-
Screensaver	4912640	11 years 318 days	23
Winamp	18585	409 days	57
WMP	5986	112 days	17

The screensaver is by far the most used with a bit low average fps of 23. The screensaver is locked to run at a maximum of 30 fps since it is a screensaver and should use a low amount of resources. The reason is probably that the complex android scene is the most viewed that has a average fps of 15.
Winamp comes next but with a much higher average fps of 57. Winamp is locked to 60 fps and is usually run in a smaller window so that can explain the comparatively high fps. The lower fps in windows media player is because windows media player handles the frame locking and only calls the visualizer ever so often.
I'm happy to see that the editor is run quite a lot. I had plans on removing it since no one seemed to use it but with this data in hand it will stay.

Shatter

Mon, 04 Apr 2011 18:28:00 Z

On the morning of 26th of March I finally came up with an idea that I could use to join the DBF Destruction competition 2011. The problem was that the deadline was the very same day. The idea I had was to simulate the shattering of glass and as such it was a fairly ambitious idea for the 8 hours that was left until the deadline but I though I might as well try. A while before the deadline I had a entry that I though was good enough to enter the compo with.

The original entry finished 3rd but work continued on the effect and this is the end result of a few days of polishing.

Launch in another window

The process to do this effect is as follows.

Create 4 points and add to a list
Depending on the destruction done on the window
- For a explosion randomize a number of points inside the rectangle formed by the 4 points
- For a bullet hit pick a random point and generate rings with the initial point in the center
Triangulate the point list. Paul Bourkes triangulation works fine for this
From the triangle soup create one shard per triangle.
Depending on the destruction done on the window
- For a explosion calculate the distance from ground zero and apply a force equal to that to each point in the shard list
- For a bullet hit calculate the distance from the ray and apply a force equal to that to each point in the shard list
Use a verlet integrator to simulate the shards particles. The verlet integrator is very simple, fast and stable so perfect for shards.
After the integrator has moved the shards forward a time step move all points out from any collision surfaces
Let the effect run for a few seconds then apply a linear interpolation that takes the shard particles back to their original location to create the rebuild effect
Apply an appropriate shader to the triangle list and the effect is complete

Only one window is simulated and then cloned 3 more times to create the illusion of a fully simulated box.
The first explosion in the video is about 2000 shards in each window the 2nd and 3rd explosions are closer to 30000 per window.

No textures where used or harmed in the making of this entry. It's all procedural.

You can try it yourself. Start it with the "run.bat" file. Most of the scene can be changed in the scenes/shatter.p9s file

Large font support

Sun, 06 Mar 2011 22:13:00 Z

A while back I found a paper by valve on how they have done their font system in Team Fortress 2. I wanted to add such a system to the visualizer but didn't find any good test scene for it. That all changed one day when I noticed the colour clock on delicious. It looked rather nice and since the most favorite scene current is the digital led clock I though it could make a fine addition to Plane9.

After a bit of work it was added and this new distance field font system is one beast with plenty of potential. However the only way to really give the scene creator that power is to allow him/her to edit the shader that is used for rendering and that is exactly what has been added. Slightly more complex but a lot more flexible.

So how did it go with the color clock? Here is the end result of that

Since you now have the complete shader system to play around with you can easily use the various noise functions to make the scene more interesting. For example make the text look like it's made from bubbles.

It's just the voronoi shader function doing its work so one line of shader code.

The end of the last line of text seems to be in a mess because it's using the character expression that exists in the last few versions of plane9. It works by letting each character have its own expression and move independent of all others. The expression used in the screenshot is simply

pos.x = pos.x + noise2(age, charnr*12)*(1-age)*3;
pos.y = pos.y + noise2(age, charnr)*(1-age)*3;

Plane9 v1.7 has been released

Tue, 22 Feb 2011 19:31:00 Z

The next version of the visualizer is hot of the presses and its one very feature packed release.

But before we go into the release details I want to show my appreciation to the paying supporters of the visualizer and announce that 10 scenes are released exclusively for them. Registered users should receive them shortly. You can also log in to your web page account, or register one if you don't have one, and enter in your serial number under your accounts page. This will open up the customer page of the website where you can download the exclusive scenes.
Thanks again for you support.

Here are the changes that have gone into this release
Added

Engine: 46 new scenes
Engine: Editor and screensaver can now react to what is currently playing. So even if you have an unsupported application like itunes or spotify running in the background it will now react to the music! Only works on Vista/Windows 7.
Engine: CopyTexture node. Copies another texture to a new possibly smaller texture
Engine: Blur node can now specify radius of blur
Engine: 2d fluid node
Engine: Multicolor gradient texture node. Can create linear, radial, cone and square gradients with any center or rotation. Very good for color lookup tables
Engine: Lightning bolt node
Engine: Ribbon node. Creates ribbon strips using an expression
Engine: SignalGenerator node that can generate sine,triangle,square,sawtooth and random waveforms
Engine: Noise node creates a tillable noise texture in 1-3 dimensions
Engine: Shader ports have a few, very powerful, predefined functions. See the Wiki for details
Engine: expression ports now have the functions rand() and srand() that uses seed value from a special port and has a much better random than the functions that take in a seed
Engine: expression port new functions time() and date()
Engine: PI,PI2 as define in shaders
Engine: Shader ports define tex1size/tex2size/tex3size that contains the texture size in pixels
Engine: Stop logging after writing more than 100kb during one session
Engine: File texture node handles any texture size
Engine: Support for 1d and 3d textures
Engine: Added tangent and binormal to mesh objects
Engine: Waveform & spectrum supports a mono channel output when specifying channel as -1
Engine: Added Camera FOV to RenderObject node Breaking change. Previous fov was 28, it's now 45
Engine: Anonymous usage information is periodically sent to help improve the visualizer. For details see the faq
Engine: Screenshots now include the name of the scene(s) that where rendered
Editor: New much improved editor for shaders and math. Supports search & replace, intellisense, snippets, goto, unlimited undo and a lot more
Editor: Color ports now show the color and have a picker dialog that can be shown
Editor: Frames per second is shown on the status bar

Changed

Engine: Rewritten blur node
Engine: Rewritten multimonitor support
Engine: Changed expression ports noise1/2/3 to use simplex noise instead of perlin noise
Engine: Resource leak when using renderbuffers like the blur/glow effect
Engine: Disc/Cylinder nodes places a center vertex in the end caps now to make it easier with vertex manipulation on the meshes
Engine: CloneExpressionNode center option now always centers all objects. No matter the distance between each object
Engine: Large visual improvement on texture quality
Engine: Fixed truncation of log if its larger than 100kb when starting
Engine: Oscilloscope node was missing to update one line
Engine: RenderObject scale by aspect now works correctly even if the object is rotating
Engine: Point and Line primitive types works
Engine: All old scenes have been improved with the new glow/blur, fullscreen render node and the like
Editor: Crash when no node is selected and clicking create folder
Editor: Double click on folder showed empty scene
Engine: Expression smoothstep arguments have been changed to match smoothstep in shaders to avoid confusion. Now they are in the form "smoothstep(min, max, value)" Breaking change
Engine: 'Dont render this monitor' didn't cover the screen with a black window
Editor: Crash when clearing rect port values
Editor: Random crashes when editing variables/functions in expression ports
Editor: Moved galaxy, grass & starfields nodes into a 'nature' group
Editor: Nicer property descriptions
Editor: Fixed bug that overwrote port values when selecting another node that had the same port names
Engine: Handle scene load failure better
Config: Remade registration dialog to be easier to enter serial

Deprecated/Removed

Engine: Sin node has been deprecated. Use the new SignalGenerator instead
Installer: Removed noise1,noise2,noise3,noise4,noise5 file textures. Use RandomTexture,NoiseTexture or a shader instead Breaking change
Installer: Removed snowflake file texture. Only one scene used it so not worth the added size. Replaced with simple shader Breaking change

Gradients and the magic they can do

Thu, 06 Jan 2011 19:31:00 Z

I have spent a lot of time working on the visualizer the past few months so the next release is going to be a big one. Quite a lot of new nodes and scenes are going to be included. One of the new nodes that is going to be in the next release is a gradient node. A gradient in itself isn't the most interesting thing in the world but it can act as a component in a lot of interesting effects. For example if you combine a yellow and red gradient with a noise effect you have yourself a fire effect. Combine a gradient with mostly black and a spike of color in it, apply it to a turbulence noise effect and you have yourself a energy beam.

The gradient node handles linear, radial, conical and square gradients that can have a custom center point and it can also rotate the gradient to any angle. This makes for a very flexible gradient setup that should cater for most needs.

Here is an example of the gradient types applied to a cube

The project has been growing quite a bit now. It wasn't long ago it past 110000 lines of code. If you wonder what those lines looks like here is an example to still your curiosity

star->m_StartCol = startColMin + ((startColMax-startColMin) * CRGBA::Rand());
star->m_EndCol = endColMin + ((endColMax-endColMin) * CRGBA::Rand());

The winamp page has another nice big number the project crossed over. Since the visualizer has now been downloaded over 300000 times from winamps web page!

The work it takes to be random

Wed, 01 Dec 2010 20:00:00 Z

Creating flexible programs like Plane9 does present some rather unique challenges.

For example when creating a visualizer that is basically a single effect, like most other screensavers and music visualizers are, you can rather quickly put something together. If it looks ok and gives you the desired effect your done and you can quickly move onto the next feature you want to add. This however doesn't really work when a end user can create their own content so each part can be used in ways you didn't plan on from the start. This is of course both a blessing and a curse.

Randomizer
For a more concrete example of this lets take the randomizer in Plane9. Randomizers, or rather psedorandomizers as is the proper term in this case, is a well studied subject and normally adding one shouldn't take long at all. Using the build in library functions is the easiest option since its already created for you. However then we run into the problem that Plane9 requires two forms of randomizers. One that generates more true random and another that is based on a specific seed value and will generate the same random values each and every time.

The standard randomizer has two things against it. You only have one random function so you can't easily have multiple randomization seeds going at one time. The other thing is that the standard library randomizer is a linear congruential generator. So it doesn't generate very good random values from the start and further more it creates hyperplanes in multiple dimensions. This could be seen if you used the cloneexpression node and randomized the x,y and z position of the objects. Soon enough you would start to see planes form among the points. Here is the problem I mentioned at the start. Normally you could get away with the simple randomizer for the specific effect you wanted. But since this can be used in any number of ways I need to find something better than this. So there in the hunt began.

The hunt for two randomizers
The first one was rather easy to solve. The one where you want as true random as possible since there is a known good randomizer for this. It's called mersenne twister. It's fast and creates very good random values. But this has another problem. It requires a rather large work buffer and seeding it is problematic if you need to do it many times per frame. But if you only need one its very good.

So that takes care of the first problem. The second one however was more difficult. It should also create very good random values but have as small work buffer as possible and be very fast to reseed. I though this was going to be simpler than it was but just about all good randomizer fail in usually both of the requirements.

I eventually found what I was looking for in the xor shift randomizer. It also passes the die hard tests so it should be good enough for a visualizer.

So in the expression ports. If your calling random() you will get a value from the mersenne twister. If you however call rand() or rand(&myseedvalue) you will get a value created by the xorshift randomizer. Hopefully this will now take care of the randomizer once and for all so I too can go onto adding the next feature and you can get what you expect in your own scenes. Random values that are random.