ETL future?

Ok, let's be honest here. ETL development has been dragging on for a while now, and even though most of the features I want to provide are available, there is still some work to do before I'd feel comfortable with a beta release. And I'm not sure I can improve my development speed in the near future since actually I really want to concentrate on other projects right now. In addition, sinbad has committed the first files for the new upcoming Ogre terrain component, and I have to say it feels redundant to maintain my own terrain renderer when in fact Ogre is going to have an editable one, soon.

So, what I would like to propose to you is a change of scope for ETL. Instead of being a full-featured terrain library, I would like to turn it into a utility/support library for the new Ogre terrain component. I will contribute parts of ETL to Ogre if they fit the scope, but anything that is out of scope for Ogre's terrain component itself would remain in the utility library which would be specifically targeted to terrain editors.
Getting rid of the terrain renderer component would make the library much more lightweight and thus more maintainable for me. Besides, the remaining features I need for my own project, so I have an immediate interest in making them work.

Does this sound reasonable and acceptable to you? I know the new terrain component is Cthugha only and may not be production-ready for some time - but let's face it, neither is ETL. Some of you have already begun using ETL, stealth in particular. Do you think you could cope with this change and eventually switch to the new Ogre terrain component?

CABAListic, thanks for your update. Although I hadn't actually gotten to the point of using the ETL, I was planning on using it in the near future. Since I'm not heavily dependent on the Terrain, switching should be relatively painless for me. I only hope that Sinbad's version has the same or more functional features ETM/ETL has. Sinbad has excellent reference material to write the terrain component, I hope it develops soon.

And you should focus on your own projects more! Thats something I need to do as well, although you're in a better position, since there are/will be good alternatives. Working on the same thing for long periods of time is not very exciting. Show us a few screenshots of your project(s)!

I've been using ETL quite extensively for the past few months and I guess I'm disappointed to think that all the work I've put into getting everything to play nicely may become obsolete soon, but excited that Ogre will feature an integrated editable terrain system. I had no idea Ogre even had this in the pipeline.

For my current project, I've come to rely quite heavily on ETL (modifying it as required). I can always continue to work with it - as is - since it is serving my needs just fine for now. Especially since I've added missing functionality as needed. In saying that however, I'm interested to know if the new Ogre terrain component will be as good as (or better) than ETL. If that is the case, then I agree with you CABAListic.

The only thing that really concerns me now is how difficult it will be to convert from ETL to the new Ogre terrain component when the time comes.

The new terrain component for Ogre will definitely have all the basic functionality you need to have editable terrain. The heightmap data is exposed and can be modified. Whether the component will feature all the fancy editing stuff ETL currently does (i. e. scalable, rotatable interpolating brushes, editable textures, splatting manager etc.) remains to be seen. I have contacted sinbad, and some parts might go in, others will not. I have created ETL specifically with editors in mind, but editor-specific stuff is not necessarily in the scope of a general Ogre component. But this is really no problem; as I said, I would continue ETL as a utility library for this new component, so anything the component does not provide, ETL will. Interfaces will change, of course.

Now, one thing I'm not sure about is whether the new terrain component can be placed and rotated as freely as ETL can. From sinbad's early commits it appears that you can definitely align the terrain along different axes and probably move it along the chosen plane, but it might not be possible to orient it freely in the 3D space. Given how much pain it was for me to get that right and how little use there is for that in real-world applications, imho, that would not be much of a loss. On the plus side the terrain component can be integrated with the new paging system out of the box, and sinbad's planning some interesting hierarchical batching for terrain tiles which should give a nice performance boost for larger terrains

@rubasurex: As for migrating your project, I guess it depends how well you have isolated the terrain editing. Ideally they should be managed by an appropriate manager class so that the necessary changes would be very local. You will have to expect that all the interfaces change, but no functionality will be lost.

@CABAListic: I plan on using ETL until the Ogre terrain component is ready to migrate to. However in the mean time, one thing that is really paining me is how long ETL takes to create/load a terrain. It takes at least twice as long as ETM. I remember you mentioned that you were pretty sure you knew what was causing the slow down. If you're not planning on developing ETL any further, can you please shed some light on this as I would love to go into ETL and tinker with it to try and improve the speed.

I suspect the way the update works. In ETM I used a simple dirty rect to mark terrain vertices which need updating, whereas in ETL I stored single vertices in a set. But this is overkill and more specifically for a full terrain update (which is necessary at creation) it takes time to fill and process the list. Switching back to a dirty rect should solve that. In fact, I *think* I even did that in one of my recent commits. Perhaps you can backport it to the working revision.

CABAListic:

As an extensive ETL user, i have no problem with your mentioned changes, i am not updating ETL since revision 50 or something and that revision is already in Ogitor repository, so no problem for me.

Ans you are right about the future expectations, Sinbad's Paging System (not only the terrain, the whole thing) will completely change the way both terrain and scene composition in the future applications that will support it and actually I will create a stable branch of Ogitor at v0.2.5b and after that branch trunk will be modified to work with latest OGRE trunk + will start implementing the paging system in Ogitor (as a consequence i will drop PLSM support in future Ogitor and terrain editing will be suspended till new terrain renderer is out). I already contacted Sinbad about it and hopefully Ogitor will be one of the fist applications implementing new system (probably will be the most broad range stress test application for it ).

Having ETL's editing functionalities as a new system compatible library would be really great especially for editor developers like me

ismail,