XNA 3D Gizmo v2.0.0

I've just released a new version of the XNA 3D Gizmo! The updated source has been available on CodePlex for a while, but I never got around to add the final touches and create a release.

As the name suggests (2.0) it involves a major change compared to 1.0 which was released well over a year ago. The new release provides a much improved framework and simplified code while adding customization options if more advanced usage is desired.

The following is a snippet from the release notes:

FOR EXISTING USERS: If you are already using v1.0 you may choose to leave this release alone unless you require additional customization options or more advanced features which have been added in this release (see notes below for all additions)

- Quaternion support.
- Built-in vertex lists replacing fbx models (easier implementation for new users),
- ITransformable interface to add transformation support to anything in the scene (example: vertices inside an editable mesh that lives inside the 3d scene)
- A lot of framework simplifications and no more dependancies on Engine class or any other outside classes.
- Gizmo is now a standalone DLL (class files can still be placed in any other engine project without a hitch if standalone DLL is not preferred)
- Support for custom Select functionality (ITransformable.Select(ray) to allow users to define their own selection methods (triangle precision or bounding box etc.)
- Improved internal code for readability.
- Transformation is now done through event handlers, allows much more customization options on how to apply transformations in your own editor. For example it allows you to support a undo/redo system.
- You can now set different 'selection pools' this allows you to select and/or ignore certain object types by only passing a pool of a specific type (example: pass a pool of 3d entities or a pool of selectable vertices)

You can get the latest version right here!

Junior Tools Programmer at Guerrilla Games

I've recently started work as Junior Tools Programmer at Guerrilla Games in Amsterdam! (Creators of Killzone)

Grim caught their attention when it appeared on control-online.nl

I should have some spare time once I'm fully settled in to work on hobby projects that include

C# and perhaps my engine. I have a new portfolio coming up (work in progress, but pretty close to completion) I'm not sure yet where I'll post the new updates (if they're not directly Core Engine related) 

I will make an announcement when my new portfolio is online.

Gameplay Metrics for Grim (Screenshots)

As shown a while ago, we have our proprietary metrics tool to review our playtests and look for unintended behavior and opportunities to improve the game. One example of where the metrics directly help us is to look for Leap events to see if players are having difficulty making certain jumps as a result of platforms being too distant from one another. 

I'm in the process of creating a short video, for now I've included some screenshots to give you an idea of what it currently looks like.

"Climb" the level used with the metric shots below.

Unfiltered shot of the full match with 6 players. 

Red indicates low Energy resource for player.

Second trailer of "Grim"

We've just finished the second trailer of our game. It features our second level "Climb" which was created for our Breach gametype. The "Mateba" our multi-purpose weapon (with both short and long range capabilities) and Leap our primary ability are all included in this new video.



As always, the most recent updates on our development are available at our website: http://grim.morepolygons.com

Development of Grim: Weapon Particle FX

Gameplay Trailer of "Grim"

Our first gameplay trailer for "Grim"! It mainly features our first deathmatch level "Outpost" along with Deathmatch itself. In future updates we will go into more detail about the unique elements of "Grim". Hope you enjoy!

Titan Metrics: Gameplay Analysis Tool

More Polygons "Grim" Homepage

Hey guys, I have been working on a gameplay analysis tool for our online shooter “Grim”. For the first internal release I made a short video, It should give you an idea of what we can do with it so far. I have a bunch more things I’d like to add (including cloud/heat maps) but first I must take some time off to work on gameplay and server browser!

It even includes my voice this time! :P Let me know what you guys think, maybe you have a cool feature request?

Project site is online!

The project site is up! Currently you will find several screenshots and videos of our game, 3D assets, information about our game design and of course the two proprietary tools I've been working on! Have a look at let me know what you guys think.

More Polygons "Grim" Homepage

Direct links:

Titan Metrics - Gameplay analyzing tool (Features 3D Visualization of player and match data)
Titan Toolkit - Making life easier for everyday UDK Development

Of course we will update the site on a regular basis, keep an eye out for more!

Graduation UDK Project

Hey guys, It's been a while since I uploaded any videos or blogposts. I've definitely been doing some cool stuff behind closed doors, this time with the Unreal Development Kit. We're about to reach a milestone where we will start showing our development more openly. This means I will soon start recording some videos that will include my development experiments as usual.

This project is for my graduation, I'm working in a team of six to build a proper first person shooter for the PC. As expected I'm the programmer, but do a lot of the design work as well. Aside from the game itself I have been busy building some UDK based tools for the team, this includes a launcher/management tool to launch UDK in every way you can think of and includes more advanced functionality such as bug reporting (automatically sends the reports to our server at Assembla) along with FTP file uploads (screenshots, crash logs) and more. A second tool will remain secret for now. I will reveal details on it later on through some videos and post some info about it here as well.

For now I'll leave you with two (pre-alpha) screenshots of our project.

EditMesh Submode & History Panel

It was about time I posted a new video about my progress, so I decided to create a very early preview of some of the new features. This includes an early version of the history panel and the improved mesh editing feature.

If you're familiar with Neoforce you may recognize it in the video video. If you don't, it's basically a Winforms-like library with tons of features for 2D menus. It has quite an exhaustive feature-list and will replace all my previous Winforms based panels/windows. One big advantage of using Neoforce is alpha support, something not easily accomplished using regular Forms. Another advantage is in its design, instead of using OnPaint events and event handlers, it has regular Update and Draw functions. This is really nice when you're creating transitions and smooth animations for your controls.

There are some other features hidden in this video, one is still in very early development. You might have seen the screen fading from and to black several times, that is part of it ;) The best way to describe it: a method to quickly access your panels, menus, assets etc. through a single hotkey (spacebar by default) As you can see in the video, I 'pinned' the history panel to my game window, keeping it active when leaving the screen overlay. I will talk more in-depth about this video once it's more developed.

