Category Archives: Balder

GeekRider – the goal, technical perspective

As I briefly mentioned earlier I am endeavoring on a project which is going to demand a lot from me physically, but also from a technical perspective. I have a lot of things on my plate, during daytime I’m 100% engaged with work at clients, nighttime is the time I have to squeeze in a lot of activities into. For one, I have two kids that needs my attention – and I have a golden rule of engaging with them from the time I get back from work till they’re in bed. This leaves some 2-4 hours left per day to do all the things I do. I therefor have to be smart with my time and make the most of it. Adding things into the schedule is hard and if I add something, it in general must have a synergy with something already in my schedule. In my schedule I have a couple of open-source projects that I focus a lot of my energy on; BalderBifrost and Forseti, so pretty much anything I put in must relate to these in some fashion. Geekrider arose concretely from this need of synergy. I need to focus more on physical exercise and brought in Geekrider with the synergy of pushing forward development on the open-source projects I’m involved in forward. Balder will hopefully serve the purpose of 3D visualization and bringing forward the a few features that I want to have in that project. As a general web platform, I could have gone for anything already out there, but I wanted to push forward features in Bifrost, I therefor decided to build the site from scratch on top of it and also push into the cloud by hosting it on AppHarbor. Since the site will become very JavaScript intensive, and I pretty much get allergic reactions when I don’t write tests or BDD style specifications for my code, the last project also will get some love; Forseti. The reasoning behind the project is that most test runners out there has so many moving parts in the form of dependencies to get up and running and they’re also very focused on running things in a browser. Forseti is aiming towards something very different, a headless runner for JavaScript tests based on Env.js not using by default any browsers to execute the tests/specs.

One of the goals for Bifrost is to make it easier for developers to create rich web based applications, promoting good software development practices. Today, the RIA space is rapidly changing and for the most part moving away from plugin technologies such as Flash or Silverlight and focusing more on the open standards found in HTML, CSS and JavaScript/EcmaScript.

From a fronted development perspective, Bifrost is taking on this latter part. Traditionally one would compose the resulting web page that is handed over to the client on the server. Multiple solutions exist out there for doing so, and specifically in the .net space, ASP.net and its derivatives are the most popular ones. Rendering, as this is often referred to, adds an extra load onto the server – not only is the server responsible for dealing with the request from the user, wether it is getting data or performing an action, but it also has to transform the result into something the client can show. On top of all this, it has to deal with security. This pattern is a very proven pattern, but in my opinion not the pattern we want to be doing moving forward, and therefor Bifrost will focus on a different pattern. Sure, Bifrost will not only be compatible, but also support out of the box the traditional route – but for now in an opinionated fashion by only supporting ASP.net MVC. The technique that Bifrost will be focusing in on is the Single Page Applications, were you basically hand over the “rendering” to the client and let the client compose the page by swapping in and out elements at runtime. This is in fact nothing new, ever since AJAX became the big thing, we’ve pretty much been doing this – but only for parts at a time and even letting parts of our page be swapped out for new versions being rendered by the server dynamically.

Bifrost will have a composition technique that is based on, as most things in the framework, conventions. The focus will be on Features and one can point to a feature simply by adding a <div/> tag and give it the attribute data-feature=”[name of feature]”. Based on the configurable convention, Bifrost will find the necessary files representing the feature. Looking at the page from Geekrider as it is at the time of writing this post, we’ll have the following.

NewImage

So, back on track. Now that we have this, what is the next logical step?  Up till now, Bifrost has been very server side rendering focused, sporting an extension for ASP.net MVC and taking advantage of that stack. That is about to change, or should I say, the fact that it has been the only way to use Bifrost is about to change. A set of REST endpoints will be exposed from Bifrost, enabling any client to interact with the framework. From a Web developer perspective, this is not good enough, we’re therefor working on bringing in a JavaScript library that will just nicely integrate with all this.

