Just an idea I had while brainstorming on a future project.
Please excuse the sales pitch, but I want to explain the reasoning...


In the BEGINNING... we were given ent_create, and we felt it good.
Later ... came ent_morph, and memory became more managable and flexible.

NOW ... we have ben granted ent_createTERRAIN, and our world is more managable.
So now... I feel ... we need ... we want ... I want ... ent_morphterrain!

The ability to take an existing terrain entity and change its size.
That is either its cell 'size', or its overall width or length(in cells).
Much like the "Change Terrain Vertices" funcion in MED, except in-game...

[EDIT]Another bonus would be if it could allow you to re-locate an existing
terrain to a new XYZ co-ordinate, without needing to remove and re-create...

An engine function for changing the number of terrain vertices had no advantage over recreating the terrain in lite-C. It would be pretty much the same code.

How about the fact that re-creating a terrain consumes memory?

And if done repetitively you can comsume all available memory...

If my understanding is wrong in this case, can you please contribute
to THIS THREAD...
Just to point out where I/we are going wrong and perhaps pointing us
in the correct direction.
The latter stages of that thread are more to the point, but it's
probably worth your time to read from the start, so you can see the
'thought proccesses' that led us to those later points...

Thanks dude.

Yes, it consumes memory. But this is due to the level cache and would be no different with an engine based function.

You can use ent_purge to clear removed terrain from the video memory, and level_free to clear it from the level cache.

And thats why Im after the ent_morphterrain function!

Because ent_purge only clears the video memory, and
clearing the level-cache removes EVERYTHING.

The reason I ask is because I want to be able to MORPH terrains so
I can build a supra-large terrain out of a 'swarm' of smaller, mobile terrains.
Im currently developing this using terrain-like entities, but true terrains
are far less cpu-hungry.

(have a quick LOOK at the other thread I linked earlier, it explains in more detail)


Oh... And thanks for listening dude.


{EDIT] Hell, I would be happy with just the ability to MOVE a terrain,
and adjust the size of its cells, and re-center its origin with this function,
even if I cant have the ability to change the number of cells..

Moving and scaling should be possible by just changing the terrain vertex positions with ent_getvertex/setvertex. The examples only show how to change the height, but it should also work for x and y. I haven't tried it yet however. Post here if you get problems and I'll look into it. Be careful not to distort the terrain - every cell must stay rectangular, otherwise chunking and collision detection won't work anymore.

I am already aware you can adjust the X and Y, but Im not going to go there.

Because with the needs I have, these vertices may be getting moved by
500,000 quants or more from their origin, and I think thats getting pretty ugly.
And then there is the huge numbers involved in the mathematics, then we are just
asking for trouble in trying to keep the vertices aligned along the edges of
of neighbouring terrains...

Just too many things to go wrong doing it that way...

[EDIT] BTW, Im not using any chunking or LOD...