Core Engine Development

EditMesh Submode & History Panel

2011-12-05T02:44:00.001+01:00

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!

2011-11-05T06:02:00.000+01:00

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

2011-09-23T15:28:00.000+02:00

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]

2011-07-04T00:32:00.000+02:00

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 defines 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

2011-07-03T02:23:00.000+02:00

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)

2011-06-26T16:21:00.004+02:00

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

2011-06-15T21:10:00.000+02:00

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)

2011-06-14T23:39:00.001+02:00

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]

2011-06-05T02:35:00.002+02:00

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]

2011-05-21T22:59:00.001+02:00

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]

2011-05-21T13:23:00.000+02:00

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.

'Depth Dependent Halos' for Wireframe rendering

2011-05-21T01:33:00.000+02:00

'Depth Dependent Halos' is something I read on the UDK site a while ago, it's for their 'new' (by now pretty old...) wireframe rendering that increases readability of the lines for complex scenes. I was kind of wondering how they accomplished this and wanted to try this out myself (I was working on a wireframe-mode anyway, so it was the right time to experiment)

This is the effect I am trying to replicate. Black halos are drawn around the wireframe lines to provide a better understanding of depth differences between these lines.

I went through a few different approaches and ended up with a small post-processing shader that applies the halo around the wireframe lines. It took a few iterations to get the desired results, but I did end up with something that is pretty close to what I am looking for...

The first step was to create my regular wireframe and letting the post-processor create a small single pixel halo around these lines using a different color. The second step (still have to start on this one) will require a depth-buffer and use the depth information to determine if the outline/halo should be drawn with halos being drawn on top of lines underneath them, creating discontinuities between lines that intersect and are underneath others.

Some of the iterations I went through:

Trying to find out the correct pixel offset and coloring by finding edges and applying a different color to each direction (up/down/left/right in screen-space)

This is the current state of the code, and resembles the desired effect (of step 1) quite closely.

I have also been working on some additional scene navigation features. These are best shown in a video, but since I currently get my connection through a painfully slow USB stick - that will have to wait...

bonus image...(this result was less then expected, but looks pretty cool)

Prototype: Orientation-Adapative Grid

2011-05-14T19:33:00.000+02:00

"Orientation adaptive Grid" is a concept I drew up earlier this week and I finally turned it into a working prototype yesterday. There really isn't a lot to talk about - It reacts to the orientation of the camera and shows/hides the three available grids. The video below demonstrates this in a few seconds...

(watch is high-quality to see the lines)

I'm not quite sure if I will be using this in the later stages of my editor - so far it goes look kinda cool and doesn't seem too distracting - it will require some more tuning (of the alpha values) and once the ViewCube (seen in the top-right corner) is complete I will revisit this concept as they play pretty well together.

Editor Tool: ViewCube (Camera Orientation helper)

2011-05-02T00:10:00.000+02:00

Got to work on a new tool today and to users of 3D Studio Max or Maya it may look very familiar. It's called the ViewCube and it helps you orientate your camera in the scene. The video below demonstrates the basic system, Right now it's still only a prototype I made earlier this evening and I will finish it at a later time. The final tool will interpolate to the new position/orientation and the tool itself will be available in the top-right corner of the screen (and will have greatly improved visuals of course ;)).

Since I only have one viewport available in my editor, this can theoratically be a replacement for the standard dedicated Top/Side/Front-viewports. I might add an easy toggle for perspective-to-orthographic so you would not longer need/have 4 viewports on your screen at the same time...

Engine Restructuring

2011-05-01T02:05:00.000+02:00

So I have actually had the time to work on the engine again and been experimenting with some design patterns. Since the deadline of our latest project (Project Sunburn) has passed a while ago I have been doing some experimental stuff, mostly to try and fix issues and concerns that were bugging me for a while. Since there are currently no new projects/games scheduled to use the engine I am basically free to experiment and try out new things.

A pretty major annoyance is 'one-frame-lag', it's fairly common and can easily happen when you don't own full control over the optimal update-order of your components. This type of lag most commonly occurs when object-A affects object-B, but B has already updated himself that frame. It will then take another frame for the full-effect to be applied. The same thing can happen when different objects query information from a object that itself gets affected several times during a frame, this ends up being messy and will have unexpected results and one-frame-lag.

However, I believe to have found a pretty solid solution, since it a bit experimental I will first test it against more complex components. More on that later...

The latest version of Core Engine was also lacking a proper Game-State management framework, which wasn't a problem for a long time since we generally didn't use 2D menus for our prototypes, but I am currently figuring out a good way to re-integrate this into the engine (from scratch) The 'standard' frameworks really don't work for me as they easily make your framework very complex and put a lot of extra strain on iteration speed, it should be a lot simpler and that's exactly what I'll be trying to accomplish.

A small note on the Gizmo for those of you who may be using it - I might release an update soon fixing some of the integration issues people might experience when they don't have a similar framework set-up. I will try to completely decouple the component which makes it a lot easier to integrate into your own editor. (If you experienced any other issues, let me know and I will see if I can fix is along with the rest)

With all the other stuff going on I did not spend a single minute on V-script (Except for a presentation I did, I might talk about it some other time) So there is not much news on that I'm afraid.

Starting my Internship (at Trinigy, Germany)

2011-04-03T14:24:00.000+02:00

Some of you may know I was recently accepted as Intern Software Engineer at Trinigy, Germany. I arrived in Engingen (near Stuttgart) yesterday (on April 2nd) and I will start my internship tomorrow. It lasts 6-months which is quite extensive, but I expect to learn a lot from this experience.

I don't know what effect this will have on my personal (XNA)projects. I might be able to work on them whenever I have some spare time available. One of the projects is V-script which I recently talked about. I'm considering making it open-source, but have not made my decision yet. It all depends on the quality of the end-result. If you're interested in seeing the V-script (or 'Node-graph Framework') as open-source, leave your comment and let me know if you have any specific features you would be interested in... (I will publish a feature-list soon)

I was going to publish a video of the assignment I had to complete in order to get accepted, but I'm not sure if that is allowed. If I'm able to publish it, I will upload a video about it soon.

SgMotion: Rig/Skeleton Visualizer

2011-03-29T01:20:00.000+02:00

A couple of days ago I added a new feature to the SgMotion animation library.
It visualizes the animation skeleton to debug animation and rigging issues and helps finding bone/dummy names and indices more easily.

You can grab the latest release for SgMotion over at codeplex.

An example of how to use this new feature is available inside the Sample project.

As an added bonus you can cycle through the skeleton to highlight bones and their children, watch the video to find out exactly what I mean.

Visual Script 2.0

2011-03-10T00:53:00.000+01:00

The above image contains the new (WIP) V-Script tool. It's much like the old script tool, working with Nodes similar to many other node-based frameworks out there. However, this new tool is build from the ground up and should end up with a much cleaner structure and higher flexibility. It will include Xbox 360 support, something that the old wasn't designed for.

As you can see above, I have most of the basics worked out. A cool feature that I added today is auto-alignment, this basically structures the connectors automatically and re-sizes the Node if necessary. The old system required you to manually place all connectors, which proved to be a pain for the more complex script-nodes that were added late in development.

One last thing you can see is the new menu inside the XNA Game Window. There aren't captured by Fraps, so you couldn't see them in my last video while it was already implemented back then. It's still only a small proof of concept, it's a context-based menu that changes depending on what you've selected and/or are working on (particles, scripts, object-placement etc.) note that the gray bottom-bar (that is currently empty) will include info about the editor and gizmo properties etc.

Console Extension - Auto-complete & Suggestions.

2011-03-02T14:44:00.000+01:00

I actually finished this last night, but I didn't post about it and decided to get some sleep instead. It's an extension on the console component I integrated a few weeks ago. It adds support for auto-complete and command suggestions. I might add an argument-completer as well in addition to some layout fixes.

(watch in HD 720p + fullscreen to read the text)

I originally got this idea from the UDK console that has a similar feature, it should make browsing and finding commands much faster and easier and doesn't rely on software knowledge as much.

It's based on the GameConsole by Vos which I believe is one of the best console component for XNA.

XNA 3D Gizmo Video!

2011-02-26T12:41:00.000+01:00

Finally a video about the Gizmo showcasing the feature-set. I've added some tunes as well this time, hope you like it...

XNA 3D Gizmo v1.0.0 Released!

2011-02-24T10:09:00.000+01:00

The latest version of the XNA Gizmo is now available on Codeplex! You can download it here.

Since my last announcement I have added many features (including all those I mentioned in my previous post) and it should be ready to use in your own editor. I supplied a small framework to show the Gizmo at work. I have tried to make the implementation to your own engine/editor to be as painless as possible, however it can always be easier...(if I knew what all of your engines/editors would look like :) )

I still haven't made a video to showcase all of the new features, but it should be available soon...

Download Link

Gizmo Roadmap & Engine Revamp

2011-02-12T23:56:00.003+01:00

First off, there have been several updates for the Gizmo since the last announcement. You can download them on the Source Code-tab on Codeplex.

Most (features and code) has already been implemented by now, however there are still some nice features on the horizon. This includes:

- Grid & Rotation snapping.

- Multi-layer selection. (or click-through selection)

- Reset transform.

- Added support for multi-selection.

- Precision Mode.