In addition to the goals summarized thus far, I’ve also got another goal for me personally; I want to become more productive with tools other than what I’m used to. I recently bought a MacBook Air, an impressive piece of hardware – but it doesn’t sport the same specs as my MacBook Pro or my iMac, I’ve therefor decided not to put any virtualization software on it to run Windows. This means I have to start using other tools than Microsofts Visual Studio for my development. For .net development, I’m for now using MonoDevelop and for general HTML, JavaScript and CSS development, I’m using TextMate. My long term goal is to be using TextMate for everything.

Summarizing, Geekrider will be the proof of concept for features added to Balder and Bifrost – driving forward with new thoughts and ideas. I will try to blog about the progress as much as my schedule can permit. This means I should keep myself from playing around or doing unnecessary stuff.

 

Balder – where is it, and where is it going?

In 2007 I started something called Balder, a 3D engine for the Web using Silverlight. Back then with Silverlight 1.1 Alpha and later 2.0, there really weren’t that many options to make it especially feature rich, nor fast. My first goal when I started this whole thing was basically to achieve 3D rendering on the Web across multiple platforms (Windows + Mac, later Moonlight on Linux) and have a declarative programming model for 3D. This is still the motivation for Balder; to be cross-platform on the Web and be declarative in its nature. I’ve never had the idea of being a 3D engine to compete with the big engines out there that are both free and commercial, this has been partly a research project for me to learn Silverlight properly from the ground up and also maintain a foot within the graphics programming industry which I still hold dear. Even though my day to day job is something completely different these days, I’ve always had side projects that kept me somewhat close to what was happening in the games industry that I left behind some 10 years ago.

Back in 2007 with SL1.1 and 2.0, you basically had to either built on top of the built in primitives, which were super slow or you had to do magic like create yourself a realtime PNG encoder and draw pixels manually with code and then hand over the generated PNG to an Image control inside Silverlight.

With Silverlight 3 came along the WriteableBitmap that enabled to skip the PNG step and Balder started to pick up performance and features were a lot easier to create. This story continued through for Silverlight 4 and Balder has received many a make over of both its rendering pipeline, but also internal architecture while I’ve learnt more and more in-depth of how to do things in the best way inside Silverlight. With the announcement of Silverlight 5 came a long a low level interface for drawing 3D utilizing the GPU sitting inside your graphics adapter. Finally Balder could shine with great performance and still maintain its declarative, Silverlighty way of doing things.

For SL5, that was the gold-plated story – the reality is quite different. Balder needed yet another architectural make-over in order to achieve hardware rendering with Silverlight. The main problem being that rendering now had to be done on a specific rendering event that sits on a completely different thread than the regular UI thread inside Silverlight. This poses quite a few problems when Balder is built to be declarative and have all the binding capabilities that Silverlight offers.

Most of the architectural change has been done – but far from being finished. There are still some holes that needs to be filled internally in Balder that has to do with code-smell basically. At one point in time, development of Balder went forward too fast – and code-quality was during this period suppressed in favor of number of features per day that could be implemented. I know, I’m not proud, but it was the reality for the period that things needed to get done and they needed to be done fast. Another aspect of Balder development has been the lack of being able to properly test things with unit tests all the way. Quite a few times I’ve tried to do the effort to retrofit tests without succeeding all the way. Silverlight is basically too hard to test if you want to be lightweight with your tests. Sure, there are things out there that mock out the runtime and you can make most of your code so that you don’t have dependencies to the Silverlight runtime and just run the tests on the desktop framework. I’ve done all the techniques out there but never been happy with the flow. This is an ongoing things.

Are we there yet?
Phew.. So, were are we at?  Balder has a default branch which is still on the SL4 level where I left off over a year ago and there is a parallel branch for the SL5 parts and all the refactorings and changes that had to be done to bring Balder to SL5. There are some bugs and quirks in it and development is not going as fast as I would have hoped. There are a few reasons for that, one is the lack of tests and not a good story for retro fitting them. I’ve started doing it with MSpec and writing in a specification way instead, made it a lot easier but there is still a lot of work to be done there. The second reason things are going slow is that Microsoft has yet to come up with a good cross platform story for the 3D bits, in fact, thus far there is none – it only works on Windows for now. I’ve been probing them to get an answer, but haven’t gotten one yet. To be honest, it has for a while halted my motivation for moving forward at the same pace, until last week when I had a breakthrough in rendering that increases performance quite a bit and also the quality for software rendering, which will then prove as the fallback solution for Mac.

