[SOLVED] Terrain - Multi tile world editing.

[Guest shane.ploenges]

Hi, i am looking for some suggestions and ideas as to what the best way to approach a problem with multi terrain tiles might be.

 

We use very large multi tiled worlds, consisting of many many seperate terrain tiles. We need to be able to edit these tiles across edges where they join as if they were one tile (otherwise the edges of the tiles will no longer meet up.

 

We plan this to suppot height brushes, detail masks, normal maps - in fact everything that single terrain tiles have in regards to editing capability.

 

If unigine were to tackle such a problem, how would you go about doing this? and do we have the same access in to the terrain system without source code to try and implement something like this?

 

Does anyone else in the community have any ideas about how to tackle this, it certainly does not seem like it will be an easy, and even perhaps an impossible problem to solve with the current system.

 

thanks in advance

[Guest shane.ploenges]

With 19 views and zero responses, i am asuming no one has attempted something like this, and that it is going to be extremely hard to implement :D

[ulf.schroeter]

Shane, key problem of your approach from my point of view is usage of multi-tile ObjectTerrain instances: I would expect all kinds of nasty render problems like cracks between instances. Maybe most of the time it might work quite well, but at the most inappropriate moment (e.g. customer Präsentation :-) it will break...simply because it's not designed for your usage pattern.

 

Best way would be to motivate Unigine for implementation of a  truely unlimited terrain streaming solution including appropriate editing support. Trying this on your own sounds like a challenging endeavour to me....especially without source code access

[Guest shane.ploenges]

Thanks for the response Ulf.. nevertheless, this is exactly what we will need to do given our simulator requirements and our tight schedule. I do not think Unigine will implement this any time soon, so we need to just bite the bullet and attempt to develop our own method.

 

We are already using a multi tiled world approach, and yes it is not working too well for us performance wise, although cracks in tiles has not been an issue yet.

 

We are thinking of having a detection method in the brush itself to find which tile you are on and switch tiles accordingly - this may or may not be practical, and will certainly have performance implications in the brush. but it will be the first thing we test i think, unless we think of a better solution.

 

I was hoping someone technical from unigine might give us some ideas as to the best way to proceed so we do not waste too much time, but i think maybe this is something they have not ever planned for of thought of doing themselves either.

[unclebob]

Hi Shane,

 

There are al least two ways, for both you'll need to write/modify source code in UnigineScript.:

 

1. Modify terrain tools in our editor. By doing this you'll need to have core.ung source code.

2. Write your own terrain editing tool in editor script and use it in editor. Most of project specific tools for Oil Rush were written by using this approach.

 

So, basic idea remains as you write above: find brush-terrain intersection, detect all terrain objects around and apply brush to all of them.

 

You can get performance drawbacks on terrain object searching and brush applying. Most of that drawbacks will be spent on brush coordinate correction between different terrain objects, I think.

[Guest shane.ploenges]

Thanks for the reply, this is as i suspected. We think we have another alternative to try also, which is less powerfull, but easier to implement. basically we are going to stick to single tile editing, however adding a terrain tile edge height detction, averaging and stitching tool so that tile can be edited seperately then stitched together afterwards. We would also try to avoid editing across seams as much as possible.