Sonic and Sega Retro Message Board: SonicGLvl v0.9 - Now on GitHub - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

SonicGLvl v0.9 - Now on GitHub NOT FOR REGULAR USE - EXPERIMENTAL BRANCH

#1 User is offline Dario FF 

Posted 13 December 2011 - 10:17 PM

  • Tech Support Hotline
  • Posts: 956
  • Joined: 03-April 10
  • Gender:Male
  • Location:Mar Del Plata
  • Project:SonicGLvl
SonicGLvl 0.9 - Now on GitHub Posted Image

This version is not meant for public use and is merely uploaded as the work that I've done so far. It's very much in need of work to be considered a stable release.

GitHub repository licensed under GPLv3
Building on Windows

Development Roadmap

SonicGLvl Wiki

Builds:
Stable: None yet.
The bin folder in the repository at the moment has the last compiled version of the code, but ideally no binaries should be hosted there.

Code Status:
  • In need of some cleaner refactoring, especially how file opening is handled at the moment. Loading the files should be an external method that returns a value, not a constructor per type of object.
  • Almost all of the ugly WinAPI code can and should be ignored since a port to Qt5 is inevitable.
  • Switch all headers to #pragma once and try to forward declare mostly everything.
  • Needs to be documented a lot more, although the names are pretty obvious as to what the methods do most of the time.


Last Preview Video:
https://www.youtube....h?v=2fAkw7kcQPw

FAQ

Q: Can I use this over the original SonicGLvl?
A: No, and you shouldn't. The current new branch does not have feature parity with the original SonicGLvl yet. At most it's fairly usable for some simple object layout editing.

Q: Can I use the database/models from the original SonicGLvl?
A: No, the databases are no longer compatible for the purpose of extending the functionality a lot more. However, on the plus side, dumping and detecting new object templates is pretty much unnecessary unless you want bigger control over how the objects are displayed. The new branch of SonicGLvl no longer relies on having objects on the database to be able to load/display them at all.

Q: How similar is it to use this branch of SonicGLvl compared to the original one?
A: For the purposes of optimizing the work pipeline and making it easier to understand, a lot of old tutorials will be pretty much useless, so a new knowledge database will need to be built on the wiki.

Q: Summary of new features planned/implemented compared to original SonicGLvl?

  • Smoother and much easier to use Viewport Controls.
  • Undo/Redo.
  • Smarter Object Database with extended previewing features.
  • Smarter Stage/Terrain cache, verifies hashes and cleans up automatically.
  • Game shader support, able to preview materials in the editor very similarly to the game.
  • FBX Importing/Exporting instead of using Ogre formats, which gives us plenty of possibilities for a smoother pipeline between 3DSMax and SonicGLvl.
  • Generalized Formats Library: You can do other applications that use LibGens for reading files from the game without having to integrate them into SonicGLvl. Also allows the possibility to do batching command-line tools.
  • Terrain Lightfield Generation: Generate a lighting map based on rendered maps of the stage so objects and the player are affected by them.
  • Better Terrain Group/GI generation workflow. More details on this can be seen on the roadmap.
  • Ghost Playback/Camera Previewing for easier iteration on editing cameras.
  • New material editor with real-time previewing, using the real game shaders, simplifying the iteration on polishing graphics a lot.


Original thread:
Spoiler

This post has been edited by Dario FF: 09 May 2015 - 02:37 PM

#2 User is offline Dario FF 

Posted 17 December 2011 - 09:07 PM

  • Tech Support Hotline
  • Posts: 956
  • Joined: 03-April 10
  • Gender:Male
  • Location:Mar Del Plata
  • Project:SonicGLvl
Update
+ Fixed the XML dumper for reading as much attributes as possible from the XML with objects of the same type.
+ Nearly 30+ objects added from Act 2 Common like springs, dash/rainbow rings, jump/trick boards, etc. and some common elements from GHZ.
+ Added some more models for stuff like sounds, collisions, etc.

You can get the latest snapshot from the Downloads page, or use SVN update.

My intention right now is to get GHZ Act 2 with a pretty accurate visual representation of some objects at least.
Posted Image

Also, Falk reminded me of those Unleashed DLC Hard acts on the other thread, so for kicks, I did a lame and short edit of the first section of GHZ Act 2 to make it harder to speedrun through.


