Another reason for the Ogre backend - this looks ace

charlieg · Post by **charlieg** » Thu Feb 28, 2008 1:47 pm

This guy is implementing the seamless planetary flight that is so desired:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=39254

A merge of this and the ogre backend. I can but dream.

Xit · Post by **Xit** » Thu Feb 28, 2008 1:55 pm

It looks like he's used an opposite approach to Tarzan02 in the thread here, starting with huge ridiculous mountains and leaving the scaling until later... I would guess Tarzan's will be ready a long time before the Ogre backend is completed though?

Post by **safemode** » Thu Feb 28, 2008 7:41 pm

maybe his planet is very small, rather than the mountains very large.

I also think he's overestimating the performance. He's going to have to cut a lot back if he'd doing between 1200 and 700fps for one planet. what happens when you have to do collisions on the surface, out in space, and on the surface of half a dozen other planets in the same system, and ships in orbit firing down at you or bases on the planet's surface being blocked by mountains or such. What happens when the texturing is actually somewhat decent, there is an atmosphere that uses the system's star(s) as the light source and has to shade correctly. Then you're going to have to have real gravity (not just a number) and that changes space and in planet flight . Right now in VS, you can expect to get 150fps easy in 90% of the gameplay. dogfighting brings this down significantly, big battles much more so. I really dont see how this wouldn't cripple gameplay unless we bump it off to another thread and make the min vid card an nvidia 8800 and offload some of the physics to gpu.

bgaskey · Post by **bgaskey** » Thu Feb 28, 2008 9:08 pm

the requirements for vegastrike are about where they should be right now. I can't see this doing anything except multiplying them by 100 or so

while it would be sweet, not that many people have state-of-the-art gaming hardware lying around

on the other hand it would be an excuse to upgrade my video card alot (GeForce 8800 GTS

) and my processor, and my motherboard, and get some new RAM...oh well, may as well buy a new comp

sounds good to me

bgaskey · Post by **bgaskey** » Thu Feb 28, 2008 9:14 pm

Sorry that last post was kinda harsh. It looks like it would be a sweet addition to vegastrike, maybe if it could just model the closest planet to the player and leave other planets like they are now. But that would pose a problem for multiplayer

I can't wait for anything that improves the game tho

Post by **safemode** » Thu Feb 28, 2008 11:27 pm

AI would be able to enter planet atmosphere too... so you'd have to render for all such planets in a system. i dont see this being very feasible without some serious cheating.

Xit · Post by **Xit** » Thu Feb 28, 2008 11:37 pm

Yeah, just the closest planet would do it for me, I dare say at some point we may have other planets accurately simulated, but if we could fake it in the meantime then having a whole planet (or just 1000km at a time) to interact with would open things up so much...

Frontier did pretty well with planets, there were maybe two with reasonable detail at any time and the rest were just dots. We could probably fake the physics of distant planets by just turning them into black boxes with set probabilities, like was suggested for player ships being transported to the current system?

Current requirements do seem about right to me also, I can install the game on any current computer and it'll run fine, but it would be nice to have something to occupy multi core systems, it kinda annoys me that there's not many things worth computing on a quad Opteron system atm...

bgaskey · Post by **bgaskey** » Fri Feb 29, 2008 1:58 am

i say just let the ai dock with planets like is currently possible on planets that aren't the one being accurately and seamlessly rendered. also, if the player is not near a planet (in deep space) you don't have to render any planets. but there could be a configure option to simulate more planets with those with some extra cores (opterons

). I seriously need some new hardware...with more cores...and geforce 8800's

Xit · Post by **Xit** » Fri Feb 29, 2008 3:50 am

Hmmm I was going to say that you shouldn't bother getting more hardware at the moment - as there's not much out there to use it, but then I noticed you have an iMac...

bgaskey · Post by **bgaskey** » Fri Feb 29, 2008 7:13 pm

but then I noticed you have an iMac...

Ouch

but i'm gonna build my own for my next comp, hackintosh style

i want to have a dual core to play with

Tarzan02 · Post by **Tarzan02** » Sat Mar 01, 2008 10:29 pm

my collision detection is based on the reference of the actor (could be a NPC or a PC). The reference is the major body near the actor, if the reference is the same than tne PC => use the detailed mesh (more than 320 triangles) if not => used the root mesh (only 320 triangles to test). My proc is recursive so only the last triangle is tested => very fast. The NPC are only displayed in short distance (based on the view angle). A lot of work to do, if someone is interrrested i can give access to the source (hosted by sourceforge).

Post by **safemode** » Sat Mar 01, 2008 11:41 pm

i'm guessing PC isn't personal computer, so you'll have to explain what that is supposed to indicate.

