Hello SunBurn community!
We’ve just released the latest SunBurn Game Engine update; version 2.0.13 – which is now available in the Downloads section!
This is a very exciting update that focuses on enhancing the overall user-experience for developers and artists alike. It includes new features like:
- Background importing – continue working while importing large assets or many at a time
- New Visual Studio templates – create new components, plugins, and managers in a single click
- Lower release requirements – release Windows games requiring only the XNA Redistributable (~6.7M)
- And more!
The update includes a few enhancements that change how certain objects behave and select areas of the API, while these changes are small I thought they’re definitely worth mentioning.
Shared Materials
As mentioned in my previous blog materials are now shared across all models. This means if two loaded models both reference the same material file, they will both contain the same instance of the material / effect object.
This reduces memory usage and load times of games – and also allows the editor to present a single instance of the material in the Materials tab, making scene editing easy.
In the past two models referencing the same material file created two separate material / effect instances and we know some developers are using this quirk in their games, so the new behavior can be disabled using:
ResourceManager.ShareMaterialsBetweenModels = false;
Or by cloning only the effects that need to be unique in code (recommended):
Effect clonedeffect = originaleffect.Clone();
ObjectType is now UpdateType
In SunBurn 1.3 the ObjectType enumerator indicated whether an object was Static (never moved) or Dynamic (moveable and the scenegraph tracked its movement).
This was an excellent solution at the time, however over the past few months new features have been added that took advantage of the enum and made the meaning a bit less clear.
As an example in previous SunBurn 2.0 releases:
- Static objects
- Were not tracked by the scenegraph
- Could be light mapped
- Could not be affected by gravity or receive update events for components
- Dynamic objects
- Were tracked by the scenegraph
- Could not be light mapped
- Were affected by gravity
- Did receive update events for components
On the surface this seems ok, however what if you have light mapped objects that need to use components? Or moving, collidable objects that should not be affected by gravity?
To make this more flexible in SunBurn 2.0.13 the ObjectType enumeration was replaced with the new UpdateType enumeration and the new AffectedByGravity property.
With this new design the UpdateType enumeration controls:
- Objects set to None
- Are not tracked by the scenegraph
- Do not receive update events for components
- Object set to Automatic
- Are tracked by the scenegraph
- Do receive update event for components
The AffectedByGravity property controls if objects are affected by gravity (even when the UpdateType is Automatic). Likewise the LightMapped property can control if objects are light mapped independent of the UpdateType.
This new design is far more flexible, and is very easy to transition to from the old ObjectType design.
Collision Members
To help make integrating custom and 3rd party collision and physics systems even easier, we’ve refactored portions of SunBurn’s built-in collision system.
The changes were small, but effective:
- SceneObject.React(), which is specific to the built-in collision system, was moved from SceneObject into the CollisionMove object (and ICollisionMove interface)
- ICollisionMove interface only exposes general collision / physics methods and properties
Now SunBurn’s built-in object movement and collision handling is completely contained within the CollisionMove object.
And new collision / physics systems can be implemented by creating a class derived from ICollisionMove that interfaces the 3rd party / custom system, and assigning instances of the class to scene objects.
If you have code that relied of access to the CollisionMove members, but uses the ICollisionMove interface, you can access them again by casting the interface to the CollisionMove class:
(obj.CollisionMove as CollisionMove).Begin();
With this minor change all existing collision code will work like before.
Get it Now!
There are a ton of awesome enhancements and improvements in this update. Make sure to check out the release notes for more goodies. :)
Let us know if you have any questions or comments!
-John Kabus
Other SunBurn 2.0 Blogs:
- Announcing the SunBurn 2.0 Game Engine - free upgrade, new editions, and updated features
- SunBurn 2.0 Collisions, Scenegraph, and Components - new collision system, components, and more
- SunBurn 2.0 upgrade for our Torque customers - upgrade path for all of our previous TLK technology customers
- SunBurn 2.0 goes Mobile on Windows Phone 7! - full Windows Phone 7 support, light mapping, and more
- Holiday, Components, and more! - read about the new components and more
- SunBurn 2.0: components, perfabs, and more! - more details about SunBurn's new component system
- Festive SunBurn 2.0 Starter Kits, yum, yum! - first release of the new SunBurn Starter kit
- SunBurn 2.0.10 update available - streamlined user experience and integrated starter kits
- SunBurn Dev Journal: Scenegraph Optimizations - faster scenegraph and City Demo with 10,000 buildings
- SunBurn 2.0.12 Update Now Available! - edit components and custom scene object types in editor
- SunBurn Update: Windows Redistributable - ship Windows games using only the XNA Redistributable
- SunBurn Dev Journal: Workflow Enhancements - background importing, shared materials, Visual Studio templates, and more

Posted
04-01-2011 7:53 PM
by
JohnK "bobthecbuilder"