[mjn.mixael]

Now, the point you raise about animations is a good one, but even that can be done with a few tricks as part of a skybox.

What tricks? I know we could use EFFs as the skybox map or even for just a single part of the map.. but at the scales planets are usually done with skyboxes, nearly the entire skybox map would need to be an EFF which wouldn't work out well performance wise. Is there another way I hadn't thought of?

[The E]

Well, skyboxes _can_ have rotating submodels. You could, for example, have a few planets as part of the skybox, at an apparent distance from the player where you do not need enourmous textures to make things look good.

You can also use transparent texture layers in front of a skybox object to simulate stuff like cloud layers; X3 uses such a technique.

[Nighteyes]

Has anyone thought of the option of having the skybox an actual model of sorts? meaning when you fly inside it you move closer to the box sides
think really big sizes so it would barely be noticable, think that its possible to put the planets on modelled planes inside the skybox, so you would get closer to the planet but not to the starfield that is much further away.

and of course limit the map size so the player can never fly into any parts of thie skybox model

[Thaeris]

You know, I have to disagree with that.

I am admittedly perhaps the only person I've encountered that enjoyed modeled planets in Cardinal Spear (FS1/FS Port campaign). And furthermore, I will explain why:

Moving in simulated time and space, it is easy to rationalize that your relative position with respect to another large celestial body might be quite minimal. And skyboxes are certainly prettier than a modeled planet in FSO. BUT, the truth is, in fact, that you are indeed moving. Cardinal Spear made you feel much less lethargic when flying about in your very slow high-powered starfighter by, even though the sizes of the planets were not to scale, ensuring that everything you moved in relation to changed its apparent size and position. Of course, this was only possible because the planets were modeled!

The end result is this - until someone figures out how to make modeled planets look really good in FSO, people will argue against them as they are not as pretty and will possibly break that sense of precieved realism to some. Alternately, they add a depth of realism that skyboxes do not have, as now the environment in which the player exists is also now dynamic. Personally, I think the sense of motion that modeled planets can deliver to the player makes them well worth the effort if the missions in which they exist are properly designed, and the scales of the planets are properly managed.

At standard FS2 speeds, planets are far too large to successfully navigate around.
At standard FS2 scales, realistic planets will need to use several very high-resolution textures in order to look good.
Without additional code support, you will still be able to ram the planet and bounce off it.
At the sizes you would have to use in order to make a planet realistic, you would pretty soon run into floating point inaccuracy issues.

Now, the point you raise about animations is a good one, but even that can be done with a few tricks as part of a skybox.

It was either StarLancer or FreeLancer that showed everything that can be done wrong when planets are actual 3D models.

I should note that to every program that did something well or not, there has or will be a counter-example. In the case of Freelancer or Starlancer, well, that was an older game with reduced capabilities as compared to now. I should note that in vanilla FS, or FS2, things just look terrible. In fact, I would argue that many, many games of the late 90's or early 2000's which rely on texture maps for detail often look really bad from a combination of poorly-made, low-poly models and low resolution textures. Under those constraints, it's really hard to make a good looking curved shape with a lot of detail. I'd also theorize that it's where the majority of box ships came from, where artists were trying to make the best of design whilst limited by hardware (looking at YOU, Wing Commander...). In any sense, modeled planets are not a bad option for every program under the sun, but probably more so FSO.

If one tries to make modeled planets in FSO, however, I'd again point to Cardinal Spear for a job well done. And you're right, vanilla FSO speeds are ludicrously low, and far too low for inter- or intrasteller navigation. Your comment on textures is probably also very much valid. In fact, every point you've made is vaild. And so, why might I still argue or promote my views?

First, I do not think the average user ever bothers to think about how fast they're actually going, or that FS is probably the slowest space sim/arcade sim out there (or at least the slowest I've ever seen). But they do think they should be going fast, and Cardinal spear did that with visual trickery. Planets were not full-size. They were not at a realistic range from the player. Rather, they were positioned and proportioned such that they made the player feel like they were at least moving in relation to the planet, and were placed at a range such that the player was unlikely to collide with them. Mission design, not models alone, pulled the effect off. As unto the speed argument, that has itself been argued enough, and is not needed in here.