Gizmo update coming soon!

Hi guys, just wanted to let every XNA3DGizmo user know that a update is currently being developed. I noticed that the original implementation had some sloppy shortcuts that could make it more difficult to implement if you were unfamiliar with the code. This included references to the Engine class among other things.

So I decided to improve things by removing any reference to outside classes (including InputState which is no longer required) I realized this update is necessary as even I found it difficult to implement the gizmo in a new project and wasn't a simple drag&drop operation as it should be (or as close as possible to it) this made it obvious some improvements were required to the public version.

The last public update was quite a while back and I was using a modified version with already several improvements implemented (such as multiple type of objects you can select as shown in the Vertex Manipulation Video where I select both scene objects and vertices with the same Gizmo component)

So in general the upcoming update should make it much easier for everyone to implement this gizmo into his own code/editor. If you had trouble integrating it, please let me know. There is no current ETA on therelease, but I'll try to do it sooner than later...

Image Collection

I haven't made a lot of progress recently on the engine due to my internship (completed) and the start of the new school year (my last) I did make some screenshots a while back when I was working on flares and terrain texture mapping. Below a small assorted list of the things I did.

With the terrain texturing I tried to minimize stretching on steep surfaces without using the tri-planar technique, there were some difficulties and I don't have a finalized method yet. The red/green colors on the terrain indicate UV coordinates, the lines are the surface normals and the yellow text displays the vertex number in the VertexBuffer. I hope this can at least somewhat fill the major gap in between posts recently, hopefully I can do some cool stuff again soon like working on the mesh editor from my previous post.

Vertex Manipulation [Compound objects]

Just a short update on what I've been working on this time. It started when I was playing CoD:WaW this afternoon and I noticed a lot of debris and broken walls which got me thinking about how they managed these kinds of assets. This intrigued me, so I started drawing up some ideas on how I could potentially add this to the toolset, with little knowledge on mathmatical geometry or destruction calculations I tried to start things simple and look for existing online resources.

I will go into much more detail on this topic at a later time, for now I'd just like to share a few images and give notes on what you see.

ray vs. triangle collision. white lines visualize an array of lines from the camera eye colliding with the geometry.

The box-mesh on the left was used to cut 4 holes into the plane-shape.

The wireframe of the same scene, visualizing the triangles of the triangulated plane.

A hole cut by defining 5 vertices by colliding a ray with the plane, these were defined at runtime from the camera-eye.

I'm also looking into 'bridging' (users of 3D Studio Max may know what I'm talking about) to fill the gap between two planes of a wall (its back and front) after cutting a hole with the triangulator. Some basic box uv-mapping and a noisy texture to simulate broken concrete (or any other material) and you should have the basics to quickly create holes in walls or break chunks of the scene's meshes. The resources I used are listed below. Much more on this at a later time, there is still a lot to do and even more to talk about :)

Resources

App Hub - Triangle Picking Sample

Nick Gravelyn's Triangulator (2D)

Triangulation By Ear Clipping - by David Eberly

Input & Hotkey Management

Input management is one of those things I never really paid a lot of attention to, using simple if-statements inside an Update() or HandleInput() function worked fine is most cases, until recently. Recently I started to notice my input handling got scattered throughout my code-base and a lot of coupling was required to make sure it was handled properly.

To prevent hotkey-clutter (especially when modifiers (ctrl, shift, alt) get involved) I started working on a HotkeyManager that handles groups of Hotkeys in an easily maintanable way. Initially it was supposed to assign a HotkeyGroup to one or more 'editor-states', like 'only-use-this-hotkey-while-in-editmeshmode', I soon realized this wasn't going to be very helpful and I would have to continuously add new states to keep it up to date...so this was scrapped and replaced by a simpler, but more powerful feature - Predicate<T>. Using predicates enables the manager/hotkey to activate only if a predefined condition is met (i.e. if gizmo.IsActive == true -> execute the hotkey-function) it can contain more than one statement such as gizmo.IsActive == true && Camera.IsMoving == false for example...if both conditions are met, the hotkey may execute with the associated Action (the method assigned to the hotkey) The code-snippet below should be able to illustrate its use.