I like my troll dash rings after the spike mini-tunnel. :eng101: This helped me find a nasty bug in a template though, which I fixed.

I can't wait til Stage geometry rips are released. I'll be so happy to do edits later with that instead of a grey background.

#3 User is offline Chimera 

Posted 18 December 2011 - 01:15 AM

  • I'm not a furry.
  • Posts: 951
  • Joined: 04-October 10
  • Gender:Male
  • Project:TOO MANY. BUT ONE LESS.
  • Wiki edits:5
I think your dash pannel's rotation settings are a bit off :V

Other than that, pretty awesome. My only complaint is that, since we have no actual geometry to look at, and some of the objects aren't even relevant to gameplay mechanics (such as, particle effects everywhere and etc), it can be a little visually jarring.

Here's a suggestion! If you can manage to do this, maybe draw a spline curve for Super Sonic's path to give a general sense of direction through the stage? That is, until the level exporter gets released of course.

Another thing: maybe a filter setting. You know, so you can filter out cameras and/or physics-effecting objects so you can see JUST the standard intractable objects, such as enemies and platforms. That'd be neat :V

EDIT: Also for the wooden bridge (even though I doubt anyone would make one anyway), why not for "numwood" your editor draws out wood pieces?

EDIT 2: Another thing... Some things like ChangeVolumeCamera and other things that have a collision "bubble" (or rather, box) could use a see-through mesh for added accuracy. For instance, like how you did the one way floor's width affecting its scale, it'd be cool for a transparent box to have its length, width, and height, modified to match up with the boundaries of the object's set collision.

Also, for camera objects specifically, if you can pull this off, it would be badass: why not try making a "preview" button for cameras? As in, your view will shift to the view of the in-game camera once Sonic passes through the camera modification object. Like my previous suggestion, it would really cut down guess and check, as well as, when the level exporter gets released, make much higher levels of accuracy possible!
This post has been edited by Chimera: 18 December 2011 - 02:02 AM

#4 User is offline Dario FF 

Posted 18 December 2011 - 07:18 AM

  • Tech Support Hotline
  • Posts: 956
  • Joined: 03-April 10
  • Gender:Male
  • Location:Mar Del Plata
  • Project:SonicGLvl

View PostChimera, on 18 December 2011 - 01:15 AM, said:

I think your dash pannel's rotation settings are a bit off :V

Yeah, I'm not really sure what's the deal with that. Maybe I'm not passing yet EXACTLY the rotations, but I thought they were fine. Or maybe it's just that the model exporter has some problems? I will have to look into it.

Quote

Here's a suggestion! If you can manage to do this, maybe draw a spline curve for Super Sonic's path to give a general sense of direction through the stage? That is, until the level exporter gets released of course.

Could be added I guess.

Quote

Another thing: maybe a filter setting. You know, so you can filter out cameras and/or physics-effecting objects so you can see JUST the standard intractable objects, such as enemies and platforms. That'd be neat :V

Yeah I considered that. That should be separate files for the types of filters though. It would also help sort the main object menu. Adding something like "Category:Camera" to templatelist.txt should do the trick.

Quote

EDIT: Also for the wooden bridge (even though I doubt anyone would make one anyway), why not for "numwood" your editor draws out wood pieces?

I didn't add that because there was no template option for it yet. I will add it though, something like
<CopyScaleX>
  <Count>NumWood</Count>
  <Interval>2</Interval>
</CopyScaleX>

The X axis would be local and relative to the rotation.

Quote

EDIT 2: Another thing... Some things like ChangeVolumeCamera and other things that have a collision "bubble" (or rather, box) could use a see-through mesh for added accuracy. For instance, like how you did the one way floor's width affecting its scale, it'd be cool for a transparent box to have its length, width, and height, modified to match up with the boundaries of the object's set collision.

That can be achieved already on the templates. Just gotta add:
    <MeshScaleX multiplier="2.0">Width</MeshScaleX>
    <MeshScaleY multiplier="2.0">Depth</MeshScaleY>
    <MeshScaleZ multiplier="2.0">Height</MeshScaleZ>


Quote

Also, for camera objects specifically, if you can pull this off, it would be badass: why not try making a "preview" button for cameras? As in, your view will shift to the view of the in-game camera once Sonic passes through the camera modification object. Like my previous suggestion, it would really cut down guess and check, as well as, when the level exporter gets released, make much higher levels of accuracy possible!