As for appearance... I have to wonder... is the draw order (with respect to model transparencies), which FSO is capable of delivering, enough such that you could put an atmospheric submodel on a planet, and not have any transparency problems? I think the only downside it that you'd only (as of this time) be able to draw one atmospheric layer...

[deathfun]

Forget making planets
Make a deathstar

[Nyctaeus]

Molaris, check WCS Final. They are a lot of awesome planets here, both skyboxes and standard "background" planets.

[Nuke]

the biggest sphere i managed to get in game was tethys. and you have to orbit close in to avoid ****ing up the float maths (you get some wobble otherwise). mimas is a little bit smaller, and actually works better. large planets, earth for example, are better off being flat.

i was kinda looking into what we would need to create a tiled terrain system. each tile would have a large number of lods. lod is based on distance so that tiles far away will be a low detail level, and ones that you are on top of will have a high lod. the idea is that a large number of tiles can make planet size surface. freespace sorta lets us do that within some limits. you can use detail boxed subobjects stacked as lod chains, so long as xtiles*ytiles*((lods*2)-1)+1 is less than whatever subobject limit is in place.

the +1 is there to represent the hull object, which can either be a dummy. or a plane used to hide the edges (this is what id do) the *((lods*2)-1) is there (instead of just *lods) because for every lod (except the last in the chain) you need a dummy object. if its inside radius x then the geometry for that lod is used, if its outside then the dummy geometry is used (it doesnt get rendered), but its chidren represent the next lod. this is because of detail box implementation only allows an object to be rendered if its inside a radius/box, or outside a radius/box, not both. i want to see if its between radius x and radius y, and if so render it, but as far as i know this isnt in the engine. having to use heirarcy also limits you to about 4 lods, because of instance depth limit. probibly need a minor engine tweak to make the equation xtiles*ytiles*lods+1, or if you perfer, implement detail distances on a sobobject by subobject basis, which will make the setup simpler (linking instead of sobj props).

this is with current engine tech though. it would probibly be better to generate the geometry from textures in real time, using something like a geometry shader. thus mesh density is dynamic with proximity to the camera. you could also sphereize the terrain with altitude to make it possible to go surface to orbit in a realistic looking way. of course increasing the useful size of the play area is a different matter entirely.

[Rodo]

Is it possible to use a submodel inside the skybox and set it's texture to be an eff format file, so that we can get an animated planet or something like that?

I know it's possible to have something like that done, BtRL had it on the asteroid mission but after checking it I don't seem to understand how the hole texture works on that submodel.

[Snail]

Wasn't it something about rotating submodels? I recall Kara saying something along those lines.

[Angelus]

BtRL used a model made of 4 rings, three of them where to set up to rotate, each at a different speed, while the 4th was static.

While it would be possible to use an eff on such a model, it's not adviseable.
If you have high rez textures you kill performance, if you put low rez textures on it, it looks less then decent.

I've been experimenting with an "active" skybox for a while ( not so much with planets though), and effs are only useful in situations were a small area/ object needs to be animated.

[Rodo]

So my little plan comes down like a pile of stacked dominoes.

[Antares]

Didn't Dark used to make planets? Ross 128 has one which uses a Ulysses as a placeholder.

[Nuke]

should point out could could also do terrain tiles on a sphere. though there are some complexities with texture mapping. if your sphere is composed of a longitude-latitude grid with a capped top and bottom, some tiles are non-square and texturing those becomes problematic as there is always warping. one thing they did in games like ksp was to construct a sphere from a subdivided cube that had been sphereized. this allows you to keep your tiles square and can map directly to textures without wasting space. i did some tests with this idea in max, and while there is still some warping it should work somewhat better.

