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
published on 10/4/2012 2:51 PMWork 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.
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.
published on 10/16/2011 3:24 PMI'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.
published on 6/5/2011 6:43 PMThe 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.
- 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
- 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
published on 5/11/2011 8:57 PMPreviously 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.
published on 4/4/2011 6:28 PMOn 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.
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
published on 3/6/2011 10:13 PMA 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;