Deferred software rendering

In addition the latest versions of the most used browsers on Mac supports WebGL, which is something that can be used directly from Silverlight as well. After getting the software rendering fallback done, I’ll start looking at the WebGL approach as a second fallback scenario for those browsers that supports it.

Another aspect of the SL5 codebase is that Microsoft changed security from the beta released at Mix to the version released at Build which lead to in-browser shaders not being allowed to do loops. Balder supported 5 light sources with the pixel shaders I wrote for the Beta version, but can only do one with the latest version of SL5. In order to fully support an arbitrary number of lights I’ll have to move over to deferred rendering and that has quite a few implications on how Balder works as well. But a job I’ve started and will make it the default rendering method across the board for now.

But all that being said, there are some critical issues that needs to be solved – they are issues that really makes it hard for me as a developer to get the velocity I want, so I will be going back and forth researching and bringing back the code quality I want to feel comfortable.

 

So, what about the tag-line of Balder and devices?
A couple of years ago I saw the opportunity to bring Balder onto more devices and started optimizing the code-base and extension points to be able to bring to things like the Windows Phone 7, iOS, Android and others. This is something I’d still love to do, but will not focus on it for quite a while. There is still too much work on the Silverlight side to justify focusing on devices just yet. There is a version of Balder for WP 7, but not for the latest Mango and to be honest, WP7 is in fact the hardest of these devices to get any proper rendering on since one is not allowed to write shaders for that device.

 

Conclusion
As you might understand, Balder is still active – not just at the same pace as before, hoping to pick this up a little bit moving forward. There are some code-rot that needs fixing, increase of code quality and things like that holding back development a bit, but also technical challenges with the platform. Since I’m relentless with the cross-platform part and am not willing to budge on it, I will focus my energy on getting that working and hopefully working good. If this was a commercial product, I would probably not go to the lengths I am to get the cross-platform parts working, but one has to remember that my original motivation for going down the road of creating Balder in the first place was based upon cross-platform – take that out and personally I will lose the biggest motivation I’ve had with the project.

I’ve established a Trello board were people can see what I’m focusing on these days for Balder.

 


Balder gets donation from NDepend

Today the Balder project was lucky enough to get a donation from NDepend. Yet another tool that will be used to improve the code quality of Balder.

Thanks a lot to the people at NDepend for the donation.

PoweredByNDepend

Balder – 0.8.8.9 very close

Its been a hectic week – but finally most of the pieces are falling into place for the next release. There is only a couple of minor features I want to add before calling it a release. Meanwhile, I’ve updated the samplebrowser and released it as a sneak peak. I’ve replaced the Material Picker sample with a Material Editor were you can actually edit all the properties of the materials and also the lights added to the scene.

Here’s a screenshot of how it can look like when configured with all features enabled:

Balder_0_8_8_9_Preview
If you’re having trouble with the SampleBrowser on Safari or Chrome on the Mac, this is something I’m investigating. I’ve tested it with all browsers on Windows and Mac, but these two had some issues when textures were involved on my machine. Will look into it more carefully before releasing the next version. The odd thing though, it worked with the samplebrowser compiled as debug.

 

Clarifying Balders feature set

Hopefully I’m not forgetting anything (probably am) – but below is a clarification of what features Balder has.

Coordinate system

Balder uses a left-handed coordinate system – currently there is no way to change this, but there are plans for opening up for any coordinate system.

Nodes

  • Interaction – one can enable interaction on any nodes and they can be interactively manipulated during runtime
  • Position coordinates
  • Rotation coordinates, in angles for each axis
  • Scale coordinates
  • Hierarchical rendering of nodes