Some of these were already part of the old gizmo, and others were already implemented in the internal version of the Gizmo I used in my own editor a while ago. So it shouldn't take long to implement any of these in the revamped public release...Stay tuned for updates!

Next, a quick notification on the Core Engine roadmap. Since there is currently no game in development I can make breaking changes without ramifications. This is something I often do when there are no games actively developed with the Engine. This time it's a pretty huge revamp of the complete engine-structure. So far I have deleted over 110 classes to make room for a new and improved structure including a much better GameState management system that is first on the list.

Not all code is deleted though, I will be using a lot of the old code for new components and managers, deleting them for now makes the re-design a lot quicker and efficient (preventing 100's of errors)

In addition to the new structure I'd like to design components in such a way that it's easier to create external projects for open-source initiatives such as sgMotion & GizmoComponent. If I can just copy/paste my own component to one of the open-source projects, it will be a lot easier to update and maintain. The Gizmo is a good project to fine-tune just that.

A new video should be up soon, once the Gizmo is out of Beta.

Gizmo Beta Released!

2011-02-08T12:16:00.004+01:00

It's finally here...well kinda. It's still in Beta, but a lot of its functionality is working and now you can try it out for yourself on CodePlex.

There are some known issues (including local-space transformations not working as intended) but I really wanted to let you guys try it and see what you think of it.

The component has been re-built from the ground-up to eliminate all of the old issues and improve readability and flexiblity of this new revamped component. Feedback and suggestions are welcome, you can post it in the comments or leave a message on Codeplex instead.

I'll leave you with just this image and a download link for now, a video will follow once I have a fully stable build.

Since I'm finally using SVN, you can directly follow my updates on the Source Code tab of codeplex.

GSM & Gizmo Update

2011-02-05T23:22:00.004+01:00

Still no release available for the Gizmo project. However, with the Translation mode pretty much complete and the Rotation well under-way it's getting closer.

I finally created an SVN-host. This means the next Gizmo release will use it as well, so you should keep a sharp-eye on the Source Code tab of the project page.

Among other things I completely re-designed the GameState management of the engine. the previous GSM had faded over time in flexibility and support due to heavy changes in overall engine structure. This new system should increase readability, flexibility and performance. The Gizmo will use a small portion of the GSM. As it will be flexible, you can easily change the components to fit in your own framework without having to use mine.

The (normally invisible) collision hull of the Rotation-mode. Mesh vs. Ray will determine the selected axis.

The already complete Translation-mode. As seen in the previous video.

Gizmo Update (no release yet)

2011-01-31T03:46:00.004+01:00

I have been working on a completely new Gizmo. The old one did what it has to do, but it lacked feedback for the user and didn't look very professional.

The new release, should be the (near) final iteration of the project. I still don't know exactly when it's going to be finished, but I've made a lot of progress today.

Currently, only the Translation part of the gizmo is in place. But like the previous version, rotation and scaling will be supported.

Updated 'Over Night' Trailer on Youtube

2011-01-07T04:14:00.003+01:00

I've just finished updating the trailer of our previous project, 'Over Night'. It includes a new voice for Jake, the protagonist and higher quality in-game footage. The previous upload suffered greatly from compression artefacts. This issue has been resolved and the overall quality of the footage has been greatly improved.

For anyone wondering if this means the project is still on-going, I'm afraid I'll have to disappoint you. I've updated the trailer so I can include it in my Portfolio. More on that later...

Due Update

2010-12-31T03:51:00.007+01:00

It's been a while since my last update. After a tiring 26 and a half hours of continuous work to make the deadline, I needed some time off from XNA. I got started again earlier this week though and I have a few teaser screenshots to show you guys.

The placeholder shells colliding with the environment.

The new shell models. (By Bo our 3D Artist)

Transparency/cube-map test for scope on Assault Rifle. (using Arbitrary model)

Dummies, a much easier way to align muzzle flashes and shell positions with the weapons.

The new (WIP) Gizmo. The current release on Codeplex is pretty outdated feature-wise. An updated release should be up soon (no ETA available yet)

Other upcoming tasks include, motion-blur on the shells, depth of field on the weapons and a proper muzzle flash among other cool stuff...

Updated SgMotion for Sunburn 2.0.6

2010-11-21T02:47:00.003+01:00

SgMotion v1.2 for Sunburn 2.0.6 is now available on Codeplex!

Mostly changes to the Sample and removed some older unused classes that were causing trouble with the new XNA 4.0

The PlayerMarine.fbx class seems to loose his Animation clips in XNA 4.0 for an unknown reason. I have tested this issue with some of my own animated models, and they still work fine (using KW-Xport)

If you run into similar issues with your own models, I added a small *.xml file that demonstrates a quick way to split the model into custom animation clips (Note, default clip name in .fbx model is "Take 001")

Download Here

Project Sunburn: AI-Subsystem (First Dronetype & AI-Manager)

2010-11-02T15:31:00.002+01:00

We completed our first playable prototype yesterday, and it includes AI! This was the first time I worked on game AI, previous games like Needle Juice and Over Night did not include any form of AI. Luckily our enemies are robotic, not human. It's a lot easier to create a believable drone that in-fact should act as if it's programmed compared to a humanoid character running around trying to act as a sentient being. So far the main drone class, the Spider-Drone, has been implemented and is strolling around in our game. Other drone types (including flying drones) will be added later in phase 2. (started yesterday) Below I wrote a very short summary of certain AI aspects that I included so far.

A lot of the info a drone requires is processed in a global manager class. This makes it easier to spread the workload across multiple frames, avoiding frame drops. One example is the Link Availability, testing the links against active drones in the level, blocking a certain link if a drone is not moving (shooting or idle), and therefore blocking that path. This avoids unnecessary navigation errors when drones try to reach the player.

Red lines indicate the path is blocked...

Another task that is handled by the AI-Manager is tagging waypoints as cover. As certain drone variations will hide behind cover to deploy their weaponry. These kind of non critical components are updated on low frequencies to safe CPU-cycles. In addition, only waypoints near the player can be tagged as potential cover.

The Yellow waypoints are tagged as "Cover"

All drones have some kind of weaponry to use against the player. Our first drone has a light machine gun, firing short bursts of bullets. Their weapons work very similar to the player weapons, so it was easy to setup. The turret tries to maintain a solid aim at the player (limited by its rotation speed) and fires bullet salvo's while trying while trying to get closer. In addition, the lens in front, can be destroyed by a single well-aimed shot. This basically counts as a headshot and immediately disables the drone.

These are some of the highlights currently implemented as part of the AI-Subsystem. In the upcoming phase I will spend more time optimizing the current manager, add air-drones, improve path-finding and improving overall behavior of the drones.

Post-Process: Motion-Blur Effect

2010-10-13T23:37:00.002+02:00

A simple Motion-Blur post-process based on the GPU Gems 3 article.

Editor Update: Clone-tool with ClonePreviewer

2010-10-13T03:22:00.003+02:00

You can simply drag your clone to the desired location while using the scroll-wheel to determine the amount of clones you like. The process is finalized by pressing the Enter key.

The preview models share the same instance of the source model, rendered with an offset for each clone. The translation is snapped to the current grid size, alternatively you can use precision-mode (Shift) to fine-tune your clone-offset. Works with any type of placeable entities, however entities without a model (particles etc.) use simple boundingboxes/icons to show their destination. This may change in the future, where even particles may be fully rendered while previewing.

Creating Line-based Animations with the SketchTool

2010-10-12T02:59:00.003+02:00

A Proof of Concept to animate objects, particles and lights using the Sketch tool.

The position and normal (of the colliding triangle) and stored and converted to an animation file (shared with the already built-in Animation Editor). These can be plugged into any script to easily animate objects, lights or particles in the environment.

Effortless Waypoint & Path creation using 3D-Sketching

2010-10-10T05:04:00.004+02:00

About 3 weeks ago, I demonstrated the Sketching in 3D Tool. Today I went a little further and expanded it to be able to create waypoints and paths for our upcoming levels without effort. Manually placing waypoints can be a tedious task, especially if your level is continuously changing in its early stages. With this new Tool we'll be able to create full AI paths in seconds, with easy tweaking after the initial waypoints are setup.

Currently there are two types of lines. WaypointLines and AvoidanceLines, the latter is used to state certain parts should simply be avoided by the AI or to break paths that are too close to geometry or ledges.

Triangle-precision ray collision

2010-09-27T00:30:00.005+02:00

Bullet collision was previously calculated using the triangle mesh capabilities of BEPU. This wasn't going to work efficiently with all the separate meshes that are going to be used in our levels. With the basics of triangle-picking already implemented in the editor tools it didn't take a lot of time to get a basic prototype up and running. In the image below you can see the new filtering algorithm.

each "group" (1 big sphere, 8 small ones) contain 41k polygons. (click image to read the text)

In a regular scene with a higher amount of objects with lower polygons per mesh that are spread across the scene, the optimization methods will become more efficient. This will be tested once the prototype level is complete.
The main focus of the new filtering system is excluding hidden models before they enter into the per-triangle collision check. This system is added on top of the bounding-sphere filter that was already present in the editor tool.

Overkill? 150 million triangles both rendered and tested against the bullet ray. This clearly wasn't going to run smoothly (roughly 0.1 fps)

Video:

(use 720p and fullscreen to read the filtering info in the topleft corner)

Engine Update: Sketching in 3D

2010-09-18T17:05:00.004+02:00

Over the past 2 months I haven't posted a lot of news. With the new project up and running (kick-off was the 13th) I'll start doing more regular postings like I used to.

With the project details still being worked on, there is some time to develop tools that should make life easier later on in the development stage. So I decided to work on some odd ideas that I came up with while traveling. The first one is a pretty cool feature, its sketching in 3d. It uses the 3d meshes inside the level as a canvas to draw on. I think this is very useful for level designers and to help process play-testing feedback.

For this particular feature to work, triangle precision ray-testing was required. Luckily the XNA Creators Club had a sample project to get me started. The lines are made of vertices combined into a LineStrip. In addition the triangle normal is tested against the ray direction to prevent drawing on back-faced triangles.

While implementing triangle-precision picking I updated the Gizmo so it is now able to select models by triangle instead of the small boundingbox. Being used to 3D studio max' selection methods I decided to implement multi-layer selection. Because that name probably makes no sense, I'll try to explain it. If multiple objects are behind one another, clicking multiple times will select the object behind the previously selected object, clicking again will select the one behind it etc. That means you can select any object even if another is blocking your view.

Each click will pass through another "layer" and select the object occluded by the one in front.

Level & Content management [Part 3]

2010-09-07T17:38:00.010+02:00

I got a question about my level and object management recently and was asked if I could talk about it. So in this post I'll explain my old and current method of dealing with (level) serialization and how I combined it with my game editor.

A few months ago I created my levels using a hybrid implementation of a level editor and code to create and connect objects. A game would have several "Scene" classes to be filled with Entities and later set at the correct position in 3D space using the level editor. This worked pretty well, especially since our team had limited time to work on our projects (8 weeks) so I wasn't able to create a fully featured editor at the time. One advantage was the ease of setting up connections and events between objects in a level, because everything is available in the Scene class. An obvious disadvantage was the inability of adding objects on the fly (in runtime) it required some planning to work efficiently. With the game Needle Juice there was only a limited about of objects that required the use of the editor, so again, a fully featured editor wasn't necessary.

However, after completing Over Night I set aside some time to work on a more complex editor to aid in the upcoming project(s). This meant a new way of serializing the Scene to store any data. This new method will be explained below, with some code snippets. On a side-note I strongly recommend looking at existing editors (like UDK) Fool around with it, learn its basics and see what fits your needs and what doesn't. I occasionally opened up an existing Unreal Tournament 3 map and messed around with it to hunt for new features. If you're the only developer to use that tool you can mold it to your exact specifications and preferences very easily.

Before I go on, the following is in no way the only or the best way of doing it. It worked for me and should be easy to implement for yourself. It will hopefully give you a clear idea of you can combine your own requirements with the examples shown.

First off, any object that exists in my level is an ISceneEntity (interface) with a Position, Rotation, Scale etc. The interface holds data that is necessary for any object in the world. Any class that derives from this interface or any other subclass may have its own properties that need to be serialized as well. That means a flexible serializer is required. Luckily Shawn was so kind to explain everything you ever wanted to know about IntermediateSerializer. I recommend you read through his article.

To store all data in your level your engine needs to know what to serialize and what to ignore. I use a fairly simple Level class to keep track of any objects currently in the world (and part of the serialization list) You add your Entity to a List in your Level class. The IntermediateSerializer will go through the list and store all Entities in an Xml level file.

To actually store your level you need to call the IntermediateSerializer.Serialize() to write all of the level data to your disk.

The above method is part of the Level.cs class.

If you're following along, don't forget to add the Microsoft.Xna.Framework.Content reference to your project folder. By default its already part of your Content project, when referencing in code, you need to add it to your game project as well. The IntermediateSerializer class is part of the Microsoft.Xna.Framework.Content.Pipeline.Serialization.Intermediate namespace.

Your level is now stored on disk. Some class will require setting some Attributes in order to be stored properly. Use the [ContentSerializerIgnore] Attribute over any public property that you want excluded. Use the [ContentSerializer] Attribute to include private or protected variables.

Finally to load all of your previously stored data you need to call IntermediateSerializer.Deserialize(). For more info I recommend reading through some of Shawn's articles about it.

I was going to talk about a new feature (mentioned in my previous post) that allows preloading of assets, reducing overall idle-time. This post is already long enough so I'll keep it in mind for some other time.

I hope this helps anyone looking to create his own editor. Level serialization isn't a complex operation, the most important thing is properly structured component system. If you have any questions you can post your comments in the comment section below.

Engine Update: New Features & Tools!

2010-08-29T17:52:00.007+02:00

It's been a while since my last post. That means I had a lot of time to add new features and spend more time on existing features as well. I'd like to include them in a video soon, for now I'll do a quick rundown of the most important new additions to the engine.

Preloading of Assets

Load Models, Textures, Video, SoundEffects in the background (Separate Thread) before the complete level is setup. The engine reads part of the level file and pulls out all the required assets for the upcoming level and load them before the game initiates a level transition.

Undo/Redo system
I Finally took the time to integrate this into the editor. For now it works primarily on SceneEntities (anything part of the level) and can undo translation/rotation/scale.

System messages

The system will "ping" important messages and warnings to the top-left corner of the screen, warning you of possible errors. (See above)

Game Properties Window

Allows you to set Engine properties as well as user-defined game properties, very useful when debugging.

3D Text Buttons

Selectable by mouse, useful for either ingame activators or 3D menus. Text is baked into a texture at runtime and stored on disk.

Improved Object placement

It's now possible to add objects using the Quick-menu (right-click popup) objects will be placed on the position the mouse is pointing in 3D.

Maya style navigation/orbit camera

Holding down "L"-key will orbit the currently selected object, scroll-wheel will zoom in/out.

VisualScript & AnimationEditor improvements

Added a lot of new Node-types and added the ability to directly add an animation to a new script.

Material editing inside VisualScript

All (Sunburn) material effects are stored and can be accessed using Script Nodes. Useful to dynamically set textures and other shader properties etc.

File browsing inside VisualScript

to easily attach files (Textures, Models, Levels etc.) to a Script Node.

I consider these the most significant changes/additions to the engine. Other things will show up in the next video.

Soon a new project will launch, lasting 4 months in total (instead of the previous 8 weeks we were given when building OverNight & Needle Juice) It's targeted towards XBLIG (Xbox Live Indie) and should be the first game to be fully developed (previous projects were prototypes, not full games) and released on that channel. I'm looking forward to get started, and will of course update on the progression of the game...

Engine Update: Shaders & Editor Additions

2010-07-28T03:14:00.007+02:00

It has been a while since my last update. The image below shows some of the things I've worked on these past few days...

So what's new? First off, the shaders might have caught your attention, the lava is flowing and the arrows are flashing which you can't see in the still image unfortunately, I'll make sure to include them in the next video. They were really just experiments to get some practice with shaders and was hoping to use it for a material editor I was working on (had to put it on hold for now) Still, I think they look pretty cool (especially when you see them in motion)

The next thing you can see on the image is the ContextMenu (pop-up menu that appears when you right-click) Its part of the Editor and is rendered inside of the XNA Game window. XNA is still running as it is used to, winforms is added to the XNA window not the other way around.

As you can see there are several useful options inside this pop-up window. You can quickly add new Entities, add selected entities to your current script and continue playing or restart the level using the changes you made in edit-mode.

Hopefully I'm able create another video soon, showcasing some other additions that were added over the past couple of weeks. In the meanwhile I'm working on a game prototype, this directly aids in build the engine as well...

Core Engine: Creating a simple level (Video)

2010-07-11T00:25:00.004+02:00

I'm back with another video, this time I'll show you the creation of a (very) simple level. With The purpose of demonstrating some of the new additions, including the Animation Editor and the updated Visual Scripter. The video playback speed is set to x2 to reduce the overall length. Hopefully you'll enjoy watching and get a bit of insight in the engine's development capabilities.

The menu system shown in the video above is a WIP, originally all level objects were added at build-time. It's a big change in overall engine design to get these things working flawlessly with the new system. The core is aimed at rapid development and tweaking of the game/level while playing. It's been like that since day one and the new system should compliment that, increasing flexibility of the engine and speeding up the overall process of creating games.

Visual Scripting Editor (Video)

2010-07-08T06:44:00.003+02:00

It's 6:45 in the morning and the scripting editor is finally ready for a short demonstration. Spend most of the time cleaning up the node-system and made it a LOT easier to add additional node types in the future. The scripts are now directly stored inside the level file and can be stored separately if desired (for re-use in other levels)

In the video you will see two simple scripts, one animating a box and the other toggling a point light on and off. You'll also see the new Level Manager window, more on that later.

(Watch in HD & Fullscreen!)

Scripting for Artists (and programmers)

2010-07-05T00:51:00.003+02:00

My last entry was over a week ago, but I've been very busy with C# nonetheless. The most interesting (to me at least...) is a visual scripter I've worked on for the past 4 days. It's supposed to work very similar to UE3/UDK's "Kismet". If you don't know what Kismet is, don't worry it is explained a little further in this entry. Although the visual scripter or artist-scripter (as it would be most useful to non-programmers) is not the only thing I've worked on (Animation Editor is another thing that is currently WIP), but I'll only talk about scripting for now.

The past couple of days I used MEL (scripting in maya) Unity Scripting and Dragon Age scripting. They all are terrible to get into. They are probably great if you spend a lot of time learning them, but I usually spend only a very limited about of time on any of those scripting languages. Now for "us" programmers it's not that hard to learn a scripting language if you take the time, but for artists and level designers whom only occasionally need to write a script it's very helpful to have a tool like Kismet. See below...

Example script made in Kismet.

Kismet is not designed to replace the regular scripting language in UE3...it's a tool to help create simple (and sometimes more complex) scripts for level specific behavior. The more complex and game wide scripting can only be done with the regular scripting language. Even though I'm a programmer and can probably live without this tool, I still decided to create something similar, as a challenge, a cool new feature and because it could prove to be very useful when working on our next game...

So far, the basic system is in place and working properly. I hadn't really worked with Winforms nor Event driven programming before, so this was a great way to get into that.

My own visual scripter implementation (visually still very unpolished)

Progress so far: A new script can be created at runtime, nodes can be dragged around, connections between nodes can be created and the whole script can be saved and reloaded to and from the hard drive. A few simple scripts have been created so far (ea. playing an elevator animation when the player enters a volume)

Similar to Kismet, you can load an animation file (previously created in the Animation Editor, more on that later) and play it when the assigned trigger is fired (Can be something like a level has completed loading or the player entered a trigger volume).

I should be able to demonstrate all this in a video shortly, first I'll continue working on essential usability features...

Be sure to keep an eye on my YouTube Channel if you'd like to get an early glimpse of the Scripter in action (I'll upload a video as soon as I feel it's ready to be recorded)

Post-Processing Volumes

2010-06-28T04:27:00.005+02:00

This time I'll keep the words to a minimum and let the images speak for themselves...(more info below)

Base Image

Increased black-point

Cold tint

Warm tint

If you've ever tried Post-Process Volumes inside of UDK/UE3 then you'll be familiar with the concept. I've tried to replicate a lot of its features. You can affect highlights, midtones and shadows (as seen in the images above) as well as bloomscale, blur, noise etc. They all react to the position of the player (inside or outside of the volume) and will transistion between the values when you enter/leave the associated volume. I'll upload a video of that later on...On a sidenote, I've made a lot of progress with the animation editor, more info on that will be available later on just like the video :)

Engine Update: (Finally?) Switching to Winforms

2010-06-26T00:17:00.006+02:00

You might argue it's about time the engine got a proper interface, I agree :) I was trying to avoid using winforms (to keep compatibility with Xbox easy and maintainable to name a reason) and using the console for most if not ALL runtime actions (except for the Gizmo) I had my reasons for not using winforms, but after rethinking the overall design of the engine, its time to do things a little bit different...

One of the reasons that got me doubting the usability of the current interface is a new (and still WIP) feature for creating animations at runtime. The goal of the Animation Editor is not to create complex character animations, but rather allow the creation of quick and dynamic animations for rigid objects such as doors and elevators. At first I made it compatible with the Console like any feature prior to this one...It works, but is definitely not the best way to do animations. It's hard to know what keyframes are used, and what the timelines looks like...I made a very simple elevator animation (with acceleration and deceleration) and it does work...however it's not very flexible, at all.

That got me thinking and finally got me to try winforms...After an hour of experimenting, it finally worked. I'm pretty new to winforms, but it surprised me how easy most things can be achieved with very little effort. For starters I made a "Search Actors" window as well as a "Object Properties" window. Both are shown below. (Click on image for full-size)

The Search window can be activated using "Ctrl-F" like many other applications, clicking the "properties" button with an object selected will show its...properties.

I have a few other browsers/windows I'd like to get working on in the next couple of days (Tracker window, Content Browser, Animation Editor) I'm currently looking at UDK (Unreal Development Kit) for inspiration on browsers/windows. Their Content Browser is pretty great, and would really help with game development if Core Engine had something similar.

During development of "Over Night" we did lack a proper naming convention and both the asset naming and asset count quickly got out of hand. In the end it took a lot of time to find the proper texture file or locate a specific model.

I think I've talked enough about winforms for now :) I've got a few other features lined up, most of them are already working properly, but are still in early alpha stage...

Engine Update: Scripting, ReverbVolume & Tracking Window

2010-06-20T05:37:00.003+02:00

The first one is the ReverbVolume as seen in other game engines like Unreal Engine 3. The volume is very useful when defining rooms,allowing you to alter sound properties when either inside or outside of the volume. The volume alternation is already working when inside or outside of the volume, ironically the only thing that is not yet in place is the Reverb effect itself. I'll explain ReverbVolumes a little more in-depth later on once I've completed finished it, hopefully including the actual Reverb effect instead of just the volume/pitch modifiers. In the video on the bottom you can see/hear it for yourself.

The white box is the reverb volume, the blue circles are ambient sounds emitters (or actually the radius of the emitter)

Another concept I've been experimenting with is a sort of Tracking Window (or output/clipboard window) It's an additional (and optional) window that you can use to print out useful information. You can choose to print it as a static string. As a sort of clipboard/memory aid to help with Vector positions or pretty much any piece of info you may need to remember in runtime. If it were nothing more than that, it would pretty much be an in-editor notepad...So I added something I like to call "live-tracking" (or real-time tracking, or just tracking...) You can use the tracking feature to keep track of any property an object may have (positions, rotations, scale, volume, pitch, visbility etc.) the window uses a series of Slots that can be filled with one traceable object each. Most of it is already working, I'll have to spend some more time on it to add every little detail. Eventually I'd like to have each slot assessable and allow user input to change any of the properties that is being tracked by the window. You can see a sneak preview of it in the video below.

The tracker window is tracking the positions of 3 objects in the scene.

The last thing I worked on today was a basic scripting/event system. In both "Needle Juice" & "Over Night" the event code got really messy over time, requiring a lot more time to find anything...which is a complete waste of time, especially when you're nearing the end of a project. In order to prevent this from happening again I need to have a solid and clean system to handle events and scripts. So far I redesigned the TriggerVolume class used for any positional triggers and added support for Enter/Leave Volume events. To test the new system I made a (simple) script that opens and closes a door when the player approaches.

All of the described features above are shown in the short video below. Make sure to turn on your sound, because the reverbvolume can only explain itself with sound ;)