I would love that idea, but I just have no idea what the camera attributes do yet. If someone could play around with them and document them, it'd be easier. Right now I'm quite busy, but I'm already adding all of these into the TODO list since they shouldn't be hard to pull off.

Thanks for the feedback. :)

Also, it seems I need to add support for another kind of attribute. Objects like <EventCollision> have attribute lists like these:
    <TargetList0>
        <SetObjectID>23435</SetObjectID>
        <SetObjectID>23356</SetObjectID>
    </TargetList0>

My templates don't support lists with attributes of the same name yet, so some stuff might be broken when saving. I noticed bugs in the swing at GHZ Act 1, which is managed by an event that calls two of these. Support for lists shouldn't be hard to add anyway, just thought I should point out that don't panic if some stuff in the levels seem broken yet.

#5 User is offline Dario FF 

Posted 25 December 2011 - 05:08 PM

  • Tech Support Hotline
  • Posts: 956
  • Joined: 03-April 10
  • Gender:Male
  • Location:Mar Del Plata
  • Project:SonicGLvl
Update
+ List support for templates. This adds support and will fix A LOT of glitches that might occurr on levels, such as non-moving swings, or any other stuff. Lists are mostly used by objects such as <EventCollision>, and they normally have 2 or more object IDs to call for triggers. For example:
<TargetList0>list:SetObjectID</TargetList0>


will produce in the object
<TargetList0>
<SetObjectID>3213213</SetObjectID>
<SetObjectID>4326213</SetObjectID>
<SetObjectID>543543</SetObjectID>
...
</TargetList0>


As many that you want. These lists are string values by default. I think that pretty much closes adding more parameters for templates, but we'll see what happens when editting other stages.

Inside the editor GUI, adding or deleting to a list is a single string, where each ';' symbol will indicate a new element for the list. So for example, for <EffectNameList>:
Editor: particle1;lightparticle;darkparticle;

Outputs to the XML:
<EffectNameList>
   <Name>particle1</Name>
   <Name>lightparticle</Name>
   <Name>darkparticle</Name>
</EffectNameList>



* Scaled the axis node 3 times as bigger. A proper solution for that is under research. :v:

GUI improvements are planned next for anyone who cares. Although nothing really serious can be done until we got a way to import the level geometry yet.

A new snapshot of this version is available at the Downloads page as always. Happy editting! :)



Also, as a bonus, here's my experimentation with DustArma's idea, AND me adding the CTE trick boards to spice things up in the first part of GHZ act 2.

Link

I had to add the CTE trick board resources to the ghz_cmn file for this to work. And also the custom entry to StageObject.xml in ghz200.ar.00. Other relevant modifications have been stated on the Resource thread already.
This post has been edited by Dario FF: 25 December 2011 - 05:09 PM

#6 User is offline Dario FF 

Posted 05 January 2012 - 03:14 PM

  • Tech Support Hotline
  • Posts: 956
  • Joined: 03-April 10
  • Gender:Male
  • Location:Mar Del Plata
  • Project:SonicGLvl
Update v0.4

+ Dumped QuickGUI, using native GUI now. There's still some issues with window focus, but it's still far, far better than my older implementation of QuickGUI.

Posted Image

+ MultiSetParam now supports using a vector as base for its array copy instead of the world 3 axes. There's still buttons for setting the 6 presets though, as well as using an angle with a degree across the XZ plane(floor).

+ Categories of objects are now available, allowing the user to find much easier the object he's looking for, as well as applying viewing filters to the current categories. This allows for hiding stuff like cameras, particles, so the main view doesn't get cluttered with stuff you don't care about. Categories aren't hardcoded, and they can be added from templatelist.txt.

Posted Image

+ The moving and rotation axis will now scale according to the distance to the camera. This will make the axis' size stay constant on the screen regardless of how far or how close the object is.

+ Templates have a new feature implemented, and it's called <CopyScaleX>(or Y, or Z), which has the following format:

    <CopyScaleX multiplier="value">Attribute's Name to use</CopyScaleX>


This feature allows the editor to generate a number of copies of an object along its local X, Y, or Z axis. The purpose of this feature is for objects like the Green Hill Wood bridge, which depending on <NumWood>, is the relative ammount of wood logs created.

