Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Yet Another USGS Terrain Thread

Author
Message
Nateholio
20
Years of Service
User Offline
Joined: 30th Dec 2005
Location: I\'ve Been Everywhere
Posted: 29th Nov 2011 12:00 Edited at: 29th Nov 2011 12:33
Inspired by reading Visigoth's threads about using USGS terrain data in DBP long ago, I've decided to try my hand at doing so without external tools...to both learn how to build objects in DBP and generate terrains for my project.

Progress has gone well, the program builds a flat mesh, reads a USGS .flt file, sets the height of each vertex accordingly, generates normals, and produces an object from the data.

There is a slight problem however, the root of which I believe is that I'm not constructing the mesh the "correct way"...which would be to define a bunch of vertex data then define triangle strips. The problem is that the object sometimes appears transparent. I think the cause is that each triangle is defined by its own set of verts, and even though the data for neighboring verts is identical. I'm sure that minuscule float errors during rendering cause the problem.

The question is, is there a way in DBP to construct triangle strips? Before you say use this tool, that tool, or whatever plugin remember that I'm doing this to learn...not fix my problem with another person's code.

I've included the code and a sample terrain for the hills behind my house. Use the code however you want. The EXE uses Sparky's DLL, so change you'll need to change the pertinent flag in the source if you don't have Sparky's installed. Instructions on how to d/l USGS data are also included in the source file. The code has a few bugs, irrelevant to its purpose, and doesn't care much for terrains larger than about 500 x 500 points.







In Development: K96 - Combat Simulation
Cybermind
Valued Member
23
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 29th Nov 2011 20:43
From the help menu in DBP:
Quote: "The mesh is used as the root limb for the 3D object"


Could you perhaps "glue" them together as limbs hence making one big object?

The byte chrunchers are coming...
DIVIDING BY ZERO/BECAUSE WE SUCK...
Cybermind
Valued Member
23
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 29th Nov 2011 20:52
I looked at the limbs command now, it seems you can do it like this:

1. make the root limb triangle.
2. construct the next triangle.
3. make a mesh from it.
4. position it at the exact spot, i.e use the coordinates of the triangles it is going to attach to.
5. add it as new limb.
6. repeat 2, 3, 4 and 5 until there are no more triangles to be added.

I have never done anything like that so I do not know if this works :-P

The byte chrunchers are coming...
DIVIDING BY ZERO/BECAUSE WE SUCK...
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 3rd Dec 2011 09:59
You could use IanM's make object commands.

From what I remember, you can

Start Object

then create limb Blah blah blah

then when you have finished creating your object you:

Finish Object

May not be accurate but from what I remember, it sounds right! lol

My signature is NOT a moderator plaything! Stop changing it!
Jeff Miller
21
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 3rd Dec 2011 17:46
You can use IanM's MAKE OBJECT NEW command with the vertex data and index data commands in DBP to make any kind of object, including triangle strips. You can make it in any FVF you think best for your needs, and you are in complete control. You are free of degenerate triangles, duplicated triangles, etc. I've used it to make everything under the sun, from a piano to a geodesic sphere. I might also add that it is extremely fast. In fact, I generally just load the vertex and index data of my objects into programs and make objects at startup using these commands instead of loading object files.
Cybermind
Valued Member
23
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 3rd Dec 2011 19:56
Quote: "Before you say use this tool, that tool, or whatever plugin remember that I'm doing this to learn...not fix my problem with another person's code."


I think he want to do this without plugins :-P

The byte chrunchers are coming...
DIVIDING BY ZERO/BECAUSE WE SUCK...
Jeff Miller
21
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 3rd Dec 2011 23:03
He isn't adverse to plugins per se. Note that he is using Sparky's in his code. I think he means that he is not interested in a plugin that generates terrains instead of constructing them yourself. IanM's plugins are by and large a vast expansion of the DBP command set. While some replace what would otherwise be a bit of coding, others actually allow you to do plenty of coding that you otherwise would not attempt. As for a learning experience, I think making your own objects with the Make Object New command gives rise to many opportunities for learning basic object structure, and plenty of opportunities for procedurally generating complex shapes. I wouldn't regard any of them as a "tool" for generating a terrain, but rather an opportunity to program to generate a very good terrain, especially with the clever use of USGS data. Also, the program speed will enhance the experience; he can get away from writing so many strings to a file.
Nateholio
20
Years of Service
User Offline
Joined: 30th Dec 2005
Location: I\'ve Been Everywhere
Posted: 6th Dec 2011 09:21
@Cybermind & Jeff
I am looking to do this w/o plugins, just to learn. However, for anything other than that I'd be using a plugin most likely.