The first sound you hear is that of a bar, the second is a bit more difficult to hear, it represents the streets just outside of that same bar. when you move through the door, the indoor sound will fade to a lower volume while the street ambient becomes more noticeable.

Over Night: In-game screenshots

2010-06-12T23:00:00.007+02:00

A collection of in-game screenshots taken during development of our project "Over Night".

Over Night: Official Trailer Released!

2010-06-12T14:25:00.003+02:00

The first official gameplay trailer of "Over Night" a game made in XNA.

The game was created within 8 weeks with a team of 4 students (and some additional outside help, see below for the full team setup)

direct link

The Team:

Mitch Manders (Design & Modeling)

Jorry Rosman (Concept Art & Textures)

Bas Babroek (Game Programming)

Tom Looman (Engine/Tech Programming)

Special Thanks to:

Paul van Gent (Audio)

Marvin Nooitgedacht (Video Editing)

Davy Jacobs (Animation)

Bo van Oord (Desert Eagle modeling, textures & animation)

Jeffrey van der Heul (Modeling)

Over Night: Deadline reached!

2010-06-11T15:30:00.002+02:00

We have finally reached the deadline of our project "Over Night". We had our final presentation (10min long trailer & making-of) yesterday with some time for others to actually step in and play the game themselves. We're very pleased with the results with only 8 weeks development. Below is a first (dev) video of the game, the trailer will be uploaded tonight...

