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 Discussion / Partial loading of 3D world question

Author
Message
BN2 Productions
16
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 10th Jul 2013 01:02
I'm working on a game that involves a large 3D world. I'd like to prevent unnecessarily long loading times so I had this idea:

What if a bitmap of the entire map could be loaded (RGBA values would correspond to Height,TerrainType,PassibiltyCode,and Object Data values, for instance), then, based off of the player/camera position, the program could take the area of the image that is relevant and real-time generate it via memblocks?

This of course prevents the ability for multi-floor travel (no overlapping surfaces), but for a landscape that wouldn't be too much of an issue.

Is this reasonable or would DBC be too slow in updating the mesh then converting it to an object for texturing for it to be effective?

Other thoughts on the subject are appreciated.

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 10th Jul 2013 10:08
I'd say it's a possibility, but you'd have to do a few optimizations.

I'd do it like MineCraft does it: Split your world up into "chunks", and load/unload them appropriately according to the position of the camera.

Since you can't load and unload in a separate thread with DBC, you just have to spread the process out over many loops to give the illusion you're doing it in parallel.

Modifying meshes in real-time in DBC has been proven to work (see: SoulHunter), and I don't think you'll experience any slowdowns with this if you keep the polygon count per chunk low enough.

TheComet

Pincho Paxton
17
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 10th Jul 2013 20:20 Edited at: 10th Jul 2013 20:21
Quote: "What if a bitmap of the entire map could be loaded (RGBA values would correspond to Height,TerrainType,PassibiltyCode,and Object Data values, for instance), then, based off of the player/camera position, the program could take the area of the image that is relevant and real-time generate it via memblocks?"


You could do the working out before you run the game. It's faster just to use the Data, and not load the bitmap during the game.

BN2 Productions
16
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 10th Jul 2013 20:57
Quote: " You could do the working out before you run the game. It's faster just to use the Data, and not load the bitmap during the game."


Absolutely. My intention was to either use a memblock or to use an array.

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
Pincho Paxton
17
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 10th Jul 2013 21:07
Yeah you can do that in real time.

Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 11th Jul 2013 18:23
@BN2

"Endless" terrains are possible as well. I've done some experiments using libnoise and DBC and it works quite well. You even have the ability to zoom in or out thus increasing or decreasing the detail.

I've also tried some tests along the line of using a premade bitmap. I've created a heightmap bitmap, then converted that into my own heightmap format and stored it in a memblock. The conversion was so I could control the size of the memblock. I could store each height value as a byte, a word, a dword, or a float depending on how I wanted to handle the actual height. A BYTE usually has to be converted using a scale formula. A WORD should be enough values without any scaling and a minimal amount of storage for a memblock. So the static terrain data of 1024 x 1024 cells could be stored in 1 or 2 megs (BYTE or WORD).

I also had created my own matrix code in straight DBC that made meshes and it was fast enough to scroll the map.

I imagine that the DLL I made and posted of Kelebrindae's memblock matrix commands would be a little faster since most of the calculations are done in a DLL.

The concept for a static or endless terrain is this:

1. The camera or player position is always centered on the matrix. The matrix should be an odd number. 33 by 33 cells seems to be a pretty good number, but I usually only use 17 x 17 cells and control the detail with textures. This gives me a little more juice for my old single core 1.5 ghz processor. But on my i7, 61 x 61 works quite well.

2. As you move, don't move the player, move the terrain.

3. Once the terrain has moved so that the player has reached either an X border or a Z border of a neighboring cell, update all of the points on the terrain with data from the heightmap.

4. Scroll the texture to the cell border, then move the entire matrix back half of the cell size of the current border the player has reached. That means that if the matrix had been moved in the x direction until the player touched the X border, you would move the matrix in the opposite direction by 1/2 the X cell width

The difference between using an endless height map vs a static one is that the heights are always recalculated in an endless one based on the current position. A static one has all of the data pre-stored.