Scene

  • A Scene contains objects, any Balder object implementing the interface INode; Lights, geometries, sprites

Viewport

  • Defines a clipping area on the screen, coordinate relative to its container

View

  • Camera
    • Position
    • Target
    • Field Of View

Sprites

  • Flat image based objects that exist in 3D space – they are rendered along with other 3D content and positioned and scaled correct according to their 3D space position.

Geometries

  • Box – simple box with dimensions
  • Cylinder – top and bottom dimensions can be specified independently
  • Ring – inner and outer circle dimensions can be specified independently
  • ChamferBox – simple box with a chamfer segment
  • HeightMap – a plane that consist of a set of vertices (points) that can be manipulated by its height
  • ArbitraryHeightMap – a derivative of HeightMap, but its plane is arbitrary
  • Mesh – a complex mesh which can be loaded from a file

Other objects

  • Container – not renderable itself, but can contain any Node in it – hierarchically

Assets

All data loaded from disk or elsewhere is known as Assets. There are Asset loaders for file types, you can even create your own Asset loaders quite easily. For Silverlight, there exist today a limitation which only allows loading of assets found in the XAP file – meaning that any asset added to the project must be a Resource in the XAP file. This is being worked on and will in a future release be more flexible.

  • ASE file – supports 90% of the Autodesk Ascii Scene Export format for 3D objects
  • Experimental support for Demoniak3D format
  • JPEG, PNG for Images

Assets are cached in a content manager, which means that if you load the same asset twice, it will clone the first one.

Lighting

  • OmniLight – non directional light, emits light in all directions
  • DirectionalLight – emits light in a specific direction, without any starting point or ending point
  • ViewLight – view dependent light that will always emit from the view and into the Scene

Rendering

  • Z buffered rendering
  • Flat shaded – single color faces
  • Gouraud shaded – color can be specific on each corner of a triangle
  • TextureMapping – perspective corrected, gouraud shaded.
  • Lines
  • Passive rendering mode – renders only when there are changes
  • Bilinear filtering
  • Face-culling – do not render faces/triangles facing away, can be controlled via Materials
  • Frustum-culling – objects not inside view will not be rendered – increases performance a lot

Materials

  • Diffuse color
  • Diffuse map
  • Ambient color
  • Specular color
  • Reflection map
  • Opacity for the different maps can be specified

Imaging

  • Supports PNG and JPEG
  • For textures, you must use images with dimensions being power of 2 (2,4,8,16,32,64,128,256,512,1024 and so on)

Input

  • For Silverlight; mouse events are supported (MouseEnter, MouseLeave, MouseMove, MouseLeftButtonDown, MouseLeftButtonUp)
  • Manipulation events for all Nodes to make it easier to interact with objects

Debug visualization

  • Bounding information
  • Show vertices

Statistics

  • Rendering timing
  • Amount of faces being rendered
  • Amount of objects being rendered

Execution

  • Actor system with statemachine for actors in the scene
  • Game – base class for any game

Silverlight / Windows Phone 7 specifics

  • Full XAML support – you can declaratively do everything that Balder can do in XAML
  • Specific CoordinateAnimation that can be used in storyboards for animating properties on Nodes
  • NodesControl / NodesStack – databindable controls that be bound to any source with NodeTemplate to specify its representation on screen. Similar to ItemsControl found in Silverlight.


Balder – vertex colors

I’ve been working lately on a demo that is for gaming a lot more realistic than the spinning teapot or box that one sees in the sample browser for Balder. A friend of mine Peter Rosenlund, an excellent graphics artist, gave me a 3D model of a city that I can use for that (thanks a lot!!).

In the 3D model, he had applied static lighting manually in 3DSMAX by painting the Vertex colors – a feature I had not implemented in Balder. After a few hours yesterday and this morning, I got it all up and running and I must say it looks kinda nice.

Balder, rendering city without vertex colors applied:

Balder_Without_VertexColors

Balder, rendering same city with the vertex colors applied:

