Planetary Scales

zippybomb wrote:

MeowMan1 wrote:

I'm sorry, but that sounds ludicrous! How are we going to make planets, THAT BIG?!
I'm perfectly calm, btw.
It just sounds like to much, sure spore planets are small, but who the heck would want a planet 312 times the size?
why such big planets?

You don't want a planet that you can explore in an hour, you want something that will provide endless hours of exploration and intrigue. You want it so that no matter how long you've played on one planet, there will always be something new to do.

There's no way to run multiple biomes on a tiny planet.

ok. You have now convinced me that it IS a good idea.
Thanks for answering, guys, I was kinda worried for a moment...
just wondering though, will the colonies resemble actual colonies, or how they would be, instead of a stupid little bubble, like in Spore?
Please tell me they resemble a true colonies...

MeowMan1 wrote:

ok. You have now convinced me that it IS a good idea.
Thanks for answering, guys, I was kinda worried for a moment...
just wondering though, will the colonies resemble actual colonies, or how they would be, instead of a stupid little bubble, like in Spore?
Please tell me they resemble a true colonies...

They would exist however you build them.

SWEET! I didn't know we could do that...

MeowMan1 wrote:

SWEET! I didn't know we could do that...

you need to read more the whole forum then buddy.....

I have an idea: the size of planets can variable and altered by settings.

What this means is that depending on how good your computer is, you could choose to double the radius of planets, and if you want your games to be more arcade-style you could make the planets smaller.

I'm not sure how easy this would be to program though.

Holomanga wrote:

I have an idea: the size of planets can variable and altered by settings.

What this means is that depending on how good your computer is, you could choose to double the radius of planets, and if you want your games to be more arcade-style you could make the planets smaller.

I'm not sure how easy this would be to program though.

Changing stuff like that is exceedingly easy. What's difficult to program is how to not render the entire planet at once.

roadkillguy wrote:

Holomanga wrote:

I have an idea: the size of planets can variable and altered by settings.

What this means is that depending on how good your computer is, you could choose to double the radius of planets, and if you want your games to be more arcade-style you could make the planets smaller.

I'm not sure how easy this would be to program though.

Changing stuff like that is exceedingly easy. What's difficult to program is how to not render the entire planet at once.

LOD is determined by distance from the camera as a radius around it, right? We'd need to reduce complexity within a radius of a smaller size is all. Make sure the highest LOD radius in the case of small planets is no more than 1/4 the radius of the planet or so, and we should be fine.

~sciocont wrote:

roadkillguy wrote:

Holomanga wrote:

I have an idea: the size of planets can variable and altered by settings.

What this means is that depending on how good your computer is, you could choose to double the radius of planets, and if you want your games to be more arcade-style you could make the planets smaller.

I'm not sure how easy this would be to program though.

Changing stuff like that is exceedingly easy. What's difficult to program is how to not render the entire planet at once.

LOD is determined by distance from the camera as a radius around it, right? We'd need to reduce complexity within a radius of a smaller size is all. Make sure the highest LOD radius in the case of small planets is no more than 1/4 the radius of the planet or so, and we should be fine.

That's the idea. The problem is making it not choppy when it updates.

roadkillguy wrote:

~sciocont wrote:

roadkillguy wrote:

Holomanga wrote:

I have an idea: the size of planets can variable and altered by settings.

What this means is that depending on how good your computer is, you could choose to double the radius of planets, and if you want your games to be more arcade-style you could make the planets smaller.

I'm not sure how easy this would be to program though.

Changing stuff like that is exceedingly easy. What's difficult to program is how to not render the entire planet at once.

LOD is determined by distance from the camera as a radius around it, right? We'd need to reduce complexity within a radius of a smaller size is all. Make sure the highest LOD radius in the case of small planets is no more than 1/4 the radius of the planet or so, and we should be fine.

That's the idea. The problem is making it not choppy when it updates.