Enjoy your day.
TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 11th Jul 2013 19:30
Latch just reminded me of one of the old DBC demos. It demonstrated exactly what Latch is talking about. I can't remember where it was any more, either under Basic3D or Matrix commands.

TheComet

Fluffy Rabbit
User Banned
Posted: 13th Jul 2013 08:00
I would like to see an endless terrain demo in action.

Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 3rd Aug 2013 22:14 Edited at: 4th Aug 2013 00:49
EDIT
The code looks weird in different browsers. It\'s tabbed all funny and sometimes there are no carriage returns so the code runs all together. I don\'t know why it\'s happening but it makes the code hard to understand.



Quote: "I would like to see an endless terrain demo in action.
"


The following code shows the concept. This will indeed be an endless terrain - limited only by the size of integers on DBC. I'm using a random generator based on the one used in libnoise. However, this example doesn't use any fancy noise functions to make things pretty. This is bare bones. What makes it endless, is the random number generator's ability to create the same values based on the same seeds.

If we use the X and Z locations as our seeds, then we get our endless terrain. You can come back to locations and it will be the same as it was on first visit etc.

The example can be expanded upon - use a nice noise function instead of random jaggies, use memblock matrix objects instead of the built in matrix commands, add texturing and handle the normal changes (can also be procedurally done similar to the landscape).

This example also needs a little smoothing out of the movement. Also, I'm updating and drawing everything every iteration. It should really only be updated when there is a change, like the camera has crossed a tile border.

Use UP DOWN arrows to move. Mouse to steer




@BN2
Load time for a terrain could be basically eliminated. However, if you change the texturing, you might have to do some loading.

Programmatically, you could use a perlin noise function to generate other things - houses, trees, walls, textures, - depending on the depth/extent of the procedural generations, the trade off might be performance. However, if you have stored "pieces" of objects that can be assembled into whatever you need, then you could use short iterations of noise functions to assemble aspects of your world. You can return values in 3 dimensions from perlin noise. These values could be the same flags/triggers you were talking about storing in a memblock or bitmap - the difference being the structured noise would be calculated on the fly.

Enjoy your day.
BN2 Productions
16
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 3rd Aug 2013 23:25
Quote: " What makes it endless, is the random number generator's ability to create the same values based on the same seeds.
"


I must say, that is genius!

Thanks for the tips, I'll look into them!

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
Fluffy Rabbit
User Banned
Posted: 4th Aug 2013 06:49
Awesome. It jitters when I'm going at an angle, though. Were you planning on turning this into a full game, Latch?

Also, I would think that a rand/noise function would be better than DBC's built-in RND for the sake of consistency across languages.
Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 4th Aug 2013 21:14 Edited at: 4th Aug 2013 21:24
Quote: "Were you planning on turning this into a full game, Latch?"

The example? Nah. I just wanted to post a quick and dirty method of how a procedurally generated terrain could be made in DBC using the built in commands. As far as the rnd generator, the built in one gave poor results (it's hard to come up with a consistent, good, re-seeding value) - so I chose to use a custom one.

A thing to try to make it more "terrainy" would be to incorporate a perlin noise function or maybe a diamond-square (midpoint displacement) heightmap function. Use a custom random generator to re-seed the points to make it endless.

Terrain Generator[/href]

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 4th Aug 2013 21:33
That looks pretty realistic. If I didn't have other (non-DarkBASIC) projects going on, I might take a shot at combining that terrain generator code with your endless landscape thing. Is it even possible?
Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 4th Sep 2013 01:47
Quote: "...I might take a shot at combining that terrain generator code with your endless landscape thing. Is it even possible? "


I think it's possible, but would be very difficult with that algorithm. It seems a little finite in that it calculates the terrain based on a grid size. It averages the points on the grid to create the landscape.

I suppose if you shifted entire edges and used those as starting points for the next set of averages, you could create an endless landscape.

Enjoy your day.

Login to post a reply

Server time is: 2020-08-12 02:34:42
Your offset time is: 2020-08-12 02:34:42