Material Editor Prototype

It's been a couple of weeks since my last post, mostly because I've been quite busy at work, but also because I reached a point in my work on the Light PrePass renderer where I need to sleep on it for a bit so I can then clean the code and improve what I have (this is how I do most of my refactor ... write stuff, stop and think aboutit, refactor/remove code/make it nice ... then rince, repeat).

In the meantime, I started working on the future Material Editor that I will need when the renderer is up ad running. I want a node-based editor a la UnrealEd or other graphical shader editors. And having this king of graph editor would be handy for other stuff like animation trees, visual level scripting tool (a la Unreal Kismet), state machines, etc ...

My toolchain is written mostly in C# (I'll develop the link Engine/Editor in a future post) so writing GUI is not as bad as the usual C++/MFC nightmare. Moreover, I found a superb 2D drawing library called Piccolo.NET a few years ago and its concept of Zoomable User Interface (ZUI) is exactly what I needed for this project. After a few days of work, I have a first version of the GUI running with some underlying graph model behind it. It supports Undo/Redo via a bunch of undoable commands that modify the graph Model. Modifications of the Model generate events that the UI hooks onto and mirror.

I'll give more details about the internals when the code design gets a bit more stable as it is still in early stages, but I am really pleased with the result so far.

Time to conclude with a screenshot :)

Texel to Pixel Centers ... and a Splash screen !

After a pretty intense period at work, things are nicely settling down and I found some time to work on my various things on the engine during the last couple of days.

I mainly worked on some ground work inside the resource management code in order to make sure I can create any type of resource using the serialization/reflection code but also by simply providing a block of data in memory, independently of where the data is coming from. This sounds pretty simple and obvious but enforcing that for all types of binary resources gives you a nice and flexible code architecture and makes things more separated and testable.

About the renderer, I noticed some rendering artifacts on the light pass and started investigating where this was coming from. I first suspected issues with my shader code as I am no expert but it turns out that the culprit was a well known fact about D3D9: Texel to Pixel centers misalignement. Instead of me attempting to explain the issue and solution, here is the official page from D3D9's online help about that matter:
http://msdn.microsoft.com/en-us/library/bb219690%28VS.85%29.aspx

And here are 2 shots, the left one showing the artifacts and the right one showing the result once the bug fixed:

Finally, I spent some time looking at how threads are implemented in C#, what is the interface exposed to the user etc ... As a simple way to use that knowledge, I implemented a splash screen for the editor, that is updated in a separate thread. Nothing particularly hard here but I am really pleased with the result ... probably the best my somewhat limited artistic talent can produce:

That's all for today, hoping to find more time to spend on adding more stuff to the renderer and then move on.

Light PrePass in the editor

I made some fixes so I can have more than 1 light and their contribution nicely accumulates in the light buffer. Moreover, I fixed some minor bugs so I can use all that in my editor and move the camera and lights easily. It's not that much but I'll just put a screenshot :

I hope I'll have some more time this week to work on point and directional lights as well as improving the point lights (by drawing a 3D sphere or a 2D billboard instead of a fullscreen quad). And also more time to posts details about all that, with code snippets maybe :)

-m