For example, for GhWoodBridge.xml:
    <CopyScaleX multiplier="0.6">NumWood</CopyScaleX>


It will copy itself every 0.6 points for each value of NumWood. NumWood should be an integer of course. For example:

Posted Image

+ Added lots of resources and templates from Chemical Plant Zone and its missions. Also some new common objects. Special thanks to lagstarr for contributing all these models to the repository, and more are about to follow soon as soon as I implement them!(City Escape, Speed Highway, etc.)

Here's a screenshot of Chemical Plant Zone Tails Mission. You can see the custom mission objects here. :)

Posted Image

* Resizing the editor's window will no longer fuck everything up. The toolbox windows will also be moved to the appropiate spot when resizing.


As always, you can get the latest snapshot from the Downloads page, or do an SVN checkout. Happy editting!

P.S: Any old custom templates you created are backwards compatible.
This post has been edited by Dario FF: 05 January 2012 - 03:17 PM

#7 User is offline Felik 

Posted 06 January 2012 - 02:13 AM

  • Posts: 788
  • Joined: 11-April 10
  • Gender:Male
  • Wiki edits:1
Wow it looks like an amazing program with great potential!
Why does it get so little attention?

#8 User is offline Dario FF 

Posted 06 January 2012 - 07:05 AM

  • Tech Support Hotline
  • Posts: 956
  • Joined: 03-April 10
  • Gender:Male
  • Location:Mar Del Plata
  • Project:SonicGLvl

View PostFelik, on 06 January 2012 - 02:13 AM, said:

Wow it looks like an amazing program with great potential!
Why does it get so little attention?


I'd rather not at its current state. It's usable, but it's missing crucial stuff like having SOME way to see the level geometry/collision(which is being researched by 2 other people ATM). I'll work on researching the path format now.

Also, we're barely 2 months from the game's first release. :v:

#9 User is offline Chimera 

Posted 06 January 2012 - 08:41 AM

  • I'm not a furry.
  • Posts: 951
  • Joined: 04-October 10
  • Gender:Male
  • Project:TOO MANY. BUT ONE LESS.
  • Wiki edits:5

View PostDario FF, on 06 January 2012 - 07:05 AM, said:

View PostFelik, on 06 January 2012 - 02:13 AM, said:

Wow it looks like an amazing program with great potential!
Why does it get so little attention?


I'd rather not at its current state. It's usable, but it's missing crucial stuff like having SOME way to see the level geometry/collision(which is being researched by 2 other people ATM). I'll work on researching the path format now.

Also, we're barely 2 months from the game's first release. :v:


when talking to TwilightZoney, he said he didn't see a reason to release the level geometry as of yet, though I forgot to mention this tool in the conversation :v:

And the fact the hacking of this game is so early and is advancing so rapidly amazes me. Sonic's fans sure ARE as fast as him! :specialed:

Anyway, everything looks and sounds badass; will try this out when I get home. Good work as always, Dario. Also FILTERS :specialed::SPECIALED::specialed:

#10 User is online Twilightzoney 

Posted 06 January 2012 - 09:08 AM

  • Posts: 264
  • Joined: 19-February 10
  • Gender:Male
  • Location:Elgin, IL And Hampshire
  • Project:Unleashed and Generations Stuff and Custom Works
Only problem I see with put in level geometry in, is it might not take a solid huge import into your thing if its a single object since most importers have a limit, besides the fact it will lag out. But if we go the collision meshes to load and be exported that be a different story.

#11 User is offline Dario FF 

Posted 06 January 2012 - 09:29 AM

  • Tech Support Hotline
  • Posts: 956
  • Joined: 03-April 10
  • Gender:Male
  • Location:Mar Del Plata
  • Project:SonicGLvl

View PostTwilightzoney, on 06 January 2012 - 09:08 AM, said:

Only problem I see with put in level geometry in, is it might not take a solid huge import into your thing if its a single object since most importers have a limit, besides the fact it will lag out. But if we go the collision meshes to load and be exported that be a different story.


Aren't the levels just a bunch of instanced geometry across different positions of the level? Ogre has support for world geometry if needed, as well as the SceneManager supporting scenes like it. I wouldn't doubt the power of the engine before we even try. ;) It would be quite useless to have that much geometry inside the editor, but I think it'd be interesting to try.

