EditMesh Submode & History Panel

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

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

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

Gizmo update coming soon!

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

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

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

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

Image Collection

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

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

Vertex Manipulation [Compound objects]

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

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

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

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

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

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

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

Resources

App Hub - Triangle Picking Sample

Nick Gravelyn's Triangulator (2D)

Triangulation By Ear Clipping - by David Eberly

Input & Hotkey Management

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

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

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

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

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


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

Vertex Manipulation (Mesh-editing)

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

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

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

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




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

Updated blog layout

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

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

An objective-based level from Project Sunburn

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

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

Environment Mapping (w/ Normal Maps)

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

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

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

Forward shader - similar setup as above.

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

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

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

Resources:

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

A new (Deferred) Renderer [Part 1]

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

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

Some other experiments include texture projection as seen below.

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

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

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

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

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

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



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

The result can be seen above...

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

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

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

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

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

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

'Depth Dependent Halos' for Wireframe rendering

'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

"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)

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

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)

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

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

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.

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!

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!

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

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!

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

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)

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

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