a whole galaxy on the iPhone - early preview

an experiment I’m currently doing, completely crazy when I started out, now it seems feasable.

Below you can see a series of screenshots of a (small) galaxy. Every dot is a sun. There are about 80,000 suns in this galaxy, and it takes just 9 draw calls to render. I can zoom, drag and orbit, and it seems to be fluid (not yet staged to the iPhone, so there’s a bit of uncertainty left).

I’m using sprite manager to render the suns, with a bit of tweaking in the generation process because it only handles up to 65000 vertices and I need a lot more than that. :slight_smile:

Next step is to exchange the billboards with something more interesting when the camera gets close, and the addition of a bit of space dust and nebulas.

331041--11651--$bildschirmfoto_2010_06_22_um_235041_439.png
331041--11652--$bildschirmfoto_2010_06_22_um_235158_175.png
331041--11653--$bildschirmfoto_2010_06_22_um_235300_477.png

I’m afraid the poly count is an order of magnitude or two higher than the iPhone can handle at decent framerates. Your computer is about a million times faster than the iDevices (well, quite a lot faster anyway), so editor performance is basically meaningless. Everything needs to be tested on the device, especially for the older models.

–Eric

I don’t know. Pure non-textured polygons is a different story. For example, the PSP and DS can render a few million triangles.

If you managed to get this to work, that would be a HUGE breakthrough for the iPhone.

GL!

very cool, i’ve actually been trying to do something similar. what are your plans for it? release? I’d love to use it (or at least learn from it) if possible.

Thats something I want to see, especially on the DS.

If we assume A4 generation, you can potentially get away with 70k - 80k triangles with a bit of luck, but only if you get rid of all alpha overdraw.

With the overdraw I’m seing there you can be happy if it does not crawl to 0 at 10k already

As such I would highly recommend to test it on the device given its meant to run on the device. Running in simulator but especially unity editor won’t get it anywhere

but generally it looks very cool, if you optimize it for its target platform, it will definitely find some use :slight_smile:

I’m not yet 100% certain about the target, which is why I don’t worry so much.

I would love to have it on the iPhone. That’s why I’m building it in Unity iPhone. But if that doesn’t work out, a webplayer is just as fine in my book. But since you can upgrade a project easily, but not downgrade that easily, I’m building in Unity iPhone and then moving to Unity, not the other way around.

I realized the alpha and triangle count will probably be an issue. So I have a few fallback plans. We’ll see. I need a bit more actual functionality before I make the first test export.

Courtesy of Wiki (Nintendo DS)
Unlike most 3D hardware, it has a set limit on the number of triangles it can render as part of a single scene; the maximum amount is about 6144 vertices, or 2048 triangles per frame. The 3D hardware is designed to render to a single screen at a time, so rendering 3D to both screens is difficult and decreases performance significantly. The DS is generally more limited by its polygon budget than by its pixel fill rate. There are also 512 kilobytes of texture memory, and the maximum texture size is 1024x1024 pixels.

What a piece of shit :slight_smile:

I happened upon this thread like a year after it’s been posted, but I got a real chuckle out of the DS information and comments. I was a DS developer for a few years, shipped out a couple of Need for Speed games. I have to say it was a real piece of shit, no more than 2000 tris on screen at any time…if there were more visible it would literally drop rendering polygons and you get all of these black holes everywhere. Most of our textures were 64x64…we were blessed from heaven to be able to use a 128x128 for something. Imagine being hard locked at 2000 polys per frame…you have a vehicle that’s 250 tris and 4 other AI vehicles…not to mention an entire world. I can’t being to tell you the tricks we did with LODs, culling volumes, fog effects and using a small skydome. One thing they don’t tell you though is…if a quad polygon was planar at export, the DS would literally see it in engine as a single triangle. Needless to say, we planarized the living shit out of everything in Maya, but imagine the joy in creating models, trying to hit about 75% planar geometry around the entire model! It sucks lol. I’m working with the iPhone now, which doesn’t use all of the same tricks…i.e. fog is a killer and no alpha testing on iPhone.

Well… they are still handheld devices. But brighter times are coming soon I think. Android is pushing the limits this year thanks to Tegra and stuff and tablets look like the future and growing in power exponentially.
I think that these dire straits (referral to the rock band is not purely casual) on computational power are going to become a nightmare of the past also on handhelds in about two years.
As a producer I’d completely forget to produce anything with less than than 40000 triangles on visual.

Can you share any more about your experience with the iPhone? Any rule-of-thumb counts or other items. Fog is bad?

This information would be very helpful as we aren’t porting until we have something playable. We ARE keeping things minimal though, we hope.

Cheers,

Fog itself is not bad, but its bad on OpenGL ES 2.0 (when you don’t implement it as a post fx with pixelshaders) or when used on the HD devices (iphone4, 4th gen itouch, ipad) because its VERY fillrate intense and the fillrate is the most limited resource these 3 devices have

