Jump to content
  • Advertisement
Sign in to follow this  
Side Winder

Scaled Model of the Solar System in DirectX

This topic is 4232 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

For someone with no prior knowledge of DirectX, do you think this is a realistic project to complete in a few months? I've been using C++ for about 9 months now and want to move onto a graphical library of some sort.

Share this post


Link to post
Share on other sites
Advertisement
It's impossible to say with such a vague description. Can you give more detail as to what you will be trying to acheive.

Dave

Share this post


Link to post
Share on other sites
Yeah... I want to have all the planets (include Pluto...) and the Sun scaled down with the planets rotating as well as orbiting the Sun. The planets would rotate and orbit at their real-life speed. I want to add textures to each of the planet (nothing facny, but enough to distinguish them). I'd like the orbits to be realistic too but I'm not sure how difficult that is (considering, I think Neptune and Pluto cross at some point??). Erm... Can't really think what else would need to be added.

Share this post


Link to post
Share on other sites
You have to be aware of the scale at which you're going to work. The aphelion of Pluto is about 7 billion kilometers, which already doesn't fit into a common 32-bit number. Increasing the unit size will make you lose the ability to represent smaller objects or velocities, so there is your dilemma. You possibly have to look into some hybrid approach.

BTW Pluto never collides with Neptune. They run in a 2:3 orbital resonance, which means that for every three orbits Neptune completes, Pluto does two. Then the sequence repeats. Oh I love cosmology and Wikipedia :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Prototype
You have to be aware of the scale at which you're going to work. The aphelion of Pluto is about 7 billion kilometers, which already doesn't fit into a common 32-bit number. Increasing the unit size will make you lose the ability to represent smaller objects or velocities, so there is your dilemma.


It's hardly a problem if he's just representing planet-sized objects. Most positions and velocities will use floats, which are more than capable of handling 7 billion.

I'd say this is definitely achievable in a few months. The hardest part is perhaps modelling and texturing the spheres, most of which could probably be done algorithmically if you know how.

Share this post


Link to post
Share on other sites
A scale model of the solar system isn't going to be very interesting. You're not going to be able to have the sun and any of the planets on the screen at the same time. If you gave pluto a 10 pixel diameter, you would have to give the sun a diameter of over 5800 pixels and you would have to separate the sun and pluto by nearly 25,000,000 pixels.

Something more reasonable would have to be the Sun and Mercury. If mercury had a 10 pixel diameter the sun would be 2900 pixels. More reasonable but you still couldn't show the entire thing on a monitor. Especially when you consider that you would have to have 120,000 pixels between the sun and mercury. In order to get the distance between the Sun and Mercury to a scale that you could display on a monitor, lets say 1,500 pixels, the Sun would have to have a 36 pixel diameter which means Mercury would be about 1/10th of a pixel.

Sure you could move between them and change scale, but then whats the point of creating them all to scale to begin with?

Share this post


Link to post
Share on other sites
If he's making some sort of astronomy viewer, then an accurately scaled solar system is perfectly reasonable. Even if it's a game, it's reasonable if he's aiming for 100% accuracy like the old Elite games.

I have to respectfully disagree with Kylotan on a couple points. You said your planets will be "nothing fancy", by which I assume you mean textured spheres. That'll be trivial to do, as there's textures available for most planets. No need for algorithms. Also, a float is not precise enough to accurately store a number in the billions. A float has seven points of precision, while a number in the billions requires 9 or more.

I won't go into details as there's lots of info on this out there, but what you want to do is store planet positions as doubles (or some other suitably high precision type), and always render the scene with the camera at 0,0, and move the universe around the camera. Thus, objects are rendered according to their position relative to the camera rather than their absolute position, eliminating ugly precision loss.

Share this post


Link to post
Share on other sites
Quote:
Original post by gharen2
I have to respectfully disagree with Kylotan on a couple points. You said your planets will be "nothing fancy", by which I assume you mean textured spheres. That'll be trivial to do, as there's textures available for most planets. No need for algorithms. Also, a float is not precise enough to accurately store a number in the billions. A float has seven points of precision, while a number in the billions requires 9 or more.


The texture itself is not the issue, but ensuring you have the right UV values for whichever triangulated sphere approximation you have is a little more complex. Maybe there's already stuff out there he can use, but I didn't want to say there was when I'm not aware of it.

As for float precision, I think it would be fine for pretty much everything except Pluto, but it's worth noting that you don't need to store every value correct to the nearest unit, as long as the errors aren't cumulative. It does get interesting when you calculate relative distances though, so calculating position as a relative value each frame is certainly the way you'd want to go.

Share this post


Link to post
Share on other sites
Ah ok, I misunderstood what you meant by using algorithms to generate the planets. Creating spheres with texture coordinates is no problem, there's lots of examples out there, whether a geodesic sphere or a more standard longitude/latitude one.

I still have to disagree about the float precision: I have a fair bit of experience with that. If your absolute values are in a float, they're going to be inaccurate, which will result in the relative values calculated from them being inaccurate as well. The relative value may be small enough to fit into a float with accuracy, but that's meaningless if it's calculated from inaccurate values. Hmm, hope that makes sense :P

The result will be that your ships/planets/whatever will appear to "vibrate" as they bounce around each frame, as each frame their position is slightly off due to the lack of precision. I learned that the hard way :P

[Edited by - gharen2 on May 17, 2007 12:56:14 PM]

Share this post


Link to post
Share on other sites
Hi guys. Long time member, seldom poster. This sounds like a really fun project and seems nice and simple for first steps into graphics programming.

Just a thought that hit me when reading this (and sort of a software engineering point rather than a coding point): I'd be inclined to keep the simulation of the system as decoupled as possible from the rendering part. This will chunk the project up a bit better into the stuff you have the 9 months' experience with and the new stuff which is probably more likely to give you problems.

Keep us posted on how you go!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!