In any case, I'm not sure i'm a fan of the mesh for collisions for against a given object changing based on the position of the player. What happens when an AI unit is near the surface of the planet, then you go down and all of a sudden the mesh becomes detailed and the ai unit is inside a mountain? or what about when an AI unit is on the surface of a mountain and you leave the planet, now he falls down to the root mesh and dies. Would we be forced to keep bases and such only on the root surface, so these changes to the mesh when the player leaves and comes dont effect it?

Post by **ace123** » Sun Mar 02, 2008 12:38 am

I assume PC means Player character and NPC is Non-player character

In this case it might be appropriate to use the active camera.

Tarzan02 · Post by **Tarzan02** » Sun Mar 02, 2008 9:18 am

PC = Player Craft
NPC = Non Player Craft

I use the active camera to define the LOD of the planet.

I control where to place the actor with it's state, if it is landed on planet => each time i must display it, i verify if its intersection triangle has a child, if it's the case => i must find the new triangle with a recursive procedure (in fact the collision detection of the planet). In the other case, if its triangle must be merged because of the distance / active camera => i've got a problem to solve

To accelerate the procedure all this is done only if the actor must be displayed

Post by **safemode** » Sun Mar 02, 2008 2:02 pm

So for every frame you gain detail, your collision detection moves the npc unit that happened to be on it along with it. And every frame it loses detail you do the same. This would be done whether or not the pc was viewing the unit because if the mesh isn't there to collide with the npc will fall until it does. And if you dont do collision detection when the PC isn't looking, then the NPC will find itself inside meshes and what not.

doing collision detection only when you are looking isn't a very good way to do things. You'll have NCP's doing things behind your back that aren't possible, and that will effect gameplay. Especially if you want NPC's to interact with eachother and not just you.

In VS. You're gonna have to cheat a lot to get the collisions working because in VS the npc characters play with eachother and collisions need to be detected for them even when the PC isn't looking. I can just imagine the entire surface of a planet acting like how we dock ai units now. that idea is not very exciting to me.

I'd be interested to see a benchmark on detecting collisions all the time no matter if the PC is watching against how you currently do it. That should give us a rough idea on the perf hit we'll see introducing this into VS. You can still do the cheating of moving the units around as the detail increases and decreases. PS. What happens to a unit that is flying close to the surface, but not landed when a mountain detail suddenly springs up in front or around him? Does your collision detection detect units that are going to be inside the mesh but aren't currently laying on it ?

Xit · Post by **Xit** » Sun Mar 02, 2008 5:22 pm

Couldn't it be coded so that:

Option 1: Areas around bases will always be rendered in detail good enough for reliable collision detection (bases should be relatively flat anway, right?), and so the geometry of these never changes. This could cause awful artifacting of 'skirted' egdes when we're not looking, but we won't really care since we can't see bad edges at a distance of 98 ls. The bases might look crappy to make them use a low enough poly count but I think that should be doable?

Option 2: Bases are always rended on top of a low LOD terrain patch, and the base model itself has to include any relevant terrain detail to make it look believable. This has problems in stopping the base from appearing to float above the planet, but would render and behae just like a very low orbit starbase.

Then, we get round the high/low LOD areas around ships, by ensuring that AI craft only pass into high LOD areas while the player is looking, but these areas are persistent until that same craft passes back out into a low LOD mesh. This could take a while if a few ships are following each other through the 'sector' but seems doable to me? There shouldn't really be that many high LOD planetary patches at any time, IMO

Post by **safemode** » Sun Mar 02, 2008 6:21 pm

my concerns aren't about rendering appearances. bases wouldn't be visible from space orbit anyway... and likely would be barely visible at the ranges you would have to be for the detail levels to change anyway.

It's not really about how things are rendered when you're not looking or too far away. Stuff that you're not looking at or too far away from aren't rendered at all.

It's about the meshes and the transforms and thus collisions of those meshes. All of that is done, whether or not you're looking at it or too far away. And it has to be done correctly or you get NPC's doing stuff that shouldn't be possible to do, and changing the game significantly.

Tarzan02 · Post by **Tarzan02** » Sun Mar 02, 2008 8:05 pm

Safemode: Completly agree with you, i've made a mistake in my post, the detection collision is done even if the NPC is not visible, the mesh taken in count depends on the reference (the major body) of the actor, each frame i calculate the new reference based on the distance (this can be change in calculate the influence of the body based on its mass for example). Like that, if the reference is the same than the PC, i use the detailed mesh rather than the root mesh, for instance the only way a NPC will fly near the surface of a planet will be to land on a starport (procedure i actually work on), the NPC will fly just over a landing area and then slowly descent. It's a difficult problem to solve.
For NPC flying and a mountain suddenly appeared, it can occur because the mesh will gradually be detailed so when a new triangle is tesselate, i take care of the altitude of the NPC and then adjust with the new triangles generated (each triangle is tesselate in 4 child triangles).

