@Niels Henriksen - Thanx for piping up. I for one will keep this going if I can with Pixel Perfect's help and others.
@Pixel Perfect - You'll be missed my friend - look forward to your return
Topic Stuff: Level Design, Editors, Techniques, Cam Settings, FOV - Get that Perfect "Look"
Level Design - On going discussion - the odds are against for certain kinds of landscapes. This thread is an ongoing discussion of just how some of these things can be conquered - but the war is still on - haven't got this licked yet.
Editors - Good reports about 3DWS - Has a powerful export "Native" format - but its binary - and you need to study the record structure to read it properly from what I can tell. This can take much more effort initially for some but the benefits will probably be worth it if you're seriously into this whole game making business. Pixel Perfect mentioned that Lost In Thought (LIT) has been hammering at this - I'd be curious to hear his thoughts about it if he's around.
Good Reports about TED. Ted has a couple gotchas but I am confident that Dan (the author) is actively improving the product - and it is a wonderful editor and the native "EPR" export file - which has info like where you placed trees, buildings, their scale, the camera range, fog distance, sun light color and "Height only" placement - (forgot if it has direction - I think so...), all in all very neat - text based - easy to use format. Tricky stuff to remember - is that is was written in blitzbasic and so some "numbers" and "flag Settings" need to be translated to the best "fit" in DBPRo/DarkGDK - this takes some trial and error - and occasionally a stop at the TED forum to see what flags mean what etc.
TECHNIQUES: For my Ted Loader, (and if I do 3dws I'll probably do the same thing) , is I have ported some decent "clouds" code from a dark basic demo titled simply "Clouds" - they are just wispy clouds - but I modified this so I can have three colors - one for each of the three "Altitude layers" I set up. Why is this a technique? Well - I have the ability to CREATE the initial clouds, and then a routine I can call (timer based) to keep the clouds moving smoothly throughout the game. The Technique is that I made my TED EPR (native file format) loader able to read some settings that match the "look" i want by simply typing into the Main Custom Section (Called INITS):
CLOUDLAYER1=230,200,200
CLOUDLAYER1=230,230,200
CLOUDLAYER1=230,230,230
This gives me three sets of colors - layer1 being the lowest.
Also, another technique that isn't rocket science but weidl awesome results is setting up a uniform SkyBox set up - and then making a directory called Sky or SkyBox - and have each "One" in its own directory. Also - toss in your water shader code and any relevant color tiles that match the "look and feel" of said Skybox. Make it consistant in each directory - where they look different but - are called into and "Made visible" the same way for each one. Then - as I have done - is I can load a "Ted Level" and either use the default skybox settings it has (6 files that make up the textures for your skybox) or override this in my EPR loader by a command in the CUSTOM area:
SKYBOX=Sky\SummerDay1
This overrides the default - and loads a specific one. Also - I mentioned water because I added a feature for that as well - But NOT in the INITS area - in the OBJECT INSTANCES Area - so I can say that a object I placed - is infact water:
WATER=Sky\Summer
I also added a "smoother" water shader for say ponds and small lakes:
LAKE=Sky\Summer
typically - I use the "WATER" shader only for the surrounding ocean and use the OBJECT INSTANCE custom area for the lake setting because in life - inland bodies of water are usually calmer.
So I can now - either inside my program or by parsing the EPR file when I load a level - control water. I have options. Save multiple EPR text files with different settings, and call them by name - this is cool because the media is more or less shared - and the EPR Text files with custom sections etc is quite small. This allows changes many thing without needing to recompile the game. Alternately - because my little code lib allows me to call the same internal functions - I can change a sky, clouds, and water stuff in the program if necessary - perhaps a transition from night to morning or water turning green from poisnous algae that glows in the moonlight - who knows.
It was a bit of work to get this all set up - that is having a system for this sort of thing in place however the fact that I can reuses it over and over - game to game - screen to screen - makes it worth the effort to me - and generally a decent media/shader etc environment system can be useful regardless o f the underlying engine - DarkGDK, DBPro or other.
I thought I should mention I wasn't the first to make a TED loader - but I definately took the example code that was available - studied it - even started to use it - until I understood the format better and how I could use it to my advantage. At this point it made sense to me to rewrite the loader from scratch - my way - so its serves my game, my uses, etc. Generic doesn't always get you where you want to be.
Camera Settings - I don't have much to say here except that often in the forums I hear - keep camera from 1-5000 - default is good - or other such claims. I personally have tried things from Near range .1 to far range 10 to things as big as .5 near and 100000 far!! Results? Vary - depends on the # of polys, the camera settings may or may not work as desired depending on eprspective etc - but I definately think "Whatever works" is the rule versus trying to stay in som limits that just happen to work for others.
The camera thing is that there isn't way to recall FOV (Field of view) the angle from your "cam eye" you see in front of you. You can get various effects from using BIG FOV - like that view in many race car - rogue car street racer games" to very intesting shots with very small FOV. Note - you can tell DB/DarkGDK what you want FOV to be, and you can change it on the fly - but I've yet to find a command to read back its current value. Solution, set up a variable, and your own FOV Set and Get functions so you always can read it back. Why? ZOOM LENS! The larger the FOV is initially - the more room you have to shrik it. Shrinking it magnifies stuff! The thing you have to remember - is that if you have LOD (Level of detail code) based on distance from camera - (and the bad guy is kinda far is using a low res model) - you need to remember that if you ZOOM in on him - you'll want him high poly. There probably could be implemented an algorythm to make the FOV and DISTANCE of the object from the camera keep the same "LOD" look and feed - but personally - if my FOV is over a certain angle and the object in question is INSCREEN - this is usually good enough to decide to switch to highpoly for that model. Note - this is along side other "code" that excludes models that aren't on screen etc and other such mechanisms in an effort to keep the action and frame rates happening smoothly. I have only done this in DarkBAsic Pro so far but I'm sure the rules are the same. I really love that in Iron Infantry - flying a helicopter - I can see a little dude running across a field - who looks like an ant, hit the scroll wheel on the mouse and zoom right up on him (Apache TADS system kinda) - and then saw him down with the machine gun. I hear he is not to happy about it though
The other thing I'm doing now to get that perfect "look" (which is an ongoing battle and I can only say I'm working on it) is taking the work that Visigoth did and trying to take it a bit further. Let me start by saying he has done AWESOME dynamically making Meshes based on the satelite information. At first I was like WOW - Satelite - that must of been hard - but after looking at his code - that isn't the hard part. The hard part (I need to study a lot more) is how he took the height information (the satelite info is actually fairly easy if you cover a limited area) and made the Terrain meshes totally in memory! "Welded Vertices", Adjusted Normals(setting up the faces properly), adjusting vertex lighting.... WOW - that is much harder than reading a grid with elevation... basically an array of "Y" values!
Anyways - His demo/source is limited to a certain size of Satelite info - you could change it to get a bigger smaplinig... but I personally like the detail reange he has - its just limited in the ballpark of only viewing 1000x1000x10meter at a time - Approximately. What I'm trying to do to leverage that is make a way that you can load any size grid you want, and it chops up the area and places it into these VisiGoth GeoMapping digestable "chunks" - and then modifying his code so it saves all the meshes, all three resolutions. The utility I'm making that does the cunking will also make heightmaps bitmaps - both 1024x1024 or smaller as well as making tiny tiled ones if desired. Why? as a tool to either import the tiles into systems where heightmap is all that will do OR as a guide to texturing the little buggers.
I'm not trying to make a facy UI, fancy anything - just trying to be able to make a decent LOD system based on these tiles - three resolutions, and they are small enough tiles where dynamic loading might be very feasible - so I'm going to try it. I realized the Terrain editors are limited in "size" no matter what you do - but this technie - not unlike how Flight Simulator and X-Plane kind work - seems inteeresting to me.
I've though about how the world isn't perfectly round, and how the coordinates of the bottom left of the maps is stated in degrees longitude and latude, and have not come up with a miracle solution to turn what is a ROUND GLOBE into a perfect set of seamless worldwide tiles. So - All I'm really trying to do is download say instead of a couple square miles at a time - is perhaps beable to take a 20mile square satelite download and turn it into a system of hi, med, low resolutions with as little work as possible. download it, dice it with my tool, feed it to Visigoth's system (modified to save the meshs as directX with numbered filename so can reload and know where they go) and probably make my tool do more than heightmaps - maybe take the satelite pictures of the terrain and use that as "Starter Textures" - tiled nicely or "Big Textures" ... dunno - its a side project - I feel will help make Iron infantry that much more cool. Satelite terrain just has the right proportions and nature has a way of drawing its own terrain better than I can - I'll just present it as best I can and color as best I can ... again - using nature as my guide.
Phew - Got work to do...later