Balder_With_VertexColors

 

Balder 0.8.8.9 coming

Things are moving fast these days with Balder and I am closing in on the next release already. Keeping up with my target pace.

At this point these are the things already done or is in progress for the next release:

  • New Skybox, utilizing built in Silverlight perspective projection, which can be hardware accelerated
  • Perspective correct texture mapping – previous version had only affine texture mapping
  • Bilinear filtering for texture mapping
  • Performance boost for the entire rendering pipeline
  • Better, faster and more accurate lighting
  • Subpixel rendering
  • Vertex-shader like functionality for SIlverlight
  • Multiple “Games” in one page
  • Multiple textures during rendering
  • Semitransparent / alpha-channel support for texture mapping
  • Introducing a control for no-game centric applications; Content3D
  • A lot of bugfixing


Balder on Windows Phone 7

BalderOnWP7
After a couple of days of work – actually more like a couple of hours over a couple of days (sneaking away during vacation to feed my computer abstinence), I’ve managed to port Balder to Windows Phone 7, a couple of quirks needed to be fixed – like this one.

For now it uses the same software rendering engine as the Silverlight one. Needless to say, its not exactly the most optimal solution, but at least it proves that most of the code runs across both Silverlight and Windows Phone 7 without doing much to it.

The next goal is now to implement a fully hardware accelerated version of Balder for Windows Phone 7, using Xna.

Wish me luck. 🙂

 

Balder post 0.8.8.7 release – What now??

After quite a hectic 2010, a lot of work at my daytime job at Bouvet, taking on freelance work with projects utilizing Balder and maintaining Balder itself – I finally managed to get a new binary release out the door. Feels like a ton has been lifted off my shoulders.

You might be asking yourself, when is the next release – christmas time? What will it contain?
Lets start with the first one, when. I can’t exactly promise an exact time for that. But what I’ve been working on lately is a build server that will aid me in getting binaries out the door faster.

IMG_0008
I’ve put together a dual core Atom based machine (to the left), that will be my continuous integration and nightly build server. Its running Hudson, a Java based continuous integration server software together with a NAnt build script. The purpose of it is to build continuously to get stuff out the door, but also assure that I’m not breaking anything while I’m developing new stuff. This means that I will commit myself to be a lot better at writing unit tests. Balder has a somewhat 20% test-coverage to date, and the last month I’ve broken a few of those tests, mostly due to architectural decisions that has rendered the tests unusable. So one of the things I will be working quite a lot on, is getting the existing tests up and running again, and also getting the coverage up to a decent level (80% +). Some parts of the engine is plain simple not testable, nor should it be testable. Such as drawing pixels on the screen, just doesn’t make sense to try even to test it. Making that code testable would make performance drop a lot, plus its pretty much impossible to do it.

The build will be dropping new binaries to my DropBox account, and I’m working on a simple Build Viewer in Silverlight that one will be able to use to pick up new stuff from there.

There is a few other reasons I want to have this system in place. If one takes a look at the Balder site up on Codeplex, you’ll notice a promise of not only Silverlight as the supported platform. Balder has since day one been written in a manner that would allow for more platforms, I just haven’t gotten around to actually implement anyone else. I had a Windows Forms version once, but dropped it. Now, on the other hand, I’ve been preparing to scale out to the following platforms :

  • Windows Phone 7 Series
  • iPhone
  • iPad
  • Xna – targetting Windows + XBox (Windows Phone 7, partially)

Also, there are quite a few elements in the Core library that needs tender, love and care. As for the Silverlight specifics, I really want to see the following in there soon :

  • Shaded textures (Flat + Gouraud)
  • Multitexturing
  • Bumpmapping
  • Managed “pixel/vertex-shaders”
  • Blend – Design time support
I haven’t decided were to start off yet, but I will be monitoring the “Issue Tracker” up on Codeplex and working actively with that to be my guide, so please cast your votes.

I’ve started the work on the shaded texturemapping, and it looks kinda cool (see the color difference at the bottom) :