Video: (Be sure you watch it in HD)

Direct link: http://www.youtube.com/watch?v=qiP9qsv5bX8

More development videos will be online once I get home.

Engine Update: Major Editor/Gizmo Updates

2010-05-31T02:21:00.002+02:00

I've spend some time adding new features to the editor and gizmo to increase overall usability and development speed. The lack of (gizmo)precision among other things started to bother me and was slowing down development of our prototype (only 10 days left!) I've compiled a short list of the most significant changes and additions and turned it into a small video.

Dust Particles with Lights & Shadows [WIP]

2010-05-28T03:21:00.005+02:00

About time for another video, isn't it? We thought it would be cool to have some kind of dust particles floating around near the windows in our game, so I started experimenting with dust + lit particle effects. Unfortunately the DPSF particles won't receive any of the Sunburn lighting calculations, so I made a basic particle system specifically for the dust trails. Currently they receive light and can cast shadows etc. The effect is a bit exaggerated to create a lightbeam effect.

Be sure to watch it in HD if you'd like to see any dust at all! :)

Video: Reflection & Refraction + FluidVolumes

2010-05-27T04:20:00.004+02:00

I just finished a short sample video that demonstrates another combination of Sunburn + BEPU. The video contains both the Reflection/Refraction sample from Sunburn and the FluidVolume feature that's part of BEPUphysics.

(Sorry for the first glitched second of the video, it happend when Youtube converted the video)

On a side note, we've made some amazing progress with our upcoming game "Over Night" all footage/development videos will be released in about 2 weeks. We have been invited by Microsoft (NL) to pitch a demo once we have finished our prototype! We're very excited about that of course :)

BEPU with Sunburn integration Source Available!

2010-05-16T01:02:00.006+02:00

The sample project is finished! :) The source download link is available below.