Post by **safemode** » Sun Mar 02, 2008 8:30 pm

NPC units may be waging an attack on a planetary base close to the surface.

Now you decide to join in and descend to the surface where the battle is taking place.

What happens while you do that? The terrain tesselation causes the collider code to adjust the units that happen to be in the way now. The base is firing on units but they're moving, maybe now directly in the path of big turrets from the base.

Xit · Post by **Xit** » Mon Mar 03, 2008 12:43 am

safemode wrote: It's about the meshes and the transforms and thus collisions of those meshes. All of that is done, whether or not you're looking at it or too far away. And it has to be done correctly or you get NPC's doing stuff that shouldn't be possible to do, and changing the game significantly.

My ideas were meant to address this, we seem to be having a lot of misunderstandings lately

I would've thought that rather than adjusting the unit heights around the terrain, the low LOD mesh should just always be larger/higher than the high LOD, so a unit can't get into an area which will be invalid later. Then, because the high LOD would persist until the unit leaves the area, it won't become trapped in the larger, low LOD mesh.

bgaskey · Post by **bgaskey** » Mon Mar 03, 2008 1:18 am

I would've thought that rather than adjusting the unit heights around the terrain, the low LOD mesh should just always be larger/higher than the high LOD, so a unit can't get into an area which will be invalid later. Then, because the high LOD would persist until the unit leaves the area, it won't become trapped in the larger, low LOD mesh.

This actually seems lie an excellent suggestion. Bases on planets could be owned by whoever controls the space around the planet so they do not get attacked/bombarded. Also, AI's could land at a higher docking point if the planet is being rendered using the low LOD mesh.

Xit · Post by **Xit** » Mon Mar 03, 2008 1:31 am

Well my idea really was that the docking points/bases would always be a high(ish) LOD mesh, so they'd always be in the same place, regardless of the overall LOD for the planet, with some intermediate LOD meshes around it, but this would somewhat limit the maximum number of planetary bases, and they'd be purely static - which might be disappointing...

Post by **safemode** » Mon Mar 03, 2008 2:59 am

ok, so the high poly count mesh stays so long as _any_ unit is in it's area if the player's unit had caused the mesh to go high res. That makes a big difference.

It'd be interesting to find out how many high res spots we can support on various planet surfaces in the situation where units dont leave a previous spot on the planet's surface (probably around a base) or perhaps is replaced by another unit before it's able to go low res. This could build up on many of the player's visiting bases before units eventually leave the spot long enough for it to return to low res mode.

If the limit is low, we would have to cheat somewhere. It may not be as big of a bog on the system though since you're not moving ships around as the resolution of the terrain changes.

Xit · Post by **Xit** » Mon Mar 03, 2008 6:43 pm

We really need some info on the number of polys a planet uses at present, and how many extra polys a high LOD chunk and its surrounding intermediates would use, then we might be able to consider it in terms of how many ships/bases/planet meshes we can simulate right now....

We'd need to keep the persistent areas as small as possible too, whilst the above prevents a ship getting trapped in the mesh, it may need to do a course change if a mesh ahead of it converts to low LOD (say if the player has just flown out to the other side of the system)

If such a thing could be arranged then we could equally apply it so that new ships will go round an old persisting area, rather than through (not sure if this kind of cheating would really be noticible, even if one ship is pursuing another through/around the mesh)

2asueekim · Post by **2asueekim** » Tue Jun 03, 2008 8:48 pm

safemode wrote:maybe his planet is very small, rather than the mountains very large.

I also think he's overestimating the performance. He's going to have to cut a lot back if he'd doing between 1200 and 700fps for one planet. what happens when you have to do collisions on the surface, out in space, and on the surface of half a dozen other planets in the same system, and ships in orbit firing down at you or bases on the planet's surface being blocked by mountains or such. What happens when the texturing is actually somewhat decent, there is an atmosphere that uses the system's star(s) as the light source and has to shade correctly. Then you're going to have to have real gravity (not just a number) and that changes space and in planet flight . Right now in VS, you can expect to get 150fps easy in 90% of the gameplay. dogfighting brings this down significantly, big battles much more so. I really dont see how this wouldn't cripple gameplay unless we bump it off to another thread and make the min vid card an nvidia 8800 and offload some of the physics to gpu.

Damn, why do you hate plantary flight so damn much.

The solution is to do what every other game does and ONLY RENDER WHAT IS ON THE SCREEN.

You see you DO NOT render the other planets. If the other plants are far away but you can see them you render a DOT that is the color composite of the planet. If it's closer but still far away you render a texture on a simple sphere, closer then that a more complex sphere (LOD).

It is ONLY when you get close enough that the planet takes up 200% of your view that you switch to more complex meshs/genreration at all.

You keep pooh-poohing the feature that many of us have been asking for for FOUR YEARS.

Please Stop.