published on 2/26/2015 8:48 PMI got some crash reports after the v2.2 release was live so I must thank you all that sent them in. It was a bit tricky for figure out exactly what had gone wrong but eventually I found the problem. Just about all reports where related either to not having a OpenGL 3.1 graphics card or moving to the next scene too quickly. The first one will now show a message and ask that to update the drivers and the second one wont allow the scene to be changed during a transition. Without the crash reports it would have been next to impossible to figure this out.
I had some feature requests as well and since there where quick and easy to do they made it into this release as well.
Full patch notes
- Show command line help using "plane9.exe -h"
- Show help texts if pressing F1 in windowed and VR mode
- Make sure we have a valid OpenGL 3.1 device and if not show a error
- Disable mouse cursor in full screen windowed mode
- Disable screensaver in full screen windowed mode
- Allow oversized windowes during recording
- Crash if moving to the next scene too quickly
- Failure to start WMP plugin with a qwindowed missing message
- Better scene randomization. Now all scenes should be shown once before reseting scene pools
- Correct colors in recorded movies
- Issue with starting WMP plugin
- Exit better if no Oculus is detected in VR mode
- Attempt for a fix of ghost image on one eye in VR mode
- FPS counter in windowed mode
..and remember. Why listen to music when you can watch it!
published on 2/11/2015 8:48 PMNow Plane9 can check off Oculus Rift support on the todo list. I managed to get my hands on a DK2 last autumn and have been trying it out since then. There are very few good applications out there with VR support. I annoyingly discovered that I’m very sensitive to VR and quickly gets simulation sickness. For example when trying any of the rollercoaster demos I usually can’t even get down the first hill before I have to take the kit off. But as long as I, as the vr character, am still then I don’t have any issues.
So this also means that the VR compatible scenes for Plane9 are geared towards this. In just about all of them so are you still while you can look around to see what happens in the scene. This should make for a rather good VR experience even for beginners. Something different than the few other VR music visualizers that exists is that Plane9 uses both transitions and uncommon postprocessing effects like embos or posterize that can give the scene a completely new direction.
What’s quite interesting is the new feelings you can get from using a Oculus Rift. Take the 'Music star' scene. If you leave it running for a short while with some music playing, then soon enough so will you realize its just you and the particle field/life form in this world. What can then make a rather disturbing feeling is when the particle field in front of you dies with the music. Leaving you all alone in this completely black and silent world. It’s certainly not a feeling I have even had a program made me feel before.
Some other goodies in this release is support a new threaded engine for a smoother experience. There is also now support for 150% and 200% render targets if you have the GPU to spare for increased quality. Plane9 now tells Nvidia Optimus to use the dedicated GPU, so if you have such a laptop you might see a large performance increase. I also discovered that on multimonitor system so was the total render area rendered for each monitor. This means that if you have 3 monitors you could see an almost 200% performance boost. What took a lot of time in this release was the internal change to use Qt for window management, changing to GLM for math and adapting the OpenGL’s right handed coordinate system and upside down textures.
Here is the full change list
- Oculus Rift support! VR mode will treat background and foreground scenes as standalone.
- Added support for 150% and 200% resolutions for improved quality for the ones that have the GPU to spare.
- Run updates on a separate thread
- Preload some shaders to reduce scene switching latency
- Use Qt as main window manager
- ScreenNode: Added look at
- Change scene using space in windowed mode or right arrow in screensaver mode
- Use GLM for math
- Follow OpenGL and use right handed system with Z going out from screen
- Tell Nvidia Optimus to use the dedicated GPU
- 12 new scenes
- Added ability to start a playlist in VR or Windowed mode from the configuration screen
- Collect total and free GPU memory if we can
- SoundTexture: Increase quality by using 16 bit texture
- SoundTexture: Accumulate result for a better result
- Increased quality of the fast noise
- All screens were rendered for each monitor in a multi monitor setup.
- Memory leak on layered scene if moving to the same scene
- Large increase in quality of earth textures. Now requires at least 100Mb GPU memory to show just that scene
- Qt 5.4.0
- Last scene wasn't shown in the configuration screen
- Removed FreeImage library. Used Qt instead
- Removed clover and blobbies
published on 9/17/2014 8:21 PMSo today marks the day v2.1 got released. It's mainly internal changes that have gone into this release where the separation between CPU and GPU work has been much more cleanly defined. This is partly so I can speed up rendering by sorting all render work but also to make it easier to change over to Qt rendering and OpenGL shaders.
Some bug have also been fixed as reported by the crash reported and by email/facebook. This release also now correctly captures up to 18 channels of sound. Before if you used for example foobar2000 with a multichannel output plugin to get surround from your stereo music or from you true surround music then Plane9 would only capture and analyze the left and right speakers. Now he will capture all channels and analyze them. This should hopefully make for a better sound response in these cases.
Quite a few scenes got updated. Specially with bloom and gamma correction. Gamma correction can change the scene quite drastically. Just a few new scenes where added in this release.
The incomplete change list
- Support analyzing sounds from the default recording device instead of 'what you hear'
- Support cubemaps in folders
- EffectNode: Allow setting alpha blending mode seperatly
- Added a few Spherical Enviroment Map Textures
- Added a few cubemaps
- Enable seemless cubemaps
- Increase max scene time in configuration windpw
- Updated command line options. Now supports
width,height, rectime,recfps, music,rand, --scene
- Added foggy and foglights scenes
- Capture up to 18 channels of sound and combine them into left and right. Before all channels except left and right front speakers where ignored.
- Sort scenes in configuration window based on last modification time so newly changed scenes are shown first
- Updated a lot of scenes with bloom/gamma correction/new lighting/..
- Fixed issue where the main monitor must be to the left of any secondary monitors. Thanks to all who reported this.
- New shader based noise functions that are 30% faster than the old one
- Diffuse textures are now loaded as sRGB textures. So any scene using textures must gamma correct the final output to look correct.
- Changed to a PaintJob based engine design for cleaner seperation between CPU and GPU work
- Qt 5.3.1
- Fixed a few crashes as reported by the crash report system
- Corrected check that verifies that frame buffers are supported
- The following scenes "Tunnel", "Neon world", "Cell rotation", "Cube sin", "ChasingTheDream", "into the matrix", "rainbow wave", "signal" since they looked bad/where boring
published on 2/16/2014 2:18 PMAfter almost 3 years Plane9 v2.0 have been released and I couldn't be happier that it's finally done.
It goes without saying that this release took a lot more time to complete than I had planned. However on the other hand a lot of things got into this release that I initially didn't plan for since the main feature, the configuration rebuild, took a lot of time. So this is one feature packed release.
I also wanted to get in any future breaking changes to the scene format in this release however I had to skip this since there is still a lot of work left. Mainly that the whole editor needs to be rebuilt to handle the new scene format in a better way so until that time the editor wont be included in the releases. Because of this all user uploaded scenes have sadly been removed from the webpage until the new editor is ready since the old scene format wont work with the new configuration window.
The major new changes are
- Completely rebuilt configuration
- Transition scenes
- Always active FXAA for cheap AA
- Sound normalization in screensaver mode
- The software is now free so there is no need to get a license key to unlock any extra features. A big thanks goes out to all that have supported the software so far!
A incomplete list of changes follows
- 100+ scenes and 35 transitions
- Engine: Support transition scenes
- Float buffers to render textures
- Engine: FXAA antialiasing
- Engine: NormalDir factor. Use to create shaded particles.
- ParticleNode: Turbulence Affect Size
- ParticleNode: Velocity damping
- ParticleNode: Time scale
- ParticleNode: Color Var
- ParticleNode: Velocity from motion
- ParticleNode: Velocity random
- ParticleNode: Direction
- ParticleNode: Ribbon tail
- ParticleNode: Option to store particle alive time in alpha
- ParticleNode: Floor collision
- ParticleNode: noise flow field
- Engine: Expression: Let Spectrum average part of the spectrum
- Engine: Globaly unique id and parent id to scene format
- DiscNode: Add double sided and phase
- CylinderNode: Add slices & rings, center
- RenderToTextureNode: Float buffer support
- CubeNode: Allow to define tessellation along X,Y and Z axis
- Engine: High quality simplex noise functions added to shaders
- Engine: Add better way to record a set of scenes with a specific song
- Engine: Send in 'render size' to the shaders
- Engine: Add destination size variables to effect nodes and 1/width,1/height in all size variables
- Engine: Allow scenes to be tagged
- Engine: License to scene format
- Add crash hook so issues can much more easily be reported
- Engine: Particle will interpolate emitter position to handle fast moving emitters
- Engine: Spectrum values supports damping
- RenderToTextureNode: Effect input
- LightningNode: WidthReduction
- RenderToTexture: Possibility to change how long between each update of the ColorNext from the current Color texture
- Config: Option to specify how often a postprocessing scene should be used
- Config: Remade the whole configuration window to be easier to use
- Engine: Improved the scene randomizer so it will always go though all scenes once before being allowed to pick the same scene again
- Engine: Default max FPS is 60hz
- Engine: Remade the scene format to a zip compressed storage format. Also includes screenshot.
- Engine: Increase the resolution of the Font texture to 512x512
- Engine: gWIT, gVI now takes scaling in the original matrices into account
- Engine: A CPU with SSE2 is required (Any cpu after 2005 should do)
- Engine: Grass: Fixed rendering issues
- Engine: Optimized mesh handling
- Engine: Improved loading/saving time of scene files
- Engine: Store screenshots in users "Pictures" folder so they can easily be found and for example used as desktop wallpapers
- Config: Rename scene collection to "playlist"
- Scene: Corrected the synchronous column rain behavior that occurred in the Matrix trails scene.
- Scene: Much improved lightning in electroSphere
- TorusNode: U mapping has been inverted so textures are applied correctly by default
- TorusNode: Added Arc and Phase
- Engine: Move previouslayernode to 'special' group
- Engine: Change expression 'clip' to 'clamp' and the function of 'clamp' to 'wrap'
- ClearNode: Default clear nodes to set alpha to 0.0
- Engine: Occasional occurring sound capture initialization error
- Update existing scenes to use v2.0 capabilities better
- Engine: Handle meshes with over 65525 vertices
- Engine: Automatically normalize the sound
- Editor: Temporarily removed since all shaders will be changed to GLSL in a future version
- Config: Don't allow changing display mode. The resolution swap is too disruptive
- CloneNode: Removed
- Engine: Removed scene name stored in scene files. Use filename only
- Engine: Remove camera input from RenderObject
- Engine: Dont send detailed file statistics any more. Too much data for little gain.
- DiscNode: Remove 'End' input
I hope you enjoy this latest version as much as I do!
published on 1/5/2014 11:53 AMI have come to the realization that the editor needs to take a timeout and will be skipping the v2.0 release. This decision wasn't made lightly but it will make a comeback in a future version. As to why this is so here are the reasons for the curious.
- The shaders will be changed from CgFx to GLSL. This is nothing I can fully automate so I don't want more scenes to be created using the old shader format that the creator of the scenes need to manually convert.
- I don't want to force users to download and install .Net just for the editor
- Mixing .Net and Native code prevents the usage of some windows features
- I am going to convert the editor to Qt so everything is native (No .Net needed). Because of this some new features are not yet as editor friendly as I would like them since the plan is to fix them in the Qt based editor.
- The current editor is using a commercial GUI library that is rather large
This means that if you do use the editor in v1.x you should not install v2.0 since you wont be able to edit your own scenes.
published on 12/21/2013 9:42 PMSince the first version of Plane9 I have asked for a minimal fee for anyone that wants to support the program. The idea was that you should get the program for free and be able to use it for as long as you like. If you however want to support the software you can get a key and some small reward that isn't critical to the functionally of the software. This idea came from that I dislike the normal crippled software license schema that most others use where you get to use the software but its so crippled that it's hardly useful, stops working in 10 days or shows a registration warning every minute.
With my choice of schema the requested money amount must be low since the user already have the fully functional software. For example I ask for 5$ while most others take 20$-30$. However asking for a small amount of money from a lot of people also means more people to support for a small return. I can't say I have had a lot of support requests, most of them relating to spam filters that are a bit too eager, but there have been a few and all of them take away from time that I could spend improving the software.
To this end I went back and tried to rethink the license system. So I wanted the license system to contain the following
- No limits to the software
- No license keys
- Commercial use of the scenes would require compensation to the author of the scene if they so choose to require it
The other change that will take effect is that all scenes comes with their own license. This is so the author of the scene can decide how you are allowed to use their creation. If they want it to be placed in the public domain they are free to do so and if they want it to be free for non commercial use then they can do that to. The latter license is what most scenes will use that comes with Plane9. Some scenes are based on others work that have their own license and they wont be allowed to be used in any form of commercial application, they have the 'norelicense' tag attached to indicate this.
The idea is that if you want to use a scene where you will be paid to show the scene then the actual creator of the scene should also gain something from it. But if your a home user or even a corporate entity that just want to use the scenes on all the computers in the office then your free to do so and you wont feel that you are missing out. Using this system you are also sure the scene will work before asking for a commercial license of any scene since it wont be limited in anyway.
This means that if you like to use a scene created by me you can get in contact for license requests. Just make sure the scene in question doesn't have the 'norelicense' tag attached to it. If it does then you need to contact the original author that will be written in the description field. If you get his/her permission to use the original work commercially then you will be allowed to use the scene from Plane9 as well.
Lastly I want to give a warm thank you to all that became supporters so far and I wish this decision doesn't diminish your reason as to why you became a supporter in the first place.
published on 10/20/2013 7:20 PMBack in 2011 I started to convert the visualizer to be DirectX10 only. During that time I also started on a blog post as to the reason why I wanted to make this switch since I figured the question would be raised. However in the end this conversion never happened. The reasons that I remember of why this change never happened where
- In Cg DX10 there is a bug where if you try to assign a texture to a sampler that isn't actually used in the shader Cg will crash.
- cgValidateTechnique must be run on a shader before using it. Otherwise we get strange crashes like trying to set a textureparameter and it crashes with access to memory 0x000040
- Cg doesn't seem to clear the texture resource if we use one. So if we use a render to texture DX10 will warn that its still bound when we set the new rendertarget
- During that time, and still, Microsoft has stated that there will never be a DirectX 12. There has however been new 11.x releases since.
- WebGL started to make it's entrance and it's based on OpenGL and GLSL
- DirectX is platform specific
I still however think the points below are true so thought I post this for anyone that trying to figure out what API to use.
The original, slightly updated, post follows
According to the statistics I have so are only 20% of the users using XP. The rest have DirectX10 already since it comes with Vista and Windows 7 out of the box.
- Latest gfx card drivers must be installed to get any hardware accelerated form of OpenGL support at all while Vista & Win7 comes by default with DirectX10 drivers. So for most users using DirectX 10 will just work.
- Its not uncommon for the OpenGL drivers that do exists to not work correctly
- The programming interface for OpenGL isn't the easiest to work with since it was created many years ago and no real cleanup has been made. (OpenGL 3.1 has done some but I can't require it)
- Documentation for OpenGL is lacking
- There are numerous ways to do the same thing. For example rending a triangle. It all started with glVertext then they added another way and another and another. Finding out to correct way that works on all/most graphics cards is very difficult
- Even the need for a page like common opengl mistakes is bad. Don't get me wrong. That page is worth its weight in gold and anyone doing OpenGL should read every single line. The problem is, you really shouldn't need a page like that. The API should warn you when you do stupid stuff.
- OpenGL has extensions and a lot of them. In DirectX10 "everything" just exists and if it doesn't your driver/hardware wont be defined as DirectX10 capable. It's a lot easier for me to notify a user that "no your hardware is too old" than to try to debug some strange issue that later turns out to be because some extension wasn't properly supported.
- DirectX10 has a fast software driver that I might find a use for
- Lack of good tools. The now free gDEDebugger exists and helps but its far from the NVidia line of tools for DirectX
- DirectX10 support true multimonitor across multiple graphics cards.
- DirectX10 supports multithread applications out of the box so multiple threads can safely do render calls.
- DirectX10 contains the shader compiler so you know the shader code will compile correctly. In OpenGL each driver writer is responsible for creating his own shader compiler with different problems and varying levels of error reporting.
Of course everything isn't just pretty flowers and red roses. DirectX10 is created by one provider, Microsoft, that has full control of it and can do what they want. It also only works on Windows so porting the visualizer to Mac or Linux would be much harder.
Regarding the drivers for OpenGL you might be wondering how bad that actually is. Lets put it this way. Most/All new browsers now support rendering 3d inside a webpage. From the start they all used OpenGL but later they found out that many manufacturers OpenGL drivers where so broken that they had to switch to use DirectX. So now they convert all shader code from OpenGL format to DirectX format for this very reason.
published on 9/30/2013 8:26 PMLast year while waiting for Qt 5.0 to be released I managed to add scene transitions. This was a feature I had planned for a future release but seemed like a fun thing to add while waiting for Qt 5.0. In v1.x you just get a abrupt scene change when moving from scene to scene. The issue with this is that you don't get any form of continuation between the scenes. The scenes will always be independent so creating a workable continuation is difficult. For example if you create a normal demoscene production you can follow a object as it goes from scene to scene or at the very least keep the same color scheme. This makes it feel like everything belong together. With completely independent scenes this is a lot more difficult. However the new transitions scenes helps quite a bit.
It's a very simple but powerful system that at it's core is just a normal scene with a transition node that outputs two textures. One texture is the current scene and the other texture is the next scene we want to move to. The only imposing limits are that at time 0.0 the from scene should cover the whole screen and at time 1.0 the to scene should cover the whole screen. It's then up to the transition scene to create some interesting way to move from one to the other. It can be as simple as just a cross fade (return lerp(tex1, text2, time)) or using 3d and wrapping it onto a 3d cube that rotates around to reveal the new scene as in the following screenshot that shows off the Cube Switch Transition.
Since it's just two texture the possibilities are just about endless
Of course rendering what can be up to 7 scenes (Two 3 layered scenes and the transition scene) can be quite taxing. To speed this up you can tell the visualizer to render the scene texture in lower resolution. Normally rendering the original from scene at 100% and the scene we want to go to at 50% seem to be enough and you don't notice too much of this lower resolution. As soon as the transition is done the new scene will be rendered at it's full resolution.
This new system greatly helps the visualizer to be something that you can just start at a party and let it run while continuously creating something that you want to see what comes next.
So far there are a bit over 30 transition scenes in v2.0 that should provide a bit of a variety, for example the Random Circle transition is one of them.
published on 7/9/2013 8:34 PMThe plan was to get v2.0 out the door before the year end. That didn't turn out as I planed. Mainly because of that I waited for Qt 5.0 and a lack of time. Qt 5.0 has now been released and I have been able to properly start the work on the new configuration window and lets just say that Qt 5.0 is amazing. I have worked with traditional windows, MFC, WinForms, WPF, Silverlight and Html before and when it comes to creating a dynamic user interface Qt blows them all out of the water in terms of flexibility, amount of code you need to write and speed. The model system however is a bit difficult to work with but they seem to be on track to ease that burden.
However I have also come to the realization that rebuilding the editor in Qt will be too much work for v2.0 so the editor wont be included in the v2.0 release. It will be re added in a release following v2.0 so I have time to properly rewrite it. Also since there are some major changes to the scenes I rather stabilize them properly before anyone else starts making scenes that then might be hopelessly broken when the release after v2.0 comes. Because of this I have also now removed the upload functionally on the site for the time being.
I really like open formats and the Plane9 scene format is no exception. It's just plain old XML. However it's also very limited since it's just xml and adding anything else to the format is difficult at best. So after much deliberation on what the best course of action is regarding the scene format I settle on a new one. It's to compress the scene in a zip container so it still uses a open format but can much more easily be expanded. The main issue I had was that I need to include screenshots and thumbnails into the scene format itself so when someone uploads a scene the screenshot is already in place. Currently this is a manual task and the reason why it takes a while for me to approve new scenes. Using this system the scenes can be auto approved! Furthermore the images can be used by the configuration window for great effect as can be seen in the current state of the configuration window.
It also open up the possibility to include external resources with a scene file. Say if a specific texture is required.
Another change to the scene format is that it will now also contain tags. These will be used both in the configuration window and by the website to form a uniform set of tags and help you quickly find the ones you want since there is quite a lot of scene to choose from now.
published on 2/25/2013 9:02 PMBloom 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
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