Balder_ShadedTexture1
Also worth mentioning, I’ll be focusing my energy also on getting documentation up to a decent level – I’ve included a lot of Xml documentation tags in the code, but have also started work on layout out samples in the help file. In order for people to start learning Balder, I’m also planning a few tutorials and some video tutorials as well.

One could say that I will not get bored with the above tasklist, I have enough to do – better start working. 🙂

 

Balder 0.8.8.7 out

I promised a release last month, but I had to do surgery and got a bit sidetracked with feeling sorry for myself being in pain. Anyhow, all is good and finally got the release out the door.

Its been almost 6 months since the last release. So this better be good. 🙂

The following are as complete a list I could compile of whats new and improved, btw. you’ll find the new release here. A new version of the SampleBrowser can be found here.

Performance improvements

  • Scanline renderers has improved quite a bit
  • Lighting calculations
  • NodesControl
  • Startup improvements
  • Content caching – loading the same content twice will only clone existing in cache
  • Color class – conversion plus operations are rewritten, introduced ColorAsFloats
  • Dependency properties now represented as Property with caching in it

Bugfixes

  • World matrix + general matrix fixups
  • NodesControl fixed, one can now nest these, plus a massive performance improvement during databinding using the ItemsSource.
  • Mouse events actually working – 0.8.8.6 had quite a few bugs with this, they are pixel perfect
  • PivotPoint fixed – working recursively
  • Completely rewritten rendering pipeline for stability, expandability and performance
  • Memory leaks in mouse event handling
  • Fixed Asset handling system – had a few bugs in it. Still has to revisit this.
  • Parsing of ASE files now use invariant culture all over the place. Had a couple of places it didn’t.

New features

  • Manipulation events on objects, implemented using mouse events.
  • They contain more detailed information about the object being manipulated, such as material information. Also, the events are not like the mouse events, they actually contain delta information about the manipulation occuring.
  • Tooltips, there is a property on all objects called Tooltip, you can create tooltips as you please, as you’d do with the TooltipService in Silverlight for other objects. The TooltipService will not work, hence the specialized property for it.
  • DirectionalLight – basic directional lighting
  • ViewLight – lighting that is “attached” to the camera/view
  • ArbitraryHeightMap – heightmap that can have its corners placed arbitrarily
  • SmoothingGroups implemented
  • New ASE parser – supporting multiple objects, world matrix. Also a lot faster.
  • Ring – geometry type
  • Started implementation of a ChamferBox – very basic at this point
  • Passive Rendering, will draw in wireframe during interaction and flip to full rendering when interaction has stopped. When no interaction, it will not render, Balder goes idle.
  • Pausing – for pausing everything.
  • Grabbing a frame from the Display can now be done
  • Container for renderable nodes – has its own world coordinate system that can be manipulated, lights can’t be placed in this container.
  • BubbledEvent system for events that needs to bubble up in the hierarchy
  • Messenger system for decoupling and stability
  • IGeometryDetailLevel – basically only used for Passive rendering at this point
  • Geometry artifacts such as Face, Vertex and so forth are now classes and has been generalized. Its now up to the implementing platform to create specialized versions of them.
  • Removed MEF and introduced a specialized TypeDiscoverer instead.

Development environment

  • Changed to Visual Studio 2010
  • Build server up and running with a more complete Balder.build file for continuous integration

Breaking changes

  • IGeometryContext does no longer hold the geometry data directly, introduced something called IGeometryDetailLevel. One can get the full detail level, which is the default (and only for now), by calling the method GetDetailLevel() on the IGeometryContext. In addition, any Geometry has a property called FullDetailLevel for convenience.
  • Mouse events has been specialized – they are named the same as one is used to from Silverlight, but the MouseEventArgs has been “duplicated” in Balder.Core.Input. The reason for this is that the Silverlight class for this is sealed and does not have a public constructor, and the mouse event handling needs to handled in a special manner in Balder. Also, the events are now bubbled as well through the geometry hierarchy.