A quick rundown of todays progress. Multi-threading got added (very easy thanks to BEPU) Cleaned up the code to hopefully help you quickly understand one of the possible ways to fix and maintain a relationship between your physics & your visuals. Spacebar will spawn a lot of spheres into the scene and left/right button will shoot sphere(s) from your current location. Leave your Feedback, Questions or just your thoughts in the comments section below ;)

Image:

What's inside?

* One of the possible ways to combine your physics with your visuals.

* Commented lines explaining the code required to setup BEPU in your Sunburn project

* A basic scene (default start kit from Sunburn) with some additional dynamic objects

* Multi-threaded physics

* A ragdoll

* DebugDrawer to visualize boundingboxes

* Actor class that combines Entity & SceneObject

The "Blades" mesh isn't using his own dynamic collision yet. May be something for a future release ;)

Don't hesitate to report any bugs or other suggestions...

Source link HERE. Enjoy!

(Sunburn is required to run the sample) More info on BEPUphysics here.

Sunburn with BEPU physics: Day 1.

2010-05-15T02:55:00.004+02:00

I've started working on a sample combining BEPU physics with the visuals of Sunburn. Almost everything is working so far, the code will need some minor cleanups before I'll release it. The purpose of this sample is demonstrating one of the possible techniques you can use to combine the physics with the visuals. The source is not yet available. I hope to have it ready & uploaded before the end of the weekend.

For now here are some images & a video :)

The video is using the default Sunburn sample LightRig.

3D XNA Gizmo v0.2.0 Released!

2010-05-05T15:06:00.003+02:00

A new update has arrived. You can download the latest release HERE. The most notable addition is rotation and scale functionality that's been added to the gizmo. Switching between the different modes is done using the keys 1,2,3 on your keyboard. Download the sample and get started!

Game Update: Storage Room Video!

2010-05-02T20:43:00.003+02:00

Storage Room WIP video is done! You can see most of the (textured) storage room models we have so far (without the desk etc. the artist is currently working on it)

I will have more in-game footage tomorrow (TV, updated phone camera etc.)

For now here's the video:

Game Update: Dual scene feature working!

2010-04-30T20:36:00.005+02:00

Hi,

One of our most important mechanics is now finally working! It's the smartphone camera that can see a different world/dimension. By using the phone's built-in camera the player can uncover hidden objects and hints throughout the world. In addition, the camera can see ghostly appearances that are invisible to the naked eye. You can see why it's a big part of our game. So I'm glad that we got it working today!

The phone will see some things that the player normally can't. A player might wonder why a certain light isn't working, if he pulls out his camera he will soon find out that the wires have been cut, which is only visible on his phone's screen. This is just an example of the differences between the two worlds. With the current implementation the scenes can use different models and textures we can use this to keep the player engaged and wondering what has happened and how he can get out...(story will be explained later on)

For the time being I rendered the camera footage to a spritebatch (for debugging), but it's already working on a 3d mesh (as texture) You can clearly notice that the phone (topleft) can see something that the player can't normally see with his own eyes.

Somethings can only be seen with your own eyes...

All objects visible while in Editmode to place objects and debug a lot easier.

Update: Game & Engine features

2010-04-25T16:32:00.008+02:00

It's time for another update. Got a lot of work done yesterday, and I'd like to share it with you guys. First off, the Gizmo finally got the features it deserved. Rotation/Scale feature are now working properly (images below)

Next up is a long overdue issue that wasn't bothering the frame-rate at all so I post-pone'ed it for quite a while. When loading a scene and reading all object-data stored inside Xml, a copy was hidden and maintained in the background (while it shouldn't even exist) In a case of 500 objects/components this would mean another 500 hidden in the background. I redesigned the loading/saving of Xml data and will no longer keep unwanted objects in the background.

Game Update

As I mentioned earlier, we're working on a new project called "Over Night". My role is Engine programmer, so I make sure everything we need for our game is there for the Game programmer to work with. A few features that I added last week are listed below and are shown in the video...

- Character (movement etc, thanks to BEPU for their base character class)

- Scene switching

- Monitor (ingame security camera footage shown on a TV monitor)

- Story notes (story driven notes and hints on the wall, helping the player with solving the story puzzle)

Game Update: Scenes & 3D Audio

2010-04-17T03:24:00.005+02:00

Finally some (two) screenshots of the scenes. Shown below are the storage and security room both part of our upcoming game. In the meanwhile I've implemented 3D audio for positional sound effects throughout the scenes, screenshot included.

On The Horizon: "Over Night"

2010-04-09T22:54:00.002+02:00

We've started our new project this week. It's going to be a horror game. And like last time, I took on the role of programmer. Luckily I now have a fellow programmer in my team, so we can split most of the programming load. My role will consist primarily of Engine programming and profiling to optimize the game's performance, he will take care of the game programming for the next 8 weeks. Like last time I'll try to post regular updates about the game/engine. Mostly programming related of course, with some images & video as usual.

A short summary of the roadmap:

- Managers, single purpose managers for tasks like physics, audio, content etc.

- Multi-threading, a low-priority task. Will only be implemented if the need for more processer power arises.

- Additional Editor features. The current editor is pretty basic, and I'll be adding some additional features to aid rapid development.

- Destruction. Although it's not a feature for our current project, I do have some plans for creating a basic destruction engine in the near future.

- XML Tweaking, a feature currently in the fridge. It might proof very useful for quick tweaking of values.

Of course, this is not all I'll be doing over the next 8 weeks. We have some pretty ambitious plans for this project, and I'm afraid I'll be spending a lot of time profiling and optimizing our game to make it run on an acceptable framerate...

SgMotion v1.1 released last week. Most notable change is the Deferred modelprocessor. Download link and more info can be found at the Community Blogpost I've made over at SynapseGaming.com.

Game Update: Deadline Today! Final Screenshots & Video

2010-03-26T23:19:00.010+01:00

We've finally reached the project deadline. We've presented our game to the teachers and fellow students today. We can be pleased with the results :) As a (probably) last update of this game for now, I've included some additional screenshots for your viewing pleasure. A video will be compiled and added later on...(Update: As promised, the video can be found at the bottom)

Update: Video Added!

Game Update: Bedroom + Reflection!

2010-03-23T02:48:00.005+01:00

Another game update. Not much to say, just watch... :)

updated models and diffuse added. Normal + specular available soon ;) The lights use emmissive coloring.

Closet used for one of our story events...

Reflection! It won't be used for any gameplay/storytelling aspects. It's really just a graphical gimmick...it caused no performance issues so far (game running on 40 fps on laptop)

That's it for now. We still have till Friday to complete this project. Maybe I can compile a short video of gameplay somewhere this week.

Game Update: Apartment Textures!

2010-03-21T22:47:00.006+01:00

The artist did a great job with the apartment textures. They look pretty sweet... :)

We have till Friday to deliver a good 'Serious Game'. We have a very busy week ahead of us, I'll try to update the Blog with screenshots & videos when new assets/mechanics are completed.

Currently my laptop can run the game with 30-50 FPS (1024x576, AAx2) but has the tendency to overheat (100c+) when running GPU intense applications...So final recordings will have to take place on my PC.

Game Update: Models

2010-03-17T21:39:00.007+01:00

The models arrived about an hour ago :) They look pretty cool. Quickly imported them into the scene and setup some basic lighting. Textures should be ready by the end of the week...

Recorded some footage of our game intro. The video is on the bottom of this post. On a side note, most of the voice acting is completed (thanks to Dutchtraveller for his voice-acting work as "The junkie")

Images:

The white text is part of the intro and is not visible once the game is actually playing.

Video:

Game Update: Apartment (Level)

2010-03-14T20:07:00.007+01:00

As promised, the first images of our work in progress apartment ( like last time, models are done by our awesome artist ) Images are taken inside of Max. In-game renders should be ready by tomorrow.

In the meanwhile I've been doing some work for our intro and menu. I'll wait till the models arrive (most likely tomorrow) before creating a video that I'll release to the public...So stay tuned!

Part of the livingroom...

Part of the kitchen...

Closet for the bedroom...

Kitchen...

Bathroom...

Game Update: Character

2010-03-14T01:22:00.006+01:00

Finally some screens from our upcoming (serious) game. Starting with our character. Model is created by one of the artists in my team (Bo) The apartment is merely a placeholder ;) More screens and a video will follow very soon (We're in the last week of development already!)

Character inside the editor...

Shadows... :)

camera position...

Engine Update: Cinematic Controls

2010-03-06T02:02:00.005+01:00

...Another feature for the Edit/Play-mode. Cinematic controls can manipulate camera behavior. Our next game will feature some cinematic moments (more on that later) so having a tool to tweak positions and movement speed quickly and visually can be really helpful. Most of it is already working, additional features will be implemented only if the need arises. To demonstrate I recorded a short demo:

(Watch full-screen!)

Note: The controllers are saved and maintained like any other object in the scene.

Engine Update: Materials in Sunburn

2010-03-04T03:06:00.006+01:00

More screenshots!

The diffuse textures are in fact the Sunburn textures that ship with the default project. Normal/Specular/Displacement maps are generated with Crazybump. Crazybump did all the generation work, and with Sunburn it was simply drag&drop in order to get the current results. A lot of material tweaking can be done with the Sunburn Editor. I might show more about that later, as its only a small test for now.

Note: The floor is very stretched. It probably makes the cubes look better by comparison ;)

