Modeling a planet?
Author
I need some help with the modeling/building of a planet for a game I'm building. Well, more than help to be honest. I don't have a clue.
The game will be played on the surface of the planet and the planet must be spherical like a real planet. It'd be awesome to have something like "Infinity - a quest for earth" have built but that is well beyond me.
If someone could give me some detailed pointers or where to start, what to use, how to do it etc. that'd be great. Once I have an OBJ file (or other format) of a planet I can take it from there.
Any help appreciated. Cheers
How big of a planet do you want to create? What resolution? Even small planets at modest resolutions can easily consume gigabytes of storage (unless you generate them on the fly). How do you want to create the topography? Procedurally or hand-crafted? A planet 1/10th the size of earth would still have ~5,000,000 km^2 of surface area. It looks like you already found "Infinity." You should read his dev journals if you haven't already.
If you check out Sean O'Neils stuff. It's a real good place to start from....
http://sponeil.net/
Also www.vterrain.org
http://sponeil.net/
Also www.vterrain.org
Author
Thanks for the quick responses. It has helped but there's still a couple of things:
Army of Zin -
At the moment the size of the planet doesn't matter (unless it affects the way it is created) and file sizes are not an issue. It will need to be the same planet everytime the game is run so I guess it can't be randomly generated "on the fly".
I'm no sure what you mean by "How do you want to create the topography?", could you explain please? Also I don't know what doing it procedurally means.
My planet will definitely be smaller than earth (ie my avatar:planet size ratio will be smaller than human:earth).
I will have a read of those dev journals and see if it helps.
Scratt -
Sean O'Neils stuff is awesome. Thanks for that link. I'm going to take a look at his source code and see if I can utilise it in anyway (I'm pretty sure it's on a BSD license).
I've looked at vterrain before. Lots of stuff on there, but none of it seemed to help. Maybe I just don't know enough about 3D modelling to make head or tail of it?
Thanks again guys.
Army of Zin -
At the moment the size of the planet doesn't matter (unless it affects the way it is created) and file sizes are not an issue. It will need to be the same planet everytime the game is run so I guess it can't be randomly generated "on the fly".
I'm no sure what you mean by "How do you want to create the topography?", could you explain please? Also I don't know what doing it procedurally means.
My planet will definitely be smaller than earth (ie my avatar:planet size ratio will be smaller than human:earth).
I will have a read of those dev journals and see if it helps.
Scratt -
Sean O'Neils stuff is awesome. Thanks for that link. I'm going to take a look at his source code and see if I can utilise it in anyway (I'm pretty sure it's on a BSD license).
I've looked at vterrain before. Lots of stuff on there, but none of it seemed to help. Maybe I just don't know enough about 3D modelling to make head or tail of it?
Thanks again guys.
Hi
I am currently developing a planet renderer for my 3D engine. You can check out a video at my website.
The planet in my current video is generated procedurally however doesnt increase in detail as the camera gets closer to the planet. This is almost complete and I should have a video soon.
As this is my first attempt at generating planets it is all done on the CPU. I hope to start using the GPU for some of the processing soon.
To generate procedurally means that the entire planet is generated within your program. It is not loaded from a file or resource. My implementation used Fractional Brownian motion to generate 3D noise for the planet. This allows me to have different levels of detail when far away and up close. I can in theory have a planet which has resolution down to 1mm. Storing a planet of this complexity in a file would be HUGE.... not to mention how difficult it would be to load the data for different resolutions. (You obviously dont want to render the planet at 1mm resolution when the camera is 100km away)
When generated procedurally it is still possible to recreate the same planet over and over again. By using the same seed number (Think of this as a unique planet ID) your noise function will produce the same outputs (Random number generators are not truely random. They are pseudo random so it is possible to get the same output). In basic terms (where I am in my development) I dont have much control over the geography of my planet however with with tens of thousands of possibilities its quiet easy to find a nice looking planet, and with more complexity added to my planet generation functionality I will be able more accurately control the finer details.
If you would like to discuss any of the methods I used etc... please feel free to message me.
Ciarán
I am currently developing a planet renderer for my 3D engine. You can check out a video at my website.
The planet in my current video is generated procedurally however doesnt increase in detail as the camera gets closer to the planet. This is almost complete and I should have a video soon.
As this is my first attempt at generating planets it is all done on the CPU. I hope to start using the GPU for some of the processing soon.
To generate procedurally means that the entire planet is generated within your program. It is not loaded from a file or resource. My implementation used Fractional Brownian motion to generate 3D noise for the planet. This allows me to have different levels of detail when far away and up close. I can in theory have a planet which has resolution down to 1mm. Storing a planet of this complexity in a file would be HUGE.... not to mention how difficult it would be to load the data for different resolutions. (You obviously dont want to render the planet at 1mm resolution when the camera is 100km away)
When generated procedurally it is still possible to recreate the same planet over and over again. By using the same seed number (Think of this as a unique planet ID) your noise function will produce the same outputs (Random number generators are not truely random. They are pseudo random so it is possible to get the same output). In basic terms (where I am in my development) I dont have much control over the geography of my planet however with with tens of thousands of possibilities its quiet easy to find a nice looking planet, and with more complexity added to my planet generation functionality I will be able more accurately control the finer details.
If you would like to discuss any of the methods I used etc... please feel free to message me.
Ciarán
Author
Thank you so much Ciarán. That is the most useful piece of information on this topic I have seen on the whole internet. If anyone can beat that I will be surprised.
I will definitely take a look at your stuff and will probably end up messaging you asking more questions. It should give me an idea of where to start too (I hope).
Did you code yours from scratch them? And is there anyway to edit a procedural terrain/planet once it has been generated? Also, what languages/packages do you work in?
I will definitely take a look at your stuff and will probably end up messaging you asking more questions. It should give me an idea of where to start too (I hope).
Did you code yours from scratch them? And is there anyway to edit a procedural terrain/planet once it has been generated? Also, what languages/packages do you work in?
Boweevil,
Giant pretty much answered your questions. Procedural generation just means that you use an analytical function(s) to define the terrain elevation. Usually it's based on functions that are driven by pseudo random numbers (e.g. Musgrave's ridged-multifractal function). It's also repeatable as long as you use the same seed(s).
Infinity's engine is the best I've ever seen for huge, multiscale, adaptive LOD, planetary rendering.
-Zin
Giant pretty much answered your questions. Procedural generation just means that you use an analytical function(s) to define the terrain elevation. Usually it's based on functions that are driven by pseudo random numbers (e.g. Musgrave's ridged-multifractal function). It's also repeatable as long as you use the same seed(s).
Infinity's engine is the best I've ever seen for huge, multiscale, adaptive LOD, planetary rendering.
-Zin
Hi Boweevil
I have multiple versions of my engine. When I started I didnt really have an end goal. It was a learning and fun experience so I have tried many platforms and technologies.
My main engine is in C++ and OpenGL. I have built this for Windows and Linux (Ubuntu). I also have a C# version of my engine running under windows however this is only about 80% up to date.
Even though I started with OpenGL I always knew I wanted DX as well (Before this project I had no OpenGL experience. All was DX) therefore I have implemented a good Graphics Abstraction Layer. When I reach a milestone (yet to be defined) I am going to rewrite the GAL allowing my engine to work with DX/XNA/OpenGL etc....
Everything in my engine has been coded from scratch by myself. Take a look on my website or search for "Decade Engine" on youtube for a selection of videos showing the basic features. In the early days I followed some online tutorials showing how to render a terrain etc.. With limited information available on planets I have implemented this myself based on what I have learned previously.
I am unsure about editing procedural planets. If I am at point A and move to point B which is a distance away, the data at point A may be deleted from memory. When I go back to point A the data is generated again on the fly. This will prevent the persistance of any editing you do to your planet. One of my indevelopment features is that when a part of the planet is out of range and to be deleted, it can be saved to a temp file on disk with this file being loaded if this area of the planet is revisited rather than it being generated agian. It would be possible for you to do this for any part of the terrain that is edited during game play.
If you require a planet to be edited from the very beginning this approach could also be used with the edited planet patches being supplied in heighmap files that are loaded when that patch is needed instead of generated. Depending on the level of modification this may become a problem as the data becomes large.
I will be happy to try and answer any questions that you have.
I have multiple versions of my engine. When I started I didnt really have an end goal. It was a learning and fun experience so I have tried many platforms and technologies.
My main engine is in C++ and OpenGL. I have built this for Windows and Linux (Ubuntu). I also have a C# version of my engine running under windows however this is only about 80% up to date.
Even though I started with OpenGL I always knew I wanted DX as well (Before this project I had no OpenGL experience. All was DX) therefore I have implemented a good Graphics Abstraction Layer. When I reach a milestone (yet to be defined) I am going to rewrite the GAL allowing my engine to work with DX/XNA/OpenGL etc....
Everything in my engine has been coded from scratch by myself. Take a look on my website or search for "Decade Engine" on youtube for a selection of videos showing the basic features. In the early days I followed some online tutorials showing how to render a terrain etc.. With limited information available on planets I have implemented this myself based on what I have learned previously.
I am unsure about editing procedural planets. If I am at point A and move to point B which is a distance away, the data at point A may be deleted from memory. When I go back to point A the data is generated again on the fly. This will prevent the persistance of any editing you do to your planet. One of my indevelopment features is that when a part of the planet is out of range and to be deleted, it can be saved to a temp file on disk with this file being loaded if this area of the planet is revisited rather than it being generated agian. It would be possible for you to do this for any part of the terrain that is edited during game play.
If you require a planet to be edited from the very beginning this approach could also be used with the edited planet patches being supplied in heighmap files that are loaded when that patch is needed instead of generated. Depending on the level of modification this may become a problem as the data becomes large.
I will be happy to try and answer any questions that you have.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
