Mini Universe?

Requirement:
I want to use pure Java (1.6) with no additional frameworks.

Idea:
Swing? frame, black background.

A universe of a 100 ‘stars’ (to begin with) which can simply show as white pixels for now (ie: no art)

Zoom in and out using mousewheel.

Stars/pixels are selectable via mouse click (perhaps highlight them with some sort of halo/ring, or paint as different colour?)

What sort of structures should I use to:
Hold the spatial data for the stars? (Keeping in mind that I may require ‘clipping’ to represent P.O.V when zoomed in/out unless that can be done another way?)

We need more info than that. :slight_smile:

HeroesGraveDev,
I’m not sure if there’s anymore that I can say really. Let’s say I wanted to map my universe as 5 stars in random locations. A basic 2D, looking down kinda map…

When I’m zoomed out I can see 5 pixels in their corresponding locations, but if I click on one star/pixel and zoom in (using the mousewheel), the distance between my selected star and the others will increase to the point where they will slide out from view, leaving just one star in the panel.

This isn’t a an image zoom, but I can understand why it sounds like one, in that star/pixel doesn’t get bigger…also there is no image.
I guess all I am trying to do is manipulating the actual distances between stars/pixels but I have no idea on what sort of data structure I would use to enable me to do this.

Give your panel a ‘zoom factor’ variable, where a factor of 1 is completely zoomed out, and factors >1 are zoomed in.

When it comes to rendering your stars, calculate their screen position using their x/y pos, the zoom factor, and the position of the centre of the screen. It would look something like this I think:

screenX = (starX - cameraX) * zoomFactor

Where:
screenX - the ‘on screen’ position of the star, in screen/panel coordinates.
starX - the x position of your star in universe coordinates.
cameraX - the x position of the centre of your screen/‘camera’, in universe coordinates.
zoomFactor - the zoom factor as described above.

In theory, as you increase the zoom factor, the screen distance between the stars should increase, but the stars themselves won’t be resized (I think that’s what you are trying to do?). I haven’t tried this, but it should work.

EDIT: You’ll need to somehow link camera panning with the zoom in/out function, so that your camera pans towards the selected star when zooming in, otherwise it too will disappear off-screen.

Hope it helps.
nerb.

Nerb,
Any thoughts on what units I should use to represent distance bewteen stars?

either parsecs or light years seems like a reasonable unit.

I think it will really depend on what you are trying to accomplish.

If you’re trying to create a seemingly realistic model of the universe, then as sproingie has mentioned, light years or parsecs could be a good choice. If you are dealing with very large or very small numbers you will have to be constantly aware of the limitations of computer/binary arithmetic; in particular overflow and floating point accuracy. It may be more pertinent if you are going to model any kind of motion, such as orbits or spacecraft.

If on the other hand it is a ‘fictional’ universe which will be used in a game, then I wouldn’t get too caught up on units at all. Instead I’d be focusing on making it look good & play well, using arbitrary units that ‘fit’ the game and avoid the aforementioned arithmetic problems. For example, you could give the stars x & y positions between 0 - 1024, whatever units that may be. You could then find an appropriate velocity for any moving objects to give the effect you want, i.e. if you wanted fast-paced gameplay, or something more slow-paced.

So in summary, your choice of units should be influenced by the desired outcome.

nerb.

ArrayList

position: x, y, z

Draw at a different radius depending on distance from the camera. To be cool, draw as a line based upon the change in the camera’s position and the star’s position. A la Star Wars.

That’s how I did this:
http://otcsw.com/files/WarpField.swf

The main difference is that you need to do a little bit more geometry since my camera is on a one-dimensional rail.

You could do this easily if you know how 3d projection works.

Data for the stars are in 3d(xyz)
Project to screen when drawing
Zooming would be a simple camera movement on the z-axis.

You could do this easily if you know how 3d projection works.

Data for the stars are in 3d(xyz)
Project to screen when drawing
Zooming would be a simple camera movement on the z-axis.

Im pretty sure that zooming is when you lower the cameras FOV, not moving closer.

Technically speaking, yes – moving the camera closer or further is called “dollying”. We’re not film directors, so around here “zooming” is just a vague term for filling the frame with the subject regardless of how.

Besides, when it comes to stellar scales, you’re not going to want to use the camera alone for changing the scope from star cluster to solar system to planetary system, you’ll want to actually change the models themselves as the level of detail changes. I presume given your scale of 100 stars that you’re making a game, so fake the scales and proportions so they’re actually fun. Take a look at how games like Master Of Orion and Galactic Civilizations do it.

I’m pretty sure it would almost give the same effect.

Sigh…

www.rel.phatcode.net/mytutes/3dtutes/chapter1/chapter1.htm

Yes, but with lowering the fov, you don’t risk the camera getting inside an object.

They’re pretty similar until you start applying depth-of-field effects. Lowering the FOV deepens the depth of field and blurs things outside of the focal plane, putting all the attention on the subject. Dollying just moves you in closer, and objects in front simply move out of frame behind the camera. They’re not interchangeable. While narrowing the FOV in a follow shot is pretty standard to convey a sense of speed, playing around with rapid FOV changes, e.g. “zoomers”, is considered awesomely cheesy.

Again, not that it matters at all if you’re making a galactic 4x type game since you’re not going to want to use the camera to change scales.

Yeah, only you get “fish-eye” in this case.

For this seeing as you may want to expand it in the future use an arraylist its more dynamic.