Canali:
No, I didn't. There has never been enough interest in the system to justify making major changes. I sell only one shareware license every two months. Even if improving it doubled interest, that would still only be one sale per month. Just not anywhere near enough to justify the massive amount of time and effort, given almost nobody is willing to pay more than $20 for my systems. :-)
Also, removing seams would be difficult, add a lot of complexity to the system, and change the way the system works drastically enough that certain people might find the way they want to use the terrain system no longer works.
My original plan was to adjust the vertices at the seams in realtime, but that turned out to be much too slow. The only other possible way to fix them, would be to maybe make X copies of each tile, to handle each case of resolution difference in adjoining tiles.
In other words, one mesh for if the tile to the north is lower in resolution, one mesh for if it is higher in resolution, one mesh for equal in resolution. Going all the way around the four sides, we find we need 16 different combinations, times 3... 48 different tiles, just to get rid of one set of seams around one tile!
So that method is unworkable. There's already the apparent problem of too many meshes in video ram to contend with, so we don't want to compound that.
No, I didn't. There has never been enough interest in the system to justify making major changes. I sell only one shareware license every two months. Even if improving it doubled interest, that would still only be one sale per month. Just not anywhere near enough to justify the massive amount of time and effort, given almost nobody is willing to pay more than $20 for my systems. :-)
Also, removing seams would be difficult, add a lot of complexity to the system, and change the way the system works drastically enough that certain people might find the way they want to use the terrain system no longer works.
My original plan was to adjust the vertices at the seams in realtime, but that turned out to be much too slow. The only other possible way to fix them, would be to maybe make X copies of each tile, to handle each case of resolution difference in adjoining tiles.
In other words, one mesh for if the tile to the north is lower in resolution, one mesh for if it is higher in resolution, one mesh for equal in resolution. Going all the way around the four sides, we find we need 16 different combinations, times 3... 48 different tiles, just to get rid of one set of seams around one tile!
So that method is unworkable. There's already the apparent problem of too many meshes in video ram to contend with, so we don't want to compound that.