Planetary coordinates

It's good to use for distance away fron the player, though, right?

Now that I re-read what uteen said, that would be much more suited by a blur effect. What I've written is for terrain in the distance.

Also, I've been able to put together a simple grid, I'm now working on the subdivisions.

roadkillguy wrote:

For simplicity's sake I was thinking of something like the following:



Not necessarily like a quadtree, just sectioned LOD. It may prove to not work if the planet is VERY large, but for this game I was thinking spore sized planets or less.

It would work by having nodes that contain two-dimensional arrays. To get the vertices, we render the initial grid, and then add more vertices depending on the detail level.

It works in my head anyway

EDIT: Here's some pseudo-code.

Spoiler:

I've been thinking about this quite a bit during lectures, and this is pretty much what we need. We need a base detail level for environmental simulations such as the discussion in another thread about water simulations and erosion and whatnot.

You have a base detail level as an array, lets say, a meter by a meter squared, and then you interpolate that into a more detailed mesh. Otherwise when we get to implementing Navier-stokes, the whole world asplodes. Navier-stokes algorithms on a randomly detailed quadtree is INSANE.

Commander Keen wrote:

Planets should be as scalabe as possible, because right now we can't just see what size will have the best gameplay/performance ratio. Limiting it to Spore size or less might lead us into problems later.

Yeah thats easy. Change the constant, change the planet size.

~sciocont wrote:

roadkillguy wrote:

I'm sure it will work for what we're trying to do.

Again, experimentation is the best way to figure this out.

AFAIK, that is what roadkillguy is doing now

Recently I've actually been thinking about using perlin noise to generate the terrain. Then, theoretically, we could get as detailed as we want letting the equation generate the terrain.

Navier–Stokes? Fluid dynamics right? That sounds pretty crazy... I have to admit I've never made or played a game where that was implemented.

roadkillguy wrote:

Recently I've actually been thinking about using perlin noise to generate the terrain. Then, theoretically, we could get as detailed as we want letting the equation generate the terrain.

Navier–Stokes? Fluid dynamics right? That sounds pretty crazy... I have to admit I've never made or played a game where that was implemented.

It's quite interesting.


Okay, more detail:

you have a set of base arrays:

planetgrid[][]
These are all cells of even size, say 1 metre. and take up a space of say 100 Metres.
Then each 100 metre grid is stored on a bunch of nodes, which are attached to a node the size of the cube face, or something similar.

We apply perlin noise to the grids we are working with, to get our planet layout.

This grid is further subdivided to create our detailed mesh close up.
For rendering far away, we simply take every second, fourth, or eight value and so on.

This way we have a consistent size for the terrain simulations and we can still LOD to our heart's content.


We could cut it a thousand ways, having only one grid for each cube face, and so on, but this is a general idea. We could also have 100metre grids stored on a quadtree that gets leafed with the average height of the game grid or something.

P.S.

wow. I accidentally edited your post. Still getting used to being a mod suddenly :/

See, the problem with generating top down if we want dynamic terrain is just that. you can't have dynamic terrain.

So... We can still generate procedurally, but we have to go bottom up.

That's true, and it's actually coming along fairly well. I have an ogre head showing up, along with a nice grid of algorithmically generated faces.

The only thing I'm worried about is merging the two. If the current project is a spline editor, and I'm working on an entire planet It may be a while until we merge the two.

roadkillguy wrote:

That's true, and it's actually coming along fairly well. I have an ogre head showing up, along with a nice grid of algorithmically generated faces.

The only thing I'm worried about is merging the two. If the current project is a spline editor, and I'm working on an entire planet It may be a while until we merge the two.

Not really. It's segregated quite a bit. most everything is implemented as a module.

The renderer is part of the parent engine, so that we have to heavily modify. But the terrain output merely needs to be wrtitten into a module class, and implement the load unload enable disable and step functions, and bam you have a module.

Modules work like this:

a standard module that only implements load unload enable and disable functions can plug in as a dll (i'm currently working on the dll plugging code) and is managed automatically by the module manager within the parent engine.

Any custom modules can be loaded manually from the engine and compiled directly into it.

EDIT: CONTINUED:


all modules get passed a pointer to an assetmanager class, which is where all assets (game resources, such as game objects, fonts, etc.) get stored.

Ill include a versioning system as well so that any dll compiled with the assetmanager header will contain the assetmanager version, and when loading the dll the modulemanager will check for compatability with the current assetmanager and possibly providing an alternate interface in the case that there is a mismatch.

Something-of-a-bump.

What I'm getting from this is that as you get closer to the planet, the grid gets smaller and smaller; thus, if you have a 4 x 4 grid that splits (quadtree), one of those four squares will have four squares inside it, and in essence the grid is getting smaller and more of the planet is being generated, or loaded, that is, if you've visited it before.

Getting warmer?

Noitulove wrote:

Something-of-a-bump.

What I'm getting from this is that as you get closer to the planet, the grid gets smaller and smaller; thus, if you have a 4 x 4 grid that splits (quadtree), one of those four squares will have four squares inside it, and in essence the grid is getting smaller and more of the planet is being generated, or loaded, that is, if you've visited it before.

Getting warmer?

Spot on.

Something to that effect. This is how I thought the noise should work.

1. We create a nice subdivided cube.

2. We send the vertices through an equation to get a sphere.

3. We apply the noise to get the altitude.

While I wrote that I just realized that may not work if we don't want to re-render the entire cube/sphere at once..
In other words, if we only want to update the terrain we're near it would fail when subdividing.. I'm just worried it will flicker.

roadkillguy wrote:

Something to that effect. This is how I thought the noise should work.

1. We create a nice subdivided cube.

2. We send the vertices through an equation to get a sphere.

3. We apply the noise to get the altitude.

While I wrote that I just realized that may not work if we don't want to re-render the entire cube/sphere at once..
In other words, if we only want to update the terrain we're near it would fail when subdividing.. I'm just worried it will flicker.

You cull the vertex output, not the not the original data.

Well... Nevermind. I think I got it. I tend to go back and fourth a lot

I need you to create a sourceforge account. Then i can give you a branch on svn, which we can merge to the trunk at regular intervals

Allright, I'm pretty sure that worked. I have the same name as I do here.

Okay, ill work on giving each of us (currently papergrape, yourself, and I) a separate branch to work on, with trunk merges reserved for agreed apon states of the branches.