Engine Update: HDR/Bloom & Particles

2010-03-04T01:31:00.007+01:00

Two screenshots taken from the demo scene. Features the DPSF particle system (Smoke + Snow) with Sunburn's HDR/Bloom Post-Processor.

I will be focusing on features required for our game the next couple of weeks. So less messing around and more focused building :) The editor will finally be used by one of the designers.

More screenshots and videos will be posted the next couple of weeks (the deadline is at the end of this month already) you can expect some footage of animations, cinematic camera controls, triggers & events and audio.

Update: Another Bloom screenshot (combined with an emmissive map)

Engine Update: Particles, Performance & Profiling

2010-03-01T21:32:00.003+01:00

Since my last update over a week ago, a lot of progress has been made. First steps for Full-Screen post processing (HDR, Bloom, Gaussian) DPSF Particle system is integrated and works perfectly with Sunburn out-of-the-box. Progress has been made with the level & content management classes, loading/saving works great and a new method .CombineScenePart() is currently WIP to combine scenes or scene parts into a single level.

Other features like the CameraManager is coming along nicely and should be ready very soon. The manager allows you or the engine to add/remove and set a certain camera type and modify its properties. Dynamic actors have been updated, they now return to their original position when returning to EditMode (original being the last assigned position by either Xml or the Editor). Moving the dynamic objects while in PlayMode does not affect the EditMode position of that object.

Finally got some time to work with CLR Profiler. I wasn't sure how to use this little tool to my advantage, but after some hours of fiddling with the engine code and running it through the profiler I got the hang of it. Some silly code errors were altered/removed (Like an old and unused Matrix-array being called every draw-call for my game objects, the Matrix-array had no actual purpose it was merely a left-over from a previous XNA draw method. As a final optimization I had a better look at the xml files that were created when serializing my level data. The demo scene (screen in previous post) required 43.000 lines of xml data (The demo scene had about 350 objects) worth a total of 900 KB. It took me less than 15 minutes to get this down to 7.000 lines without losing any necessary data (A easy way was serializing only the Euler rotation property (of type Vector3) instead of a complete rotation Matrix (Thanks to Sean James)) The final Xml file only requires 150KB of disk space. The overall memory allocation have been decreased, it may be a bit early for memory optimizations, but it was good practice for later stages of development...

Unfortunately I have no new video/screenshots right now. I'll try to get some interesting footage later this week!

Engine Update: Multi-threading & BEPU

2010-02-20T01:12:00.005+01:00

Integrated BEPU's method for easy physics Multi-Threading. The Physics class has the following code for Multi-Threading the physics.

if (Environment.ProcessorCount > 1)

{

for (int i = 0; i < Environment.ProcessorCount; i++)

{

Space.threadManager.add();

}

Space.useMultithreadedUpdate = true;

}

What this does is run through all the processors available on your machine and add it to the thread-manager to spread load across all available CPUs. Thanks to BEPU the integration is VERY easy. A pdf + sample is available on their site.

Multi-threading on the Xbox is slightly different, however it shouldn't be a problem considering the available documentation and sample by BEPU.

I still had some time left to test the performance gains using a small demo scene I made yesterday. It's basically a dominos scene with 350+ domino bricks in 3 lines getting knocked over by three boxes slinging through the air. With the debugger still attached the performance drops to 2 FPS at its lowest. Activating Multi-threading on two cores (my laptop has a Core2Duo (T9400) CPU, without Hyper-Threading) the lowest FPS recorded is 31. That is an amazing difference in performance. Another test without the debugger attached didn't get the demo-scene below 60.

Another thing I worked on today are trigger-volumes. These can be used for a number of tasks (audio triggers, portals, level events etc.) BEPU has a very nice EventManager attached to every Entity. With this manager you can easily add events to your game objects. There is not much to see so far, but I hope to have some cool demo scene ready very soon...I'd like to get rid of the boring cubes and show some actual cool stuff :)

Entity.eventManager.addEventHook(new EventHandlerInitialCollisionDetected(initialCollision));

This will fire the attached method only once when the Entity is colliding with another Entity...The fired method could be something like this:

public void initialCollision(Entity sender, Entity other, CollisionPair pair)

{

other.moveTo(new Vector3(0, 10, 0));

}

This will move the colliding Entity to the Vector3 position...More on this in a later video ;)

Image of the current demo scene:

Level & Content management [Part 2]

2010-02-15T04:48:00.008+01:00

Another succesful coding day... :)

Loading object data (position, rotation, scale) with XML is now (finally) complete...

What does this mean?

Every level has his own .xml file containing position, rotation and scale data for each object of that particular level. When loading a level, the appropriate xml file is loaded, assigning any stored data to the correct objects in the current level regardless of the Vector positions inside your C# code. This allows for persistence when building your levels. You no longer have to tweak Vector positions inside your code files, you can easily re-position your game objects while playing...Saving and later reloading when you're ready to play.

Video

Watch video in Fullscreen! Or check out Youtube.

Level & Content management

2010-02-14T02:12:00.007+01:00

I've been prototyping several design concepts on how to manage my content and level data efficiently and easy. After a good day's work this is where I'm at:

- LevelCollection class manages a single LevelData class.
- LevelData class can hold all the game objects in the current scene.
- LevelCollection has control over Loading/Unloading (a particular scene) and XML LoadFromFile/SaveToFile methods (managing positions, rotations and scaling)

All the content is now being managed using Dictionaries. This provides great control over used and unused assets. In the current implementation a method is fired containing all the data of a particular scene. The current assets are compared with the assets required for the next scene. Unused data is unloaded. The remaining asset data is assigned to the proper game object.

That may sound either very straightforward or maybe you've completely lost it by now... Here's a quick summary:

LevelCollection.Load(*levelnametoload*) will know which scene you want to load, and will clear all current data present in the scene and loads all the new scene data as well as comparing current with new assets (models, textures etc.) to check if any new assets need to be loaded and if unused assets need to be unloaded to free memory.

When you're scene is loaded and visible on screen, you can either play it or start messing around with the positions. Changing a Position or Rotation will require LevelCollection.SaveToFile(*filename*) to persist after quiting the game.

I'd like to show a video about this very soon...So stay tuned!

Update: Video available HERE

sgMotion v1.0.0 Released!

2010-02-06T13:58:00.004+01:00

sgMotion is an animation library (based on XNAnimation by Bruno Evangelista) and provides full integration with both the Sunburn Engine and the Sunburn Framework. The project is available for download on Codeplex:

http://sgmotion.codeplex.com/

The library source + Sunburn sample code is provided to get you started! Current release supports Sunburn 1.3.x for both PC & Xbox. For the older 1.2.x release click here.

Note: The previous releases will be maintained for some time using my Dropbox public space. For new releases check out the Codeplex page above.

XNA Gizmo Released!

2010-02-06T02:36:00.004+01:00

Finally got the time to create a sample with simplified classes of the current Gizmo used in Core Engine. It was quite a bit more than anticipated, with all engine utilities and tools used by the Gizmo and EditorComponent (the two main-classes for object movement) some parts had to be rewritten or completely removed.

The project has been published on CodePlex:
http://xnagizmo.codeplex.com/

The project status is set to Beta. Everything should work out of the box. If you run into any issues using the code/sample, leave your comment here or use the Discussions tab on the CodePlex project page.

I hope you enjoy!

XNAnimation Library for Sunburn 1.3.1

2010-02-01T15:10:00.005+01:00

OK, so I finished it a lot sooner then expected. The sample and library is now running on the latest (1.3.1) Sunburn release. If you have any trouble running the sample or DLLs, don't hesitate to ask...

XNAnimation Sunburn 1.3.1 Source & Sample

XNAnimation Sunburn 1.3.1 DLLs

Update: For new releases check out my post about sgMotion Release.

XNAnimation Library for Sunburn 1.2.6

2010-02-01T14:00:00.003+01:00

Hi, today I decided to update a library I had modified some time ago to use with Sunburn 1.2.6. Only slight modifications were needed to get XNAnimation running alongside Sunburn (Thanks to John Kabus at Synapse Gaming) Updated the original sample as well, making it a bit easier to browse through, while demonstrating how to render a skinned model with Sunburn.

I provided two links at the bottom of this post, one with the source code and sample project, and another with only the required .DLL files to get started with your own animations. If you have any questions regarding the integration of the XNAnimation library, please leave your comment below.

XNAnimation for Sunburn 1.2.6 Source & Sample

XNAnimation for Sunburn 1.2.6 DLLs only

Note: XNAnimation .DLL's for the newly released Sunburn 1.3.1 should soon be available...

Engine Update and the future...

2010-01-31T13:47:00.007+01:00

Yesterday I did some work on the engine and added some functionality.

The first one is 'BlockingVolumes' it's now possible to add blocking volumes to the scene, this can be used to efficiently create collisions for high poly scenery where trianglemesh collision might wreck the performance.

Finally added the character controller from BEPU Physics library. Out of the box it can: Walk, turn (look), jump, step (onto stairs and other objects) much like you would expect :P Luckily a camera toggle type was already implemented, so it's now possible to toggle between play mode (= camera fixed to player view) and edit mode (camera in free roam) very easily.

I did some work with custom Sunburn Lights. First off, a candle light. So far it's a fairly basis class that will simulate a lit candle. I hope to include this in a video tomorrow.

