posted 04-30- 11:29 PM               

How hard would it be to create a plugin for OPS and/or AC3D that would do the following:

1. Export as terrain (dicer). This would take a terrain as one object and tile it into a terrain sm file made of the LOD mesh tiles named correctly. It would also set the proper supertexture name for the texture and map each square correctly.

2. Import as terrain (un-dicer). This would take a terrain sm file with its LOD tiles and weld them into one big terrain objecr. No texture mapping functionality.

Here is my thinking about how to create a new terrain from scratch.

1. Create a rough texture map of the entire terrain to show roads, rivers, etc. This woudl be maybe 1000 X 1000 pixels.

2. Create a flat square terrain in a 3D editor and map the new terrain texture to it.

3. Edit the new 3d object to match the texture, adding small hills, river beds, raised roads, etc.

4. Save your work

5. Export the object as mentioned above, specifying how many tiles to dice into. The result would be an SM file containing the square LOD tiles of your terrain, each mapped to a non-existant superTexture tile texture file using the correct naming convention.

6. Now take the rough terrain texture you created and transfer it to a high rez graphic - full size. (this could have been what the rough image was derrived from).

7. Dice the image using the parsoft dicer.

8. Now you have a new terain! Just add trees, airfields, ect.

Does this sound very hard, medium, easy, impossible?

Also a walk-thru mode in OPS would make positioning trees, etc. much easier.

Is this a good approach, or am I way off?

I could also see a tree placer app. It brings up a top view of the terrain. You click on points and it adds file references to trees, placing it at the correct height to intersect with the terrain elevation.

Making a new terrain would be killer fun

------------------
-Sv =FC=

WWI in SDOE!

posted 05-01- 12:27 AM               

1. You create two "textures", one is the actual texture and the other represents the hight map. You can make both of them in paint-shop or something. The height map is just the varying shades of gray etc (or green or ...). For example you might make a valley that gradually rises to hills on each side of it.

2. Save the height map texture as a raw type. i.e. no header, just the data.

3. Import this into the DEM2SM proggie.

DEM is really just a heightmap, and infact you can import some DEM's directly into paint programs. If you want historically correct terrain you use a DEM, if you want fantasy/not accurate terrain you can create the DEM yourself using a Bitmap in a paint package. Another method might be is to take a low res DEM, import it as a bitmap into a paint program and, increase the resolution and edit the bitmaps to show more details.

For what you are actually talking about, i.e. taking an exiting mesh and cutting it up, someone could modify the MG program which takes creator flt terrain files and cuts them up.

posted 05-01- 11:05 PM               

I'll have a look at it hopefully tonight or tommorow nihgt and put back the bits I dicked with while experimenting and post it somewhere.

What it will do after that is:

* Take a Raw binary heightmap of a specified bit format and create a SM file made up of lots of 'tile' models with the right heightmap

* Make the superTextureId (or whatever its called) match to the the id's created by the dicer proggie.

The first one needs a little bug fixed and the second one isn't even implemented but shouldn't be too difficult.

I would be interested to see what you could do with the bitmap heightmap technique and DEM2SM. There is an article on gamasutra.com about creating the bitmaps to use for height fields, that might be useful.

posted 05-01- 11:33 PM               

That link was great reading! How will you approach the conversion from bitmap height filed into 3D mesh tiles?

posted 05-02- 12:37 AM               

Just think of the bitmaps pixels as a height value and there is really no change in implementation from converting a DEM.

For example, if you create a gray scale image, it will be a 8-bit heightmap with the low areas black and the high bits white, with shades of gray in between.

You can do a similar thing with other image formats so long as they are not palletised.

posted 05-02- 08:34 AM               

How do you convert the DEM? to mesh

From reading that link and thinking about the process, it seems like there are some challenges. What happens when there is a sheer cliff? (A sharp color change) - does this fill with a poly, or is there a hole there when viewed from the side?

Also they talked about smoothing allot, or not smoothing when that is needed. How are rolling hills created? How would a sharp jaged mountian work? In other words, how do you decide how the polys are made from the DEM? Are they triangles? Do you find the vertecies by averaging? This is just really interesting...

-Sv

posted 05-03- 01:00 AM               

What is nothing like a line of (ascii-) numbers now can also be expressed as a 3 X 3 matrix:

30 34 29
35 34 29
36 37 31

30 arc-seconds are roughly 1 km, depending on your latitude and longitude.

Now, SDOE-terrain is made up of 3D meshes, so instead of height-points at given intervals, like above, you have a real 3D-model consisting of polygons (mostly triangles), disregarding any intervals. DEMs can be converted to 3D-models, with the outcome being somewhat less optimal than SDOE's terrain, but a lot closer to the real thing.

With the DEMs freely available for Europe being spaced at 30 arc-seconds (=1km) the tradeoff should be OK in respect to framerate. Although the terrain will be somewhat less detailed you'll get the impression of flying over the 'real thing'.

Here's how I think a DEM2SM converter would ideally work:

1. let it read a specified part of the DEM
2. convert it to a smoothed mesh and
3. put it out readily tiled and textured

You do step :
Make a big texture for the terrain and dice it using the dicer-prog. It should then work smoothly with your new terrain.
If I understood Bryan correctly this is exactly what DEM2SM does. Loading a 40x40 mile terrain-mesh into OPS would certainly not be much fun unless you have really professional hardware (something like a Silicon Graphics box).