Atmospheric haze might help, but that's going to be largely dependent on the atmosphere of the planet. I remember playing spore and seeing the terrain far ahead of me bend and warp as I moved, so yeah I'd like to make this as clean as possible. Do you think that it would make sense to do a raytrace from the camera and only show the ground polygons that intersect with a ray?

~sciocont wrote:

roadkillguy wrote:

That's the idea. The problem is making it not choppy when it updates.

Atmospheric haze might help, but that's going to be largely dependent on the atmosphere of the planet. I remember playing spore and seeing the terrain far ahead of me bend and warp as I moved, so yeah I'd like to make this as clean as possible. Do you think that it would make sense to do a raytrace from the camera and only show the ground polygons that intersect with a ray?

That would be the exact source of the choppiness. We cant do that.

Hm. If we can find a way around this, great. If not, I guess it will have to stay a bit choppy. What if we set the point for the rays a meter or so above the camera? Then only a few more polygons would be there and you wouldn't see choppiness because the polygons would snap into existence slightly before you see them. Of course, this would be a slight problem in a cave, as the ceiling might disappear in same points. We could have this apply only to ground polygons.

There could be two raycasts; one from the camera and one from a meter above the camera. That way polygons slightly outside your field of view would render and the ceiling would not disappear.

~sciocont wrote:

Hm. If we can find a way around this, great. If not, I guess it will have to stay a bit choppy. What if we set the point for the rays a meter or so above the camera? Then only a few more polygons would be there and you wouldn't see choppiness because the polygons would snap into existence slightly before you see them. Of course, this would be a slight problem in a cave, as the ceiling might disappear in same points. We could have this apply only to ground polygons.

It appears we're talking about two different forms of choppiness.

You're talking about things popping in and out of view. I have zero intention to care about this yet.

I'm talking about performing a line of sight test on half a million polygons every 1/60th of a second, which will absolutely grind the game to a halt. Sometimes you just have to accept that things will be rendered on top of eachother, because it's slower in the end due to the sheer calculation.

My problem is, coming up with the equation and organizing the quadtrees so that this is accomplished without checking every polygon. Somehow, based on the camera's location, we have to choose which quadtree nodes to expand, and which to collapse. This is what all the other people do.

You must understand this.

roadkillguy wrote:

~sciocont wrote:

Hm. If we can find a way around this, great. If not, I guess it will have to stay a bit choppy. What if we set the point for the rays a meter or so above the camera? Then only a few more polygons would be there and you wouldn't see choppiness because the polygons would snap into existence slightly before you see them. Of course, this would be a slight problem in a cave, as the ceiling might disappear in same points. We could have this apply only to ground polygons.

It appears we're talking about two different forms of choppiness.

You're talking about things popping in and out of view. I have zero intention to care about this yet.

I'm talking about performing a line of sight test on half a million polygons every 1/60th of a second, which will absolutely grind the game to a halt. Sometimes you just have to accept that things will be rendered on top of eachother, because it's slower in the end due to the sheer calculation.

My problem is, coming up with the equation and organizing the quadtrees so that this is accomplished without checking every polygon. Somehow, based on the camera's location, we have to choose which quadtree nodes to expand, and which to collapse. This is what all the other people do.

You must understand this.

Ok, I understand what you mean now. I definitely understand the problem here. Normally, this works by a simple radius test, right?
So for radius of 1, you render at detail level 1, for radius length 2, you render at detail level 2, etc. You'd just have to program in radius length and find some way to assure that there are no artifacts where corners appear, because obviously at some point on the circle you're going to have a square in level 2 that only fits into level one because it can't tessellate properly with others in level 2 because it's half of a unit offset because of the parts where the circle intersects. To remedy this, we could work with squares or other shapes made out of terain tiles that work for all levels because all of their cropping points line up with those of the level below them. If this is confusing, I'll try to make a diagram. However, there's no way that I can think of to avoid the slit artifacts you can see in spore from a long distance away.
Also, let's shot for more like a constant 30fps. There are plenty of great looking games out there that run at 30fps.