On Tuesday, my school will kick-off a new project. We might be required to use Unity instead of XNA. This would pretty much ruin a lot of my plans (to use this engine for my school projects) While Unity is really not a bad tool, I do prefer to stay with XNA. If I do not get permission to use XNA, that does not mean the end of the engine development. However, I will have to cut down on the time I can spend developing it. I just hope they will allows use to keep using XNA (That's what they've been teaching us the last couple of months anyway) If they don't, I'll have to rethink my plans.

On a brighter note, there are some cool ideas to be announced in the near future... It involves Synapse Gaming (creators of Sunburn) and should really help XNA developers with their awesome ideas. I'm not sure how much I can say about it, as it's still only a concept. Hopefully I can give you more information, soon ;)

Editor Update: Physics Rotation

2010-01-24T02:43:00.006+01:00

Just a quick video update. Implemented rotation of Dynamic and Static actors in editmode. For now, rotation is done using the Arrow-keys. This will soon be changed (most likely using a rotation gizmo)

First footage: Edit/Play feature demo

2010-01-19T03:43:00.008+01:00

I've put together a short video, demonstrating the first iteration of the Edit/Play feature. There is yet a lot(!) of coding and design to be done on this feature, but I have a clear vision of what it should look like within a few months of development. Uploaded the first video footage. I hope you enjoy watching! :)

Creating your game while playing!

2010-01-16T04:24:00.004+01:00

It's 4:30 in the morning and I've just finished a good chunck of engine work. Some progress has been made on the console (XNA Console Component) and support for switching 'modes' while playing the game.

The concept: The idea is to allow quick access to any editing tool while playing the game. This may have some pitfalls, but for the purpose of the engine (concept prototyping and school projects) it should be fine. To quickly gain access to these tools, you only need to open the console and type 'editmode' and the editor will change its ControlScheme, Camera and load all editor tools. The gameplay will be pauzed and all AI, physics etc. will not be updated while in editor mode. To continue playing, all you do is enter 'playmode' and gameplay will continue with all changes in effect.

This concept should greatly reduce developing time and will allows other teammates to build levels and tweak values without coding knowledge.

If you have any questions, please leave your comment below...

First BEPU Integration Steps...

2010-01-12T03:17:00.006+01:00

Just a small update this time...

Added some BEPU (Physics) functionality. 'StaticMeshActor' used as the static ground mesh in the video. 'DynamicMeshActor' the movable boxes. And of course the vehicle that can be driven around. Currently BEPU is not a priority milestone for the engine, messing around with physics is always fun however :)

The vehicle is a great starting point to demonstrate XML tweaking in a live scenario. All I have to do is convert all hardcoded values (like grip, torque etc.) into variables and add some XML functionality to the VehicleActor class. I hope to have a video about it by the end of the week. For now, I'll leave you with this:

Tweaking variables using XML (Part 2)

2010-01-09T20:14:00.007+01:00

In my previous post I talked about the method I'll be using to tweak values in runtime. Today, I created some code to demonstrate this method. It's an iterative process, so improvements will follow.

In the provided sample the method is explained using a Vehicle class, with two instances of that class. the static 'FrictionDef' variable will declare the value that every instance of the class should use. a private 'frictionDef' variable will allow an instance to set this static value using the XMLSerializer. You as a developer can manually change the value of 'frictionDef' in the XML file (called 'SuperCar.xml' in this sample) and reload the file to set all instances to the new assigned values in the xml file. You can use this method to quickly change values in runtime on PC. For Xbox, the 'XNA console component' could help us out setting values in the xml file (of course, you will need a 'chatpad' to properly use the console on Xbox) so other solutions are still being explored. I've yet to implement this feature into the engine so I'll save it for a later blog entry.

For PC developers: keeping this type of gameplay specific data in easily readable XML format, will allow for easy cheating by players. You might want to consider running it through the content pipeline (as binary) when you're done tweaking. Alternatively, you might simply remove the whole code used to tweak, and assign the values to the variables in your source code. Doing so, will still safe you a lot of time compared to rebuilding your project for every slightly changed variable while tweaking your game.

Some articles of interest:

Shawn Hargreaves Blog: MotoGP Tweakables

Luminance: Changing constants at runtime

Link to sample code:

XML Tweaking Sample

Video

Tweaking variables using XML

2010-01-09T03:59:00.002+01:00

A few months ago, I was tasked to tweak a car to behave like an actual vehicle (using XNA). Nothing close to a simulator, but a task like this can take up weeks of your time if you don't have proper tools. I did not have proper tools...

With a fresh project coming up (got till about April to work on the engine, before I can put it to use for another school project) I can take some time to develop tools like the one mentioned before. I've no current plans to develop these tools for a wide audience, this makes it somewhat easier to code them. I do of course release snippets and full source when applicable. Most of my current code works, but is not qualified to be released without a proper cleanup. Releasing something to a wide audience of programmers without fully debugging or tweaking your code is not in anyone's best interest.

Like a lot of other previous posts, this one will be cut into two parts. The first part I will talk about a possible method that you can implement into your project/engine when trying to save time tweaking. The next part will show an example (with snippets etc.) using this method.

If you've ever made a game before, you will know how much time fine-tuning or tweaking any object in your game can consume of your total development cycle. To help reducing the amount of time spend building and rebuilding your game with only slight changes in your character's run speed, you need a tool. I use XML to help save time. It's still a work in progress, but tests have shown good results so far. I'll explain the concept below...

Every class that uses constant values that should not change during runtime (i.e. default run speed or friction in a spring) can be tweaked using this XML method. The tweakable value is not a 'const' as this would not allow us to change its value in runtime. Instead we will use a 'public static', which holds the value that is used for every instance of the class. to Get/Set this value with XML (explained in more detail in the second part) we will need a 'private (non-static)' value.

public static float FrictionDef;
private float frictionDef
{
get { return FrictionDef; }
set { FrictionDef = value; }
}

In its current implementation you will have to manually open the XML file created for the class (one XML file for every class that uses tweakables) in a text-editor and change the value to anything you'd like in runtime, saving the file and reloading it using a simple key command in-game will load your new values to the 'public static' variables. Any instance will now use the new values and you get direct feedback on any changes made.

I will go more in-depth of the coding required to achieve this in part two. And provide a video with the implementation in effect (if time permits)

End of the Year...

2009-12-30T22:28:00.003+01:00

So, it's been a pretty good year and all, but I won't talk about all that...

Since my last blog post I've mostly been doing non-programming related things. To give you a bit of an insight in things to come I made a very small list of topics that I'm going to talk about in the coming weeks.

- XML Tweaking (tweaking 'constant' values like player runspeed in runtime using XML)

- XNA Console Component (I've used the XNA Console Component (by Kevin) and I will talk about integration of numerical values to set things like gridsize, as seen in a previous video on this blog)

- Tutorial about the 3D Gizmo. People have been asking me to release the source/snippets of the gizmo code, so I'll think about creating a tutorial or simply releasing it as full source project.

- More lighting and texturing with Sunburn.

- Possible beginners guide to integrating sunburn into your new/existing game.

...And of course there is many more that will follow. These topics are just a few things I have in mind for early 2010. I hope you will enjoy them. If you have any suggestions, please leave your comment below.

Line rendering part 2.

2009-12-25T00:28:00.002+01:00

Mostly just some screen caps and a video to showcase the grid. It’s basically centered, re-colored and two special lines are added that indicate the exact middle of the scene.

The further you get away from the lines, the more constrast you will notice between the two colors.

Close-up view of the grid, not much more to say :)

Lines are very difficult to see in the video...

How to render a Grid...

2009-12-24T15:16:00.000+01:00

As I previously mentioned. I’ve been working on a grid for my game. So far the grid has been working, but was not visually present in the game. There is a good MSDN tutorial explaining how to render a line in your scene. MSDN Points, Lines and Primitives

It’s a good starting point if you’re trying to implement your own line renderer for your game. Luckily for some of us (Sunburn owners) this has been done for us by Synapse Gaming. It’s called the LineRenderHelper() and can be utilized for easy line rendering. Below is the result of a quick setup with the line renderer.

How it works…

You simply create a new LineRenderHelper() and pass it the maximum amount of points your grid will contain. Every line has a start and end point, so it’s 2 vertices for each line.

LineRenderHelper line = new LineRenderHelper(100); // This will create the helper with a maximum capacity of 100 vertices, or 50 lines.

Method for setting up the array of lines to be drawn.

public void SetGridLines(int grid, int lines, Color color)
{
   for (int i = 0; i < lines; i++)
   {
   line.Submit(Vector3.Left * grid * i, (Vector3.Left * grid * i) + Vector3.Forward * (grid * (lines - 1)), color);
   line.Submit(Vector3.Forward * grid * i, (Vector3.Forward * grid * i) + Vector3.Left * (grid * (lines - 1)), color);
   }
}

This code will set up the array of lines. I pass a grid (empty space between the parallel lines) , lines (amount of lines that should be drawn) and the color.
To submit a line, all you need to do is call the Submit method.

   line.Submit(*start_vector3*, *end_vector3*, *color*);

This will add a single line to your renderer. If you try to execute your code, nothing will show on screen. This is because the helper is not automatically drawn. You need a BasicEffect to do this.

Draw Code:

// Setup your basicEffect
basicEffect.World = Matrix.Identity;
basicEffect.View = camera.View;
basicEffect.Projection = camera.Projection;
basicEffect.VertexColorEnabled = true;

