Call for help: New demo project for ETL (simple editor)

For the next version of ETL, I would like to have a demo project which really shows off what ETL can do and how, and the current demo ripped off of one of the Ogre demos just doesn't quite cut it.
However, I'm quite busy currently, so it would be a great help if someone else could step in here to either fully take it or prepare the foundations for me. I'll add you to the list of developer(s) of ETL so you'll share the fame for the next major release

Here is a feature list I would like to see:

1. Terrain creation: In a dialogue you can choose the vertex and Ogre sizes of the whole terrain and of the patches as well as the initial height value for each vertex and the base splatting texture. If you are really motivated, you could also add support to import a terrain from a pregenerated heightmap (image loading) or even auto-generate a terrain with the help of libnoise or similar.[/*:m]
   
2. Brush selection: Select a brush from a list of available image files and set its size and rotation[/*:m]
   
3. Terrain deformation: Deform the terrain with the currently selected brush. Both directions (up and down) should be supported. A projective decal should show the current editing position.[/*:m]
   
4. Terrain stamping: If motivated, allow a user to create a "stamp" by clicking on a terrain part. The heights of the terrain will now be saved to the brush and can be copied to other regions of the terrain.[/*:m]
   
5. Splatting: Select a texture from a list of available textures, then paint with this one over the terrain. Don't worry, the new high level splatting manager will be very smart and will add or remove textures on the fly implicitly, so no need to preselect the textures for the current terrain, just let the user select any texture known to the editor.
   If motivated, you could add stamping for splatting, too.[/*:m]
   
6. Colour painting: Via an additional dynamic texture let the user give some colour on top of splatting. The user should be able to select an arbitrary RGB colour (via colour sliders or a ColourChoice dialogue or whatever).[/*:m]
   
7. Saving and loading terrain: For each terrain the editor should create a separate directory with a name given by the user. To load, the user can then give the name of that directory (either simply via a textbox or, if you are motivated, via a proper list selection). Saving or loading is pretty much saving or loading all the involved images (heightmap, splatting maps, colour map, lightmap, minimap) as well as a simple config file to store which splatting texture was used on which channel.[/*:m]
   
8. Editor configuration: I would put all of the following stuff in a simple config file which is just read on start, but you could also make some or all of it modifiable while running, it's just more work for the configuration boxes. The editor needs two dedicated resource groups in which it can find a) the brushes and b) the splatting textures. You can even hardcode the resource group names, but they must be populated. A third resource group must be populated with ETL's shader programs and any GUI resources.[/*:m]
   
9. Camera movement: Ideally, but not necessarily, the camera should behave like in RTS games, i. e. a focus follows the terrain, and the camera is attached to the focus in some distance and orientation, both of which can be modified (zooming/rotating the camera view). I already have a CameraControl class from my project which does exactly that, it could be taken and modified to fit the new ETL and the editor environment.[/*:m][/list:u]
   
   If that sounds like much, note that most of the things necessary for the editing will be taken over by ETL. The real work (and the one which I don't have time for) is the foundation: Loading Ogre, loading config, populating resources, reacting to input from OIS, setting up the scene, moving the camera (but as mentioned, I have a class for this you could use as a start), and, most of all, setting up and handling the GUI. The GUI needs to offer ways to save and load, a Brush selector, an Edit mode selector (deform, splat, paint, ...) and a texture selector (for splatting).
   
   Seeing as the GUI will add an additional requirement beyond Ogre (unless you plan on using BetaGUI), I don't particularly care for the GUI choice. Since this is a demonstration project I would prefer CEGUI for the very simple reason that it comes bundled with Ogre' SDK or dependency packages, so it is often already available. But if you can work faster with something else or even wish to make a "proper" editor by embedding Ogre in wxWidgets, fine. It just has to be portable.
   
   Also, since this is a demonstration project, the code needs to be nicely structured and commented in a way that users can quickly find the relevant sections and understand them. So that means no ExampleFramework and separating the ETL parts from the rest as good as possible or adequate.
   
   
   ETL's primary use is to offer editable terrain, which is most likely needed for editors. So actually providing a basic editor is what would really help most users to get into ETL. If you are interested in helping me out here, please let me know, and we can discuss further details Obviously, since ETL is a free library, I can't pay you, and you need to agree to an open source license for the editor code (zlib or GPL would be the most obvious choices). Thanks

I'm certainly interested, but I have a lot of commitments as well. I'm currently working on my SkinSetEditor, and I've got a decent foundation built, except I'm finding that ogre doesn't handle multiple windowed aplications very well:

http://www.ogre3d.org/phpBB2/viewtopic.php?t=39429

I think in the end I'll create a 1x1 dummy window and make sure its hidden beneath my *main form* by sync'ing its position every frame.

Do you have a preference on whether or not multiple windows should be used? I am able to help with either route; multiple windows feel really nice to use, but the downside is that I will have a dummy window floating around, and all windows will show up in the task bar. (for example, with 5 windows and a dummy window, you'll see 6 windows in the task bar). On the other hand, sticking with just 1 render window and having emulated windows would be simple and easy to manage. If I could remove the close button from these windows and prevent them from showing up in the task bar multiple render windows would be a no brainer.

Not exactly sure what you mean with multiple render windows, or rather what you would use them for? Do you mean you'd be able to edit multiple terrains side by side?
Anyway, since this is still supposed to be a demo project, I think everything should be kept as simple as possible to still get a decent app showing ETL's potential. Multiple render windows seem a bit too advanced and distracting for that purpose

Ever make an application using winforms? It's really slick having separate windows on your desktop as part of an app.

I did a little searching and I think I found a few things to try out. 1 Render Window would make things really easy, but if I can get multiple windows working conveniently, its much better. I will look into this more tonight.

Well, just bear in mind that it's not the goal to make a "perfect" editor, but to demonstrate the capabilities of a library in a way that a user can easily understand and follow the source code. To that end I think that sticking with a standard Ogre setup with a single render window is much clearer.

Besides, you still didn't state what you want to do with the additional render windows. Multiple terrain editing, or do you want to divide the GUI components to their own windows (like GIMP etc. do)?

I already have the basic code for setting up ogre and using multiple windows, its very clean and easy to follow, I can send it to you. The only issues I have with multiple window are cosmetic, really.

GIMP or any good modelling tool would be a good example of an application using multiple windows. For example in notepad, when you click "Open..." or "Save As..." it opens up a new window, right?

You're probably thinking its a lot of work to setup, but I already have it all working. I'll PM you and I can send you some files tonight for you to look at. If you really want to limit the application to one render window that is fine to, obviously I have that working also.

Hehe, alright, you do that, although for such a solution I would actually prefer embedding Ogre in a standard GUI toolkit like wxWidgets. That gives a more natural feeling to the dialogues etc..

Anyway, thanks for your interest in helping, much appreciated

I went ahead and emailed you the code and a binary demo. However after trying to get a multiple Render Window solution working, I don't think its worthwhile to go this route. I wasn't able to figure out how to disable the close button from the windows, so I tried creating windows with a border style of "none", and emulating the window using a QuickGUI window. Ayhow I don't want to keep going off topic from the editor topic.. long story short, I'm still willing to help, but I'll be going the single window route.

I am going to be moving to ETL 3 (of course) so I'll be going through doing all this stuff for my editor.

I'll make a stripped down version for the ETL demo.

[edit]
Is there a date you're shooting to have this by CABAL?

... divide the GUI components to their own windows (like GIMP etc. do)?

@Kungfoomasta - Multiple windows are awful in M$. Unless your OS is application scoped rather than window scoped many multiple windows = bad. Even Adobe, a hardcore multiwindow software suite for like... 15 years went over to a 1 window approach as of.. CS3 I think (didn't use CS2 so it might have been in there.)

Basically, unless you're writing for macs or using... oh I'm blanking... the linux desktop system that's not gnome... oi.. don't you hate that when you just can't remember something obvious? I must be getting old.

@kungfoomasta: I received your code, thanks. I have not had the chance to run the demo yet as I'm currently under Linux, but I'll certainly do later. I did glance at the code, and it's quite a lot less messy than I would have imagined - nice work

Still, as you said, I would stick with the single window app. Furthermore, since SongOfTheWeave already has a working terrain editor, it seems to me that a forked stripdown of this would be the easiest/quickest route to take. So I would like to take up that offer.

As for the time table, it's basically unset. I do want to include it in the first release of the library, but I can't possibly say when that'll be, possibly a few weeks still. Nevertheless, providing the infrastructure for the program (setup, GUI) would already help me much, and then we can fill in the blanks when ETL moves forward

I hope it can support GeForce2/4 MX 440 with AGP8X

Those cards don't have shader, therefore they cannot support splatting which would make the editor quite a lot less usable. I'm afraid these cards won't quite make it, sorry.

A year ago I made a scene editor using winforms, mixing native and managed C++. It was a pain to develop, but it was incredibly awesome to use. If you've used Maya, 3DS, or other professional modelling tools you can see how useful detachable, separate windows are.

Since SongOfTheWeave already has a foundation laid out it would be best to go with that. Plus he is using your preferred GUI.

I know i'm late (i couldn't read forum messages for a while), CABAListic if you want I can send you my source code, it has 80% percent of the features you listed before and it is very simple, i did it using MVC pattern and it has a wxFormBuilder project, so it is very easy to extend.

if you want to see it running download ThunderWheels demo 0.3+

luis, thanks for your offer. I looked at your editor, nicely done. I like the selection of brush and texture
Still, given the choice, I would rather avoid pulling in wxWidgets as a dependency on a demo project. That's why I'll stick with SongOfTheWeave's offer. But thanks anyway

you welcome
I dont know SongOfTheWeave's editor but if it uses... ohh i remember, he uses CEGUI, I agree, for a demo I personally would prefer a lib already included in Ogre...

Sorry for the lack of follow up on this, I got busy for a while making sure the rent was paid and various other burdensome necessities. I haven't had a chance to grab the ETL 3 code yet and work it into my project at all.

CABAL - is there anything I can provide you, from my project, that would be the useful to you on a "nowish" timeframe? Er, well, on second though, I'm going to have to look at the ETL 3 stuff before I can say anything intelligent on the subject. heh.

Well, I'll go do that now then. No time like the present.

Well, I'm still a "bit" off from the first public release, so no rush
Anyway, whenever you can prepare the foundations of the editor is fine. I'm mostly interested in the skeleton, i. e. the code which loads the app and the GUI, sets GUI callbacks etc., and "all" that remains would be to insert the actual ETL manipulations.

I'm working on my own project and I'm at the point where I seriously need some map editing tools. I'd love to collaborate with you on the latest editor, adding functionality that will help both of us out. Shoot me an email at samewavelength@hotmail.com if you're interested, and we'll talk.