It’s that whole 4th gen devices thing…I’m seeing that folks still support 3G and before, but those devices are quickly becoming obsolete due to even newer devices replacing them. Plus it seems like apple themselves lose interest in even supporting theses devices as they get to the end of their lifecycle…that makes sense from a business perspective. Sorry my little rant is over. From my knowledge, yes fog is bad for the above stated reasons. If you have Pro use occlusion culling, if not well Unity does some view frustum culling of it’s own, you can use layers to kinda control the view distance of things too…combine that with a custom made skydome to help hide stuff from view and to help prevent “popping” of assets as they come into scene view. You’ll have to come up with a parenting/rotational type of script for the skydome. You’ll also go from the 6 draw calls to 1 if you use your own. Um, the usual…don’t use alpha test on materials, use alpha blend…has to do with the overdraw or fillrate again (not too sure). Try to atlas textures for objects, get the things that share the same material properties to share the same material (put it as much onto one texture sheet as will fit), this will lower draw calls as the objects don’t need to be drawn more for a different material. Use the static batching options, I believe it’s a little checkbox for any object…just don’t check that tickbox if it’s an animated object. Static batching kind of combine things in the view into a combined object, kind of similar to a combine children script. Some other things. Try to create models with smooth edges, 1 smoothing group in max and smooth edges in maya. Seems hard edges pretty much double vertex counts, because it splits 1 vertex into 2 to get that nice hard edge. You don’t want to be doubling any kind of geometry. Also try and keep your UV island amount low…what I mean is, try to sew as much of the UV shells as you can rather than leaving lots of floating UV shells. This is something like the hard edges issue. There’s a wealth of this info in these forums, so look around for the things I mentioned, so you can get a clearer idea of these things.

Back to the original topic of optimization; currently a group of students from my class are making something similar to this for a web presentation. So the project won’t need to be optimized for a mobile device.

My question for anybody here who is familiar would be, how would you break a galaxy like this up into 9 draw calls without running into a depth sorting issue using Sprite Manager 2?

I’ve been getting several questions regarding this, so I’ve decided to share the script with the community. Yes, it really is just one script. I am using Sprite Manager 1, if you use 2 you might need to change some things, I don’t know.

The setup is simple:

  • Linked Sprite Manager
  • Main Camera
  • Galaxy Object

The Galaxy Object has this script attached:

using UnityEngine;
using System.Collections;
using System.Globalization;
using System.Xml;
using System.IO;


public class LoadGalaxySprites : MonoBehaviour {

	public SpriteManager spriteMan;
	public GameObject Sun;
	public float SunSize = 0.5f;
	private string MapData;
	public string MapURL = "http://your.url";
	
	void Start() {
		StartCoroutine(FetchMapData());
	}
		
	void SetupSystems() {
		XmlDocument doc = new XmlDocument();
		doc.Load(new StringReader(MapData));

		XmlNodeList sys = doc.GetElementsByTagName("system");
		int count = 0;
		SpriteManager SM;
		SM = Instantiate(spriteMan, Vector3.zero, Quaternion.identity) as SpriteManager;
		foreach (XmlNode s in sys) {
			XmlElement data = (XmlElement) s;
			Vector3 position = new Vector3(0f, 0f, 0f);
			if (data.HasAttributes) {
				float x = float.Parse(data.Attributes["x"].InnerText, CultureInfo.InvariantCulture);
				float z = float.Parse(data.Attributes["y"].InnerText, CultureInfo.InvariantCulture);
				float y = float.Parse(data.Attributes["z"].InnerText, CultureInfo.InvariantCulture);
				position = new Vector3(x, y, z);
			}
			GameObject NewSun = Instantiate(Sun, position, Quaternion.identity) as GameObject;
			
			// I can only have 65000 vertices per mesh, so I have to use multiple sprite manager objects, a new one about every 10000 sprites
			if (++count>=10000) {
				count=0;
				SM = Instantiate(spriteMan, Vector3.zero, Quaternion.identity) as SpriteManager;
			}
			SM.AddSprite(NewSun, // The game object to associate the sprite to
										SunSize,		// The width of the sprite
										SunSize,			// The height of the sprite
										0, 			// Left pixel
										63, 		// Bottom pixel
										64, 		// Width in pixels
										64, 		// Height in pixels
										true);		// Billboarded?
		}

	}
	


/*
	WWW interface functions
*/



	IEnumerator FetchMapData() {
		WWW download = new WWW(MapURL);
		Debug.Log("downloading from "+MapURL);
		yield return download;
		if (download.error!=null) {
			Debug.Log("error downloading: "+download.error);
		} else {
			MapData = download.text;
			Debug.Log("level data download succeeded.");
			SetupSystems();
		}
	} 


}

At the MapURL, it expects an XML file with the sun data, which should look like this:

<?xml version="1.0"?>
<galaxy>
<system x="-460.15" y="42.76" z="0.5" />
<system x="-448.63" y="6.56" z="-2.87" />
<system x="-442.75" y="-44.22" z="2.75" />
<system x="-440.29" y="-19.42" z="1.04" />
<system x="-439.72" y="-71.64" z="-0.26" />
...
</galaxy>

And that is really all there is to it. The Sun GameObject that gets instantiated is just an empty game object, its job is to tell SM the position.

As you can see, SM does pretty much all the work for you. If anyone makes something cool with this, please share it as well.

Very cool thank you very much!

Thing is, all those triangles aren’t a big problem if it just sits on the GPU using a VBO. It’s when its moving or being uploaded to the card that it’ll get slow with large poly counts.

It doesn’t seem to be doing all that much in terms of fill rate.

Nice work! By the way, where did you found sun’s coordinates? :slight_smile:

how or what’s the easiest way to populate the xml file? any suggestions would be awesome.