For the sake of not pestering the Generations resource thread for the ones who actually CARE about resources there, I'm splitting off the discussion of my editor in here, and also sharing all the information I researched so far in case anyone wants to try it on their own. Also, the editor is pretty much feature complete at the moment when it comes to level data format and templates so far. What's needed at the moment is raw models, templates tweaking, lots and lots of game content that needs ripping and being distributed with the editor.
SonicGLvl - Visual 3D editor for level objects layouts
- Loading XML or AR.00 files directly as levels.
- 3D camera controls and edition.
- Customizable model previews of in-game objects, can be fully extended later using a template database.
- MultiSetParam array support for creating copies of a single object easily.
- Ogre3D engine ensures a pretty good performance all around.
- Saving back directly to the AR.00 or XML files, ready to import straight to the game.
Hosting and Downloads
I will host SonicGLvl on Google Code, although I haven't opened the source code yet. SVN will allow me to keep a common database of the objects so far ripped out. Also, this would help people to not have to download a whole new version of the editor, just for adding a simple template. Using SVN update, you can just download the latest changes.
SonicGLvl on Google Code.
Checking out the latest SVN(for use for anyone who was the tools):
svn checkout http://sonic-glvl.googlecode.com/svn/trunk/ sonic-glvl-read-only
Also, for the users who obviously ain't gonna download SVN tools just to check out the program, I will upload stable "snapshots" of the repository periodically. In other words, you will be able to download the latest uploaded version on the Downloads page.
- Do not use fullscreen mode or you'll be locked out of any "File Open" dialogue Windows pops up.
- You can limit the FPS turning VSync on
- If it looks like crap, you can put some FSAA to improve the looks
- Look over at the help menu for a "Quick Overview" so you're not completely lost with the controls.
- There's some focus issues with the windows. So make sure of what you click.
Who can contribute to SonicGLvl
The program needs lots of content ripping at the moment. Obviously I will work on it when more time frees up sooner or later, but all help is appreciated. Here's what can be contributted by simply posting here, or even comitting to the repository. Note that I'll need your google account name for adding project members. You can create a google account with any e-mail you currently have.
What you can contribute:
- Models and textures(models preferrably compatible with 3DS Max 2012)
- Converted models: Processed models with materials ready to be imported into the editor. This includes the .mesh files exported and .dds textures, plus the .material script.
- Templates (.xml): Refer to the technical info later on.
- Ideas & feature suggestions are welcome.
How to contribute?
- Post here.
- Request here to be added to the repository's project members so you can contribute using SVN tools.
- Or just PM me anything.
Tools needed for ripping
Currently SonicGLvl is using Ogre3D engine to provide display previews. Ogre3D provides enough features and a pretty fast performance for the needs of the editor, and there's no plans of changing the engine. Plus, it's cross platform in the event that SonicGLvl goes that path in the future.
- OgreMax Exporter is the plugin I'm currently using to export all models to the .mesh format Ogre uses. Do note that OgreMax supports 3DS Max, Maya, Softimage/XSI, and covers a big array of the versions of them. There's a commercial version, but the non-commercial version works fine for our purposes even with the restrictions. Non-commercial version of the plugin for 3DS Max.
- Darkspines' script with a slight modification to change the naming of the materials created is the one I'm currently using to import game's models. The name modification is because OgreMax exports the materials named as the maps in 3DS Max.
- Any 3D editor that's compatible with the above should work for exporting models into the editor. At the moment you can just use 3DS Max 2012 for free with a student 3 year license.
Screens & Videos
Some simple modifications of levels I made in the past with the editor:
- Add needed features like Undo/Redo.
- Support editting additional vectors from the object with another 3D point in space.
- Support loading level geometry when we got the chance to export it. Editting in blank space ain't fun.
- Add support for editting easily stuff like Lines, spline paths, etc.
Tech Info dump
So for the ones currently researching into the game's objects as well, here's all the info I got so far.
Sonic generations seems to use two different kinds of .ar.00 files for loading an stage, appart from the geometry in the /Packed folder.
- The file with a '#' (e.g. #ghz100.ar.00) is likely to be the "info" file of the level. The file size is small most of the time, and it holds all the data regarding object placement, as well as some physic files. While "Stage.xml" seems to refer to which files are the ones holding level data at the moment, it's safe to assume that all xml files with the prefix setdata_ are object level data. Mostly because "Stage.xml" seems to have a broken format sometimes, so it isn't really reliable.
- The file without the # holds the geometry, textures, and other stuff of the custom objects from the level. You can look into these files if you want to rip any custom models.
- These setdata_ xmls are completely human readable. While they can be editted by hand to add or move any objects you want, it's better to rely on the editor for the task. Mainly because using a 3D preview is way more intuitive.
- All objects of the level will be placed under the <SetObject> node in all these xmls. Each entry added to the file will appear as a whole new object in-game. Do note that most of these objects have a unique ID, set by a <SetObjectID> node inside them. Clashing IDs ingame are not something you'd like to see, so no objects should EVER have the same ID.
- The level files seem to have a special option built into the game to generate copies of itself across different positions. These are called <MultiSetParam> nodes, and each of these hold various <Element> nodes with their own <Position>, <Rotation>, and <Index>. There's also a <Count> node for the total ammount of copies. This <MultiSetParam> makes it easy to generate say, a line of 40 rings in a perfect pattern. While there's other parameters such as <LineBase>, or <Interval>, this only seem to be relevant to whatever editor SonicTeam used to make the game, because they have no relevance whatsoever apparently if modified ingame. What matters is the individual positions and rotations in each <Element> node, and this is handled by the editor already.
- It's considered pretty much globally for ALL objects to have their own <Position> and <Rotation> nodes. Coordinates between the editor and in-game match perfectly. You can consider the X-Z plane as the "floor" plane of the game, while the Y axis represents the Height.
- The nodes inside each object never specify what kind of variable they are. That's where the concept of templates comes in. SonicGLvl HAS to have a way to know what variables an object normally has, and what kind of variable they are.
Templates are simple XML files located in the editor's folder. They are normally built in the following way:
<?xml version="1.0" encoding="utf-8" standalone="no" ?> <MyObject> <MyVariable1>bool:true</MyVariable1> <Position> <x>double</x> <y>double</y> <z>double</z> </Position> <Rotation> <w>double</w> <x>double</x> <y>double</y> <z>double</z> </Rotation> <SetObjectID>integer</SetObjectID> <Mesh>object.mesh</Mesh> </MyObject>
Each node represents the name of the object's attributes. Instead of writing a normal value inside though, you are supposed to write the type of variable it is. The editor currently supports the following:
string: a name
double: decimal number
integer: self-explanatory I guess
bool: boolean value, will write either "true" or "false"
Any value after ':' will be considered the "default" value with which the object is created from the editor's menu. For example, <CastShadow>bool:true</CastShadow> means that true is the default value for that attribute.
Note that it supports attributes inside other nodes, like <Position> and <Rotation>.
Also of notice, <Mesh> isn't an actual attribute, but a reference for the editor to know what model to use in the preview display.
Here's an example for a game ring:
<?xml version="1.0" encoding="utf-8" standalone="no" ?> <Ring> <GroundOffset>integer</GroundOffset> <InitDisp>bool</InitDisp> <IsCastShadow>bool:true</IsCastShadow> <IsLightSpeedDashTarget>bool</IsLightSpeedDashTarget> <IsReset>bool</IsReset> <Position> <x>double</x> <y>double</y> <z>double</z> </Position> <Range>double</Range> <ResetTime>double</ResetTime> <Rotation> <w>double</w> <x>double</x> <y>double</y> <z>double</z> </Rotation> <SetObjectID>integer</SetObjectID> <TreasureSearchHideType>integer</TreasureSearchHideType> <Mesh>ring.mesh</Mesh> </Ring>
- Another option provided is the <AltMesh> reference. Some objects will change depending on the attributes they have, so the best way to represent that inside the editor is just changing the model displayed.
For example, if you would want a red spring to be displayed instead of a yellow one when the power of the spring is above 30.
<AltMesh> <Condition>FirstSpeed >= 30</Condition> <Mesh>spring_classic_r_01.mesh</Mesh> <Mesh>spring_classic_r_02.mesh</Mesh> </AltMesh>
This is purely for the editor's reference, it doesn't change anything in the game.
<Conditions> are single line statements. You can add as many conditions as you want. There's also a custom string value, LevelPrefix to check what level you're currently working on. For example, ghz for Green Hill zone, cpz for Chemical Plant. Same way as the game's files are named.
- Yet another option provided in the case it's needed, <MeshScaleX> (or Y, or Z) will allow you to change the preview model's scale using an attribute of the object(for example, <Width>). It also has a custom multiplier attribute. Here's an example for the object <OnewayFloor>, which depends on <Width>, <Height> and <Depth> to be represented accurately inside the editor.
<MeshScaleX multiplier="2.0">Width</MeshScaleX> <MeshScaleY multiplier="2.0">Depth</MeshScaleY> <MeshScaleZ multiplier="2.0">Height</MeshScaleZ>
- The editor will search for any matching objects with the templates it has, and will write any changes made. It will also add any new objects, as well as erase any deleted ones automatically. It's totally safe and compatible so far to open and save a level and import it into the game directly so far, given that you haven't tampered too much with object's attributes that you don't know about and make the game crash.
- The editor supports reading an XML and dumping all types of detected objects manually, using the default "unknown.mesh" as display model. It's recommended to tweak these files dumped manually.
TL;DR; Editting the levels is way easier than you ever thought.