//Start the effect
basicEffect.Begin();
foreach (EffectPass pass in basicEffect.CurrentTechnique.Passes)
{
pass.Begin();

//render all lines stored inside the helper class
line.Render(Engine.GraphicsDevice);

pass.End();
}
basicEffect.End();

This is pretty basic, and should not need much explanation if you’ve ever worked with BasicEffect. If you’ve placed this correctly in your draw code, you should now see the lines on screen.

Of course, like mentioned before…You need Sunburn to use this helper class.
Sunburn Framework is currently in Beta. If you’re interested in using Sunburn, you should definitely sign-up and start using Sunburn. Sunburn Community Forums

Results of a quick stress-test:

Up to 200k vertices the scene would run fairly smoothly (on my laptop Asus M50VN) stressing it up to 1.000.000 vertices (making 500k lines) got my FPS down to 5. But it was still very possible to navigate around the scene. You only need a few dozen lines for your scene at any given time. So should not ever run into trouble with your FPS because of your Grid, which in the end, will most likely not even be rendered in your final game.

Game State Management with Sunburn

2009-12-22T20:18:00.002+01:00

GameStateManagement_Sunburn.rar

A quick post, about the infamous GameStateManagement sample from XNA Creators Club combined with Sunburn Lighting en Rendering System.

I made this in reply of a forum post made on the sunburn forums. You obviously need Sunburn to use this sample.

What it does...

I simply used the 'Sunburn Simple Integration' code provided with Sunburn 1.2.6. and combined it with the GSM sample from XNA CC. The code is provided 'as-is' and all credit should to go the XNA creators and Synapse Gaming.

Holidays and upcoming changes

2009-12-22T02:17:00.001+01:00

Hi,

First of all, happy holidays everybody! It's (most likely) going to be the first white christmas in the netherlands since 1981 (I wasn't even born at the time!)

Altho, it's not all as well this time a year. Someone broke into my Gmail account and probably did some things. So far, the damage isn't so bad, it mostly feels weird when someone is trying to steal your identity. So I'm trying to get all my things back together and make sure it won't happen again...

For now tho, I've been enjoying the holidays and haven't spend a lot of time on the development project (not much since my last post) But, I have plans...I'm going to draw out a complete overview of the engine's structure (and will most likely post it here) to get myself back on track. I was working on so many features at the same time that I lost myself in all the work. So taking some time this holiday to slowly get back on the right track, aswell as taking some time to finally design some games.

I have some homemade challenges that I'd like to complete, to get my mind of engine programming for a bit (in the end, I'm building this engine for game design, not to become a world class programmer)

So to all who's reading this (and everyone else!) MERRY CHRISTMAS!

Using Transparency with Sunburn

2009-12-20T02:43:00.000+01:00

After using my old-timer model in the previous demo (with physics) I noticed the wheels were not as transparent as they should be. The problem was pretty easily solved. I set the Transparancy to ‘Clip’ and it was fixed. As I was already prepared to spend a lot more time on transparency, I decided to test the alpha quality and shadow map when using alpha’s.

To spare you the boredom of reading. I compiled a few images and a video to demonstrate my first night of playing with Alpha/Transparency.

Result of changing transparency mode to ‘Clip’

Close up shows black lines around the spokes, this is due to my (bad) texture skills :P

Quick patch-up in Photoshop, adjusted the texture file (removed most of the blackness)

Quick overview of the effect when changing Transparency value.

Video: Some fun with lighting and shadows using Alpha Textures.

That's it for today, if you have any questions or comments, please post them below...

BEPU Integrated...Today!

2009-12-19T23:15:00.000+01:00

There is not much to show today, unfortunately. Most of my work today involved removing the old JigLibX code and replacing it with BEPU Physics.

I did some basic primitive collision tests, dynamic vs. kinematic and a triangleMesh test (done with a 1100 poly car model) So far, no real problems occured. I have to create a new and solid system to add (and save) collision models to later reload into my game.

So, next on my list is to finish the StaticMeshActor class I've been working on. It's not very complex, but should form a solid base for all static meshes in the game.

I hope to have more to show by tomorrow...

Note: the vehicle collision is a ConvexHull, and the Box is made of a...Box.

If you're interested in BEPUphysics, check out their site:
BEPU Physics

Editor Basics (Viewports)

2009-12-18T14:19:00.000+01:00

Yesterday I got to work on the viewports for the stand-alone editor. It will be using the same layout as most other 3D applications (UnrealEd, 3Dsmax and Maya) so it needs orthographic and perspective viewports.

To set this up, not much work is needed. First I created a new camera class called ‘OrthographicCamera’ inheriting from Camera.cs (that’s is my base class for any camera) To create an orthographic view you will need Matrix.CreateOrthographic()to create your Projection. This is fairly straight forward and should not be too much of a hassle to do. To add ‘Zoom’ functionality all you need is a value that can change the width/height of the orthographic projection. I used my viewport width and divided it by a zoom value that could be increased/decreased using the zoom keys.

Next on the list was a system that allows 4 viewports to be rendered on the screen. This aswell is pretty easy to do. If you’ve ever created a split screen option for one of your games, this won’t need much further explanation. If you haven’t, I suggest you read MSDN Splitscreen It’s a great example of how to implement split screen into your game. The editor viewports work pretty much the same way.

Most 3D applications have the ability to either render Solid geometry or change to a Wireframe rendertype. It can be very helpful to allow your Orthographic views to render wireframes instead of solid geometry. It’s very straightforward to do in Sunburn. For every rendercall (you call it once for each viewport) add a Fillmode enumerator (Microsoft.Xna.Framework.Graphics.Fillmode) and set it to either Fillmode.Solid or Fillmode.Wireframe. With Sunburn you will simply call your ‘RenderManager.RenderFillMode = Fillmode.Wireframe’ and you’re done. This can be optimized (I try to avoid setting renderstates as much as possible) so I will get back on this later on.

If you do not own a copy of Sunburn, you can use the following line to create the same result.

GraphicsDevice.RenderState.FillMode = Fillmode.Wireframe;

The picture below is a quick draft of the editor layout. It’s nothing special and looks like any other editor you can find on the internet. My main goal is to make it intuitive and quick. A recognizable UI will help achieving this.

Note: The engine will not only feature a stand-alone editor, but will accompanied by an special in-game editor. This editor will make heavy use of the integrated Console, Gizmo’s and XML. More on this in a future blog…

Gizmo...[Continued]

2009-12-16T14:54:00.000+01:00

As Matt requested in his comment, I'll go a little more in-depth with the Gizmo system described earlier.

First off, it's not a very complex system. I use the .fbx mesh (three arrows) simply for the visual representation of the axis. The actual magic happens in an invisible level, using Rays and BoundingBoxes.

Every axis (arrow) has a boundingbox roughly the size of the arrow itself. Called something like "BoundingBoxY" or just anything that would make sense for an upward pointing boundingbox.

Whenever I try to select the gizmo with my mouse (left-button) it will check whether it's active, if that's true, it will cast a ray to see which BB is hit, if any.

At this point you will probably see where I am going...Holding the mouse down and calculating the Delta of the X and/or Y mouse axis, you simply add these values to the position of you selected object (Don't forget to update the position of your gizmo)

I really hope this will help you towards creating your own Gizmo. If you remain with any questions, please ask in the comments below.

I can't give any particular Code Snippets yet, as it's a WIP. It's still unoptimized(but working) code. If I happen to finish the code completely I will post a sample somewhere so people can use/learn from it.

Gizmo...

2009-12-15T16:06:00.000+01:00

You may notice the console in the top halve when I'm changing the grid size...
This is the XNA Console Component by Kevin Jurkowski. Modified by me to allow numerical values for use like the grid size. It's the same for the Gizmo, it will need some cleaning up before I can call it final (I will probably upload the source later on, but not before I feel it's clean enough to do so)

If you're interested in any of these techniques, leave a comment below.

(Update: I noticed that the console is unreadable due to the small size of the video on blogger, I will try to find a fix for this)

Submerged (School Project)

2009-12-15T01:37:00.000+01:00

Unfortunately the game could never reach a 'final' state, so we haven't spend much time tweaking of...anything. Player model was supposed to be just a placeholder, but was kept ingame till the deadline.

Fortunately we all learned a lot in the proces of creating this game. And I can re-use a lot of the technology added into the engine during development. Such as animation and sunburn rendering.

If time permits I will add a gameplay video later on...

Update:

Using the Engine

2009-12-14T21:22:00.000+01:00

My latest school project was built-upon the CoreEngine. A lot has changed during the development of that project.

Animation support was added (Video features XNAnimation and their PlayerMarine)

Sunburn Lightning & Rendering was added to the engine...

More integration with JigLibX and NPC pathnodes...

And ofcourse a lot of bugfixing :)

I will post some screenshots of our final product, called Submerged (as far as we could finish it during our 4 weeks of development)

More of this in a later Blog.

Welcome

2009-12-14T20:54:00.000+01:00

Welcome to the Core Engine's Development Blog. Here you can read about the development proces of my 3D XNA Engine. Based upon the Innovative Engine by Sean James.

In my blogs I will talk about newly added features and give some basic examples to work on yourself.

I hope you will enjoy reading this blog. If you have any questions or comments, just add a comment below the blog.