Damizean is working on the collisions meshes though. Hopefully he'll be lucky, since Havok tools are open on PC and there's plugins for Max.
This post has been edited by Dario FF: 06 January 2012 - 09:30 AM

#12 User is online Twilightzoney 

Posted 06 January 2012 - 10:02 AM

  • Posts: 264
  • Joined: 19-February 10
  • Gender:Male
  • Location:Elgin, IL And Hampshire
  • Project:Unleashed and Generations Stuff and Custom Works
Well it uses that but you'd have to make a importer yourself then since it doesn't work that way. Since we are importing the meshes as a single object since it doesn't kill max when loading it up.

So yeah you'd have to make your own importer to do that. Since it doesn't work the same. With how things exporter/import into max for this script.

Anyways I'd just wait for Damizean if he continues to work with it.
This post has been edited by Twilightzoney: 06 January 2012 - 10:04 AM

#13 User is offline Chimera 

Posted 06 January 2012 - 10:37 AM

  • I'm not a furry.
  • Posts: 951
  • Joined: 04-October 10
  • Gender:Male
  • Project:TOO MANY. BUT ONE LESS.
  • Wiki edits:5
How about just import the stage into Max and seperate all the seperate elements into different meshes, then save them as seperate objects and import them into the editor? :v:

We'd probably only need world geometry for areas like that one mission in Crisis City where areas that are normally inaccessable suddenly have collision, which would make for more diversity indeed.

#14 User is offline lagstarr 

Posted 06 January 2012 - 04:40 PM

  • Posts: 4
  • Joined: 24-December 11
  • Gender:Male
  • Location:Canada
  • Project:Sonic Generations Multi-format RIPS, "Project Sandbox" Unity 3D

Quote

Only problem I see with put in level geometry in, is it might not take a solid huge import into your thing if its a single object since most importers have a limit, besides the fact it will lag out. But if we go the collision meshes to load and be exported that be a different story.


An Idea to help with the problem about large amounts of memory being used by the editor if some sort of "occlusion culling" was used this way only what is in perspective view is loaded rather than the whole level being loaded into memory. this method is used quite well in the fallout 3 & NV G.E.C.K. editor & Unity 3D

Quote

Aren't the levels just a bunch of instanced geometry across different positions of the level? Ogre has support for world geometry if needed, as well as the SceneManager supporting scenes like it. I wouldn't doubt the power of the engine before we even try. ;) It would be quite useless to have that much geometry inside the editor, but I think it'd be interesting to try.


I think it would be amazing you could extend levels or create new paths and areas but the problem is going to be converting everything and figuring out what piece is what then relabel everything, then sorting and adding to the editor but until there is a way to simply convert the geometry like converting the .model files in 3DS Max or whatever program is needed, I cannot do any mass converts until then

#15 User is offline Dario FF 

Posted 09 May 2015 - 09:43 AM

  • Tech Support Hotline
  • Posts: 956
  • Joined: 03-April 10
  • Gender:Male
  • Location:Mar Del Plata
  • Project:SonicGLvl

View PostDario FF, on 03 May 2015 - 02:28 PM, said:

I'm finding myself in a situation due to my new job that I'm trying to stay away a bit from programming on my free time considering it's also what I'm currently studying as my career at the moment. I think it's time I just open source what's there. It's not depression (on the contrary since I've wanted to be able to do this for a living for years now), but it's just not a very healthy routine. :v:

What is already there is actually usable to a certain degree though, but I think an important improvement to do first would be to re-do the UI with something better like Qt instead of WinAPI.

If you think finally open-sourcing it will let you progress further let me know and I'll do the work it needs to be put in a repository.

SonicGLvl is now open source under the terms of the GPLv3. I did an extensive verification of the code base that all external code has its proper licenses/copyright notices marked as such, but I might've missed something. If that's the case please let me know. Only all original code written for the project is subject under the license.

The code design has changed a lot since I've also learned more about application design over the 2-3 years since I started with this, so I'm sorry for any weird inconsistencies. There's no restrictions to how much we should modify it if it helps in the long run.

You can check the first post for more details and the current development Roadmap.
This post has been edited by Dario FF: 09 May 2015 - 09:46 AM

  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users