some of what i looked into was converting real planets from nasa sources (height maps, and detailed photographic maps, captured by space probes). of course a lot of these maps are in the longitude-latitude grid format, usually with flat polar maps. while its very easy to apply these maps to an object in max, it causes some problems when subdividing the terrain into tiles. if i used the spherized cube, id probibly have to do bitmap transforms to convert between the two sphere styles. given high resolution sources (which are available) and some utilities i might be able to make a set of bitmap (height and texture) tiles for an entire planet. you then just need a series of progressively higher resolution spheres. tiles for each will be displaced and textured by their respective maps, and then detached from the spheres to create an lod set. aggressive loding is mandatory, you might have millions of polies in total, but the trick is to only make a few thousand of them visible at any time.

now the real issue is that freespace, as far as i know, likes to preload everything when a mission starts. but because of the large number of high res textures that are required it becomes necessary to page in textures from system ram to video ram as needed. you certainly dont need the high res bitmaps for the other side of the plannet, and you can page in the lower mip levels as it comes around to your side (dds textures are setup for that kinda thing, a simple load time tweak of the header and ommitting data for high mips are all thats neccisary) as they get closer and their lod gets higher, you now need to page in the higher mip levels. of course freespace doesnt do any of this and its likely not going to be done.

doesn't really invalidate the idea though, it just means were limited in the number of tiles and the resolution of the textures. but the planets still rotate and move in relation to you and you can approach them and they will look ok until your close to hitting the dirt. setup is probibly gonna be a ***** though. probibly will require the creation of some tools to do the bitmap transforms, converting source maps into tiles. it will require a new feature in the engine. a 'detail shell' feature (like detail sphere, but detail object is visible if its between radius a and radius b and not visible otherwise). but there are probibly better ways to go about it.

[qwadtep]

Not to mention that you can make a modelled planet rotate. Even a very very slow rotation rate would greatly help in making the planet look real instead of just a static bitmap.

The Solar System's fastest rotating planet, Jupiter, takes 10 hours to complete a rotation. That's six degrees over the course of a typical ten-minute FS2 mission. This much. If your players are able to notice that, they probably need more Shivans shooting at them.

[Thaeris]

"Living" planets are more interesting in this regard. I'm not sure how many layers of transparency FSO can do right now, and draw them properly (I know this is an issue for some of Diaspora's ships), but an atmospheric layer which is animated AND rotates might be very cool indeed.

[Legate Damar]

The only reason to use an actual model of a planet instead of a background is if you want to blow it up in the mission.

I am going to have a planet exploding in my campaign, but I plan to do it as a cutscene.

[Killer Whale]

http://qntm.org/destroy
Better be subspace like sath-fleet; not conventional weaponry. Of course rule of cool and humour, but personally I can't stand casual planet destruction, just saying.

[Legate Damar]

It will be done by an SPd Vinaashak

[qwadtep]

Atmospheres suffer the same problem as planetary rotation, which is that even though they're really impressive to watch they also aren't fast-moving enough to be noticeable over the course of a mission. The two exceptions are the auroras and the illumination of clouds by lightning, which would make for an absolutely stunning low-orbit mission, but I don't know if the FSO engine as it is could really pull it off.

Of course, shockwaves from orbital bombardments would look pretty cool.

http://qntm.org/destroy
Better be subspace like sath-fleet; not conventional weaponry. Of course rule of cool and humour, but personally I can't stand casual planet destruction, just saying.

Also consider Atomic Rockets' Boom Table.

[Nuke]

Not to mention that you can make a modelled planet rotate. Even a very very slow rotation rate would greatly help in making the planet look real instead of just a static bitmap.

The Solar System's fastest rotating planet, Jupiter, takes 10 hours to complete a rotation. That's six degrees over the course of a typical ten-minute FS2 mission. This much. If your players are able to notice that, they probably need more Shivans shooting at them.

of course from the frame of reference of an object at orbital velocity (specifically velocities for low orbits), planets rotate pretty quickly.

to create the illusion of a rotating planet, you could take a smallish sphere textured to look like a planet, rotate it, and use perspective tricks to make it look planet size and render it as part of the background.