You may have noticed the above code refers to the GizmoComponent class. SetSelectionPool(IEnumerable<ISelectable> selectables) is a new function I've added to more easily support custom collections and to assign new collections at runtime, in my case this is used to switch between vertex- and object-selection more easily. I will add this along with many other improvements to the open-source gizmocomponent at codeplex at some point.

Back to the hotkeys...within InitializeHotkeys() there is a HotkeyGroup class, this class holds a collection of hotkeys that belong to the same component or share similar functionality. These groups are passed to the manager and will be updated automatically.  The Hotkey class is the main class and has several parameters including key (supports all Keys, MouseButtons and GamepadButtons) a KeyPressState (press, release, hold) a KeyModifier (control, shift, alt or a combination - not illustrated in img), the parent  (used by the Predicate to verify the conditions) and the Action to execute after the key is pressed and all conditions are met.

A quick search revealed there are no suitable Input/Hotkey managers (I didn't like any of the libraries available on Codeplex) so I might turn this into an open-source component/library if enough people are interested in such a library.


Actions and Vertex manipulations are also still WIP, I made some progress on both these tasks and should have some something new to blog about soon enough.

Vertex Manipulation (Mesh-editing)

Editing models inside my engine has been something I wanted to support for a long time now. Especially when you're not the one creating the assets, but do have to work with them inside the editor it can be time consuming to send back a model with incorrect material names or a mesh that should be split to optimize rendering, or vice versa. With this tool I will eliminate the need to have artists re-export their models because of tiny mistakes/changes and should provide a much cleaner pipeline in general.

Currently only the very core of this feature has been implemented (as seen in the video) and a lot of other stuff is still to follow, I will give a brief overview of how the fully functional tool should work once its complete. When any new model (.fbx or .x) is imported, it's processed by the content pipeline and turned into an .xnb file, an .xml file will be attached to the source (model) file that contains all changes to the model and will be processed during build-time. By default this .xml file is empty and nothing altered, during run-time a mesh can be converted to Editable Mesh (trying to keep this similar to 3D Studio Max's naming conventions) which allows vertex and triangle selection with support for any type of transformation that is supported by the gizmo component (translate, rotate, scale in local- and world-space) these transformations are stored inside Actions (I will talk about Actions a lot more at a later time, but it's basically what you use to support undo/redo in any kind of editing software) and written to the model Xml. The model is then re-build the next time the project is build and the actions are applied, this can hold any type of alteration including material renaming, splitting meshes and deleting / adding new vertices alongside vertex transformations.

Because the source model remains untouched, whenever the model is re-exported from any DCC-tool like 3D Studio Max or Maya the model will still build with all transformations and alterations applied. An example: A material named '#46 Material' is renamed at run-time to 'corridor_floor', if the artist then changes the name of '#46 Material' to 'corridor_floor' or something else in the source model, the run-time change is ignored because the original material name (#46 Material) can no longer be found... in a worst-case scenario this ignores the material properties you stored for the original name (material properties are stored elsewhere, so no data is actually lost) so even in the worst case, you are only a small step away from re-applying your previous changes (A warning dialog with failed conversions should help with this, making it potentially very quick and painless to manually re-assign the changes that are never lost, just ignored till resolved) The same applies to vertex transformations, but these can be a bit more difficult to keep track of once the indices of a certain mesh change inside the .fbx source file.

There is still a significant amount of work that has to be completed before this feature takes it full shape, with this first proof of concept up and running I believe it will be a very valuable tool to have available, and a lot of fun to create :)




It proved to be quite easy to convert the gizmo to support vertex manipulation (and selection) I will add these changes to the codeplex project at some point in the future...

Updated blog layout

I had plans to do this a while ago, but never got around actually doing it. Last night I kind of stumbled upon a new, wider template that still looked pretty similar to the old one. Most noticeable benefit is the extra space available for bigger images and videos and I'm pretty glad about how the new template turned out.

In lack of other news I dug up some screenshots of Project Sunburn.

An objective-based level from Project Sunburn

Enemy drone firing at the player in one of our test setups.

Let me know what you think about this new layout in the comment section :)

Environment Mapping (w/ Normal Maps)

A while ago I was trying to get Environment maps (aka Cube-maps) to work with SunBurn's Deferred renderer with reasonable success. Last week I had a go at it again, this time in my own renderer, because the normal-mapping information was already available inside the shader it was relatively easier to do this time around (along with all the problems I have already solved the first time)
It was supposed to be a transparent (forward)-effect for windows etc, but somehow turned into an opaque cube-mapped deferred shader...Not sure how that happened :)