I do have a workaround though...possibly. Since I'm splitting up USGS data into 1mi square chunks, each measuring 160 x 160 verts, the idea is to just generate a plain fitting the dims/vertcount and load it into memory then manipulate the vertex data. Going over the vertexdata commands makes this seem like it'll work. Haven't tried it yet though...been playing EVE Online again lately.

In Development: K96 - Combat Simulation
Visigoth
21
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 9th Dec 2011 03:34
@Nateholio
sorry, been away from the whole programming thing for a while. I did get your message thru gmail the other day. I don't check that very often. I have some tips. First off, don't bother building the mesh. thats extra overhead you don't really need. Just use a mesh from any modeling app, weld it, and load it as an object. Clone or instance as necessary, and use vertex data commands to adjust the heights accordingly. If you insist on building meshes, I can tell you IanM's plugin is a great help. The make object plain command works great. I have a question for you though, how'd you get 160x160 verts per chunk? I always got errors after 101x101. I think its a memory thing per limb, 64k, I think. Been a while since I played with the terrains. As for the invisibility problem, you have to set object bounds on each one, if its the same problem I had. I planned on getting back into this in a while, things are crazy here at home, just got a new job, been working alot, and haven't had any time to play. But glad to see someone taking an interest in all this.
Nateholio
20
Years of Service
User Offline
Joined: 30th Dec 2005
Location: I\'ve Been Everywhere
Posted: 9th Dec 2011 05:17
Ah, glad you got the message.

I trashed the whole idea of building a mesh in DBP for building a flat plain (160 x 160 verts) in MS3D instead.

Not sure where you're going with the vert question so I'll give you two answers to cover both bases.
I got 160x160 because I'm doing everything in US measurement rather than metric (I know, I'm a caveman, evil, and so on)...Each heightpoint at 1/3 arcsec is about 33ft from the next...My terrain chunks are 1mi square, hence 160 verts per side.
I've only tested loading the flat base terrain...which measures at 25600 verts. It seems like there are no problems; however, I haven't tried to manipulate the verts yet so there may still be an issue.

In Development: K96 - Combat Simulation
jason p sage
19
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 15th Dec 2011 16:37
Ahh... Good luck here. I worked with Visigoth... and added USGS to the Jegas Game Classes for DarkGDK (Before they changed how all the vertex stuff worked... it was flawless).

I didn't have a memory problem myself.. but I did use frustrum culling to hide the stuff out of the camera. But I did do the limbed thing. I made like a chessboard of limbs that would cover what I was loading... and I applied it that way. One thing I did to make it a little easier to separate DarkGDK stuff from what I was doing is to have a routine I could call SetVert(x,z,Value) and GetVert(x,z) to respectively set and get heights from the terrain. This meant I had to write code smart enough to know what limb, and how to set vert (potentially multiple along seams) and gave me a way in game to do something like DarkGDK/DarkBasic's terrain get height function... so you can place trees and stuff.

I actually just made a utility that does this so satellite data can be used for both DarkGDK, DarkBasic and all the other game engines out there.

Good Luck man - You're very very close to nailing this thing.

Jeff Miller
21
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 17th Dec 2011 01:44 Edited at: 17th Dec 2011 01:57
How rectangular is the data? Not all arsecs are equal when it comes to projected distances from spherical angular data. If the angular measurements are from the center of the rectangular area selected then you are home free. But if they are arsecs in Latitude and Longitude, you encounter a distortion. If the 10m (approx. 33 feet) distances for 1/3 arcsec are good for North-South Latitude distances, East-West distances from longitudinal increments would be similar for an area centered at the Equator. But while the North-South distances should be relatively independent of location, East-West distances for 1/3 arcsec would be very latitude-dependent. In your location 1/3 arcsec in the projected East-West direction would have a median value of less than 28 feet rather than 33 feet if the arsecs are in longitude, suggesting that a grid intended to simulate a "square" mile should be something like 190 by 160, rather than 160 by 160.

Login to post a reply

Server time is: 2026-07-09 15:47:34
Your offset time is: 2026-07-09 15:47:34