Tackling the tge terrain

#41 A few terrain improvements that I'll probably never see happen, but I might attempt if I had a lot more time on my hands:

1) I personally like the idea of adapting tge to handle multiple terrain blocks and progressive terrain loading. That would end any complaints about whether there was enough detail in a 256 x 256 terrain block because you could load as many as you need at any time. I got this to work in no time with terrain matrices in darkbasic, but all of the optimizations tied into the legacy terrain will probably make this a nightmare.

2) An option for real-time terrain lighting that would actually yield feasible performance. Stencil shadows look more realistic to me anyways.

3) If the two above points can be accomplished there will be an added benefit. Real-time terrain deformation would become incredibly easy. Its already done in the legacy terrain editor and could be adapted to gameplay with very little effort. Currently the only limitations are the fact that the lighting would need an update, and the deformation would be tiled along with the terrain, both of which would be fixed by the ideas I've previously mentioned

4) Modifications to the terrain blender to allow terrain with higher resolution textures than 256x256 textures. Ideally sharp enough textures that any detail texture would be unnecessary. This should look great with 1024x1024 terrain textures and shrinking the units of the terrain block down to a much smaller size relative to the player, which if my first point were possible, wouldn't create scale limitations in the level. Anyways, changes to the terrain blender would need to take place in the assembly from what i've been hearing. I actually once got 512x512 textures to load and appear correctly on legacy terrain, but after some tests I confirmed that they were automatically mipmapped to 256x256 at any distance so the full detail was never visible, and I kind of gave up there. I've been itching to pick up where I left off and try again.

5) Support for .dds textures. I've heard Atlas has that but it would be really nice if someone where to figure out how to make it work in the legacy terrain. Given the terrain blenders automatic mip mapping and assumed texture sizes, this would probably be a lot more work to implement than its worth.


Anyways that's everything on my personal wishlist. If there's a chance some collaborative effort could implement any of those ideas I would do everything I can to help.
EDIT: I realized I basically want the terrain from Morrowind... progressive terrain and automatic texture blending with dds textures of any size. I live in Maryland, perhaps I'll go over to Bethesda studios and harass them :)

#42 Just a quick note:

3) Already exists: search for "Networked Terrain Deformation". It's a basic implementation provided for example purposes, and does require modification for individual needs (note: lighting update is a huge one--and not one with a trivial solution). You are correct, it would tile, but again tiling can be turned off very easily.

#43 Thank you Stephen. The game idea I've been working on for quite a while now kind of rests on having a great amount of continuous open terrain, and the terrain tiling right now is the only way I can do that. So I'm choosing that over terrain deformation, which has no direct relation to my core game play ideas. I was just saying it would be convenient if I didn't have to choose in an ideal world. I also know that my priorities in this matter don't necessarily reflect those of anyone else or garage games. It is still my hope however that someone knowledgeable might be interested enough in any of these things to give it a try, or that if enough community interest could be garnered, it might influence some of garage games priorities, despite the difficulties involved.

Also for anyone who understands the terrain blender a bit better than myself I still have a question. I found that it was possible to allow the terrain blender to load higher resolution textures by altering the defined values in the .cc file, but that the output was still reduced in resolution. Should it be at all possible to fix the mipmapping to actually render the higher resolution without changing the assembly code? In general I would like to know more about the limitations of the assembly terrain blender because I'm not certain about anything. For example 512x512 terrain textures would load and display correctly albeit at the standard 256x256 resolution, but 1024x1024 textures just crashed torque outright. Also I could change the number of mipmap levels but changing it too far would also cause a crash.

#44 Here's a solution i had for a while.

This was some prototype code i was working on, making TGE legacy terrain with more detail, but still keep a very large terrain size. never finsihed, but i do plan to soon someday.





These are all TGE 1.5

BTW, i really hate detail textures, thats why i wrote this.

Still using 256x256 tiles. i manage to shrink the scale size lower, and add mutiple terrains to make the map still very large. only problem is. editing the terrain can be very annoying, where you have to hide each other terrain block while modifying one. its still a bit buggy, but will post some of the code soon. its actually very simple.

#45 Oh yeah. if you are adding mutiple terrains and want to move them around, you got to do the following

In example\creator\editor\EditorGui.cs, find this code section:

function WorldEditor::init(%this)
{
   // add objclasses which we do not want to collide with
   %this.ignoreObjClass(TerrainBlock, Sky, AIObjective);

   // editing modes
   %this.numEditModes = 3;
   %this.editMode[0]    = "move";
   %this.editMode[1]    = "rotate";
   %this.editMode[2]    = "scale";

//... Rest of function

Remove TerrainBlock from the ignoreObjClass parameter list.

Next, you open the mission. and remove the "locked" parameter from its properties.

This should now allow you to move the terrain around the world.

#46 Is that cel shading on the orc there? I'm starting to get really hooked on the cel shaded style and I think I'll use it in my next project.

#47 Revival or actually continuation of progress here....

I managed to define the top 3 things i want changed and had noticed a few things in the source. Listed by priority.

1) Larger terrain size (meaning a non-repeat 512 or 1024 mission area; the latter preferred)
Note: there doesn't seem to be a need to modify the blender.asm (or blender.cc) here at all
it looks at though all the calcs would line up fine, but I'm not so sure about fluid yet.

2) 2:1 Terrain textures Shrink scale sizes... (meaning textures applied never exceed double the size, I'd like 1:1 with more texture slots)

3) Splatting or linked bump maps to textures (meaning any texture used has a bump map that actually matches!)

Some things I've considered:
- More portalized zoning from mission map to mission map (aka larger map). The downfall here is more loading.
- Using many dts objects to *fill-in* what the terrain looks like bare. Downfall more to render, without anti-alias looks cheap.
- Working with huge texture sizes, filling in details then scaling down. (aka 2:1 Textures. i do this now, but with a great deal of detail loss)
- using Demeter completely overhauling the current legacy terrain, Obvious downfall is development time...

@ T squared i like what you've done and it would be great if we could work through some of those issues. I think combining a good deal of dts objects and those changes would give us something we can use a great deal better then it is currently.

#48 Well the only way to fix the issue, is by making the terrain block editable while its not on tile mode.

#49 You can find the fix for that here: www.garagegames.com/mg/forums/result.thread.php?qt=63214