Below you can see what the shader looks like at the moment, where the first two images show the 'forward' shader and the last two use the deferred shader (which includes pointlights, specularity etc.) The forward shader will be modified so it supports alpha-mapping, what it was originally designed for anyway.

Forward shader - environment map, with normal map and simple directional light.

Forward shader - similar setup as above.

The deferred shader - with pointlight on the left and right (with very strong colors to highlight the effect)

Deferred shader - with the deferred rendertargets (LoR: color, normals,depth,lighting)

The next step is to further develop the forward rendering pass, for transparency mostly. This includes depth-sorting of the objects along with Composite Lighting that calculates approximate lighting for objects that don't support deferred shading.

Resources:

Custom Model Effect XNA Sample - Source for the cube-map processor and the basics for the environment mapping shader.
Shawn Hargraves on Cube-mapping - Some interesting bits about cube-mapping, closely tied to the XNA sample above.

A new (Deferred) Renderer [Part 1]

For a long time I have used SunBurn as my primary rendering solution. This helped a great deal while developing Needle Juice, Over Night and more recently: Project Sunburn. With no new game projects lined up with Core Engine, I have decided to experiment with my own rendering solution, based on Catalin’s Deferred Rendering sample along with information from many other sources including a Killzone 2 presentation from 2007.

The above images shows the most recent unit-test of filling the hardware DepthBuffer with the Gbuffer-depth to draw post-deferred geometry (i.e. using forward rendering for transparent surfaces) and other visuals such as vertex-lines. This is done during the final combining pass of the geometry data and lighting using the ‘DEPTH’ semantic. This fills the depth-buffer as all depth is lost after switching RenderTargets (something that can be prevented on the PC using PreserverContents, but does not work on the Xbox - this solves the problem entirely)

Some other experiments include texture projection as seen below.

Texture projection has several great uses, including Deferred Decals, light shapes and video projection on the scene's geometry (as seen in Splinter Cell: Conviction) Back while developing Over Night we used shadow-mapping in places where texture projection could have been much cheaper. A good example of this is the blue light coming from outside through the shaded window, covering most of the room as seen below. The second image uses a texture to simulate a similar effect, without having to re-draw the entire shadowmap every frame, instead simply sampling from the texture and projecting it into screen-space.

Looking back at Needle Juice, where we used a directional light with shadows to draw light coming through the windows, another place where texture projection would have been a cheaper and more elegant solution to our problem (also preventing light-leaking, which is very common with directional lighting)

Needle Juice: directional-light coming through the window, required shadow-mapping.

I will continue working on the renderer for the time to come, with such a wealth of presentations, papers and samples on deferred rendering (and graphics programming in general) it will keep me busy for a while…Until next time! :)

'Depth Dependent Halos' for Wireframe rendering [Part 3]

It took a while to upload (on 56k wireless connection) but the video is finally available on YouTube. If you haven't seen the previous posts about this topic, the effect is based on UDK's implementation of 'Depth Dependent Halos' to increase readability of wireframes in complex scenes.



After I managed to get the desired effect I could simplify it significantly. Moving from two render-passes to one and from 18 texture look-ups to 'just' 9. This was possible by removing the normal 'diffuse' pass which is nothing more than the regular colored wireframe you can see in the video (when the halos are toggled-off), and instead using the information available inside the depth-buffer to construct the wireframe. This is pretty easy if you take into account that if (depth == 1) there is no geometry, where if (depth < 1) there is in fact a line that was drawn when constructing the depth-buffer. From this you create a colored wireframe and the halo inside the post-processor. The same data can be used to determine intersecting lines...removing the need for 9 texture lookups that sampled data from the original wireframe in the first prototype and instead re-using the sampled depth.

The result can be seen above...

'Depth Dependent Halos' for Wireframe rendering [Part 2]

I have been working on getting the depth buffer to generate properly and using it to post-process the wires (i.e. creating the outline around the wireframe) and so far I'm quite satisfied...it's still a work in progress, but progress is going well...

This is the result so far, with the depth buffer drawn in the top-left corner and the final image in the middle. 

A zoomed-in version of the first image, the effect is visible around the characters head where you see a clear outline being formed, disconnecting it from the other character underneath it. 

For comparison I used a color similar to UDK (see first image of previous post)

4 more texture-lookups will be added which adds improved support for diagonal lines - that would bring the total lookups to 14...which is quite a lot for a single effect, but since the geometry will never been drawn with fancy shaders while in this 'mode' (nor any other post-process effect) I don't expect it to be a problem. This effect provides the most benefit when moving around with the camera, I hope to upload a short video of this after I finalized the effect.