I pm'ed the creator and this was his response, BrotherBrick. I hope it's helpful.
Hello and thanks for recommending Artifex:), I just had a look [at] what HDF5 is. Seeing it is an open format, you could easily write a converter to extract the heightmap data from it. Artifex Terra's .bin format is pretty simple and straight forward, you can see the code in the loader sources. Its just a sequential Array of floats between 0.0f and 1.0f and the first 2 values representing width and height of the terrain, e.g. 1024,1024, you get the picture. Shouldn't be much effort to do that, couple of hours maybe a day max. Hope that helped.
//Nauk
Edit:
... oh and if you need help with that, drop me a line, I am happy to assist you with it
Last edited by Greendogo on 16 Aug 2012, 23:03, edited 1 time in total.
@Eli2: I think we soon need to start getting the editor development organized more. Here is what I propose:
As soon as you get your filters to a satisfying state, I create a new editor branch from your branch, which will from then on serve as a central integration point for all editor development. You (and everything else) can then create new features branches based on it, be it an experimental branch or something that can go straight into to its parent branch.
Also, I think we should start to integrate the editor development into the regular development process. That means that we have editor development issues on the roadmap and from some point on (maybe in 2-3 releases) offer packages for the editor alongside the normally OpenMW packages.
@Eli2: Hey, what's the status on the prototype? I saw a lot of cleanup comments lately. Do you think your branch is ready to mint the new editor branch from it?
It seems, the more i code the less i am sure about that ...
I am not sure anymore if using the QAbstractItemModel is the right way for editing the Data. On the other hand it seems to be the standard way of doing things in Qt.
Also there is still a lot of strange code around (e.g. esmdatamodel.cpp).
My motivation is getting lower anyways, so maybe more experienced people can jump in and help me out.
If you want to make an editor branch, i have no objections.
It seems you also have pieces of an undo implementation mixed into your branch now. I disabled it for now. But we should in general try to have separate feature branches for these kind of things.
Also, I am getting some error messages when running the editor:
Invalid tagName "Name"
Object::connect: No such slot QTableView::resizecolumnsToContents()
Object::connect: (receiver name: 'tableView')
Okay. All bugs gone. I have two more comments for now:
1. Just an idea, but can we have the number of records in the ID List in the title of the ID list? Like: "ID List (27 items)".
2. The name handling in the filters don't work out so well. Currently you are naming individual parts of a filter. I don't see where that actually would be useful. The idea behind named filters was that you can have multiple filters (some pre-defined, some user-defined), that you can easily select by choosing the filters name.
Zini wrote:
The name handling in the filters don't work out so well. Currently you are naming individual parts of a filter. I don't see where that actually would be useful. The idea behind named filters was that you can have multiple filters (some pre-defined, some user-defined), that you can easily select by choosing the filters name.
What do you think has to be changed to improve usability ?
Well, how else to handle multiple persistent filters? You can't expect a user to manually rebuild a filter every single time he needs one. These things need to be readily available to quickly choose from. The only way I can think of to handle this requirement is to give the filter a name.
