koobas.hobune.stream
Star Field - Lots Of Poly or Transparent Texture
I am developing a space game which will work on Android and iOS devices.We are tying to target as much as devices as we can.While developing it i have faced a simple problem.I have to make decision but since i couldnt test on many devices i dont have a spesific idea that i can accept as correct way on my own. So what im asking is a little bit explanation about which method from the below could be better and why ?
Scenerio:
There will be a 2d low vert simple plane which contains space texture. I need to add stars with a different y position to have a feeling of depth. (I'm using a perspective camera to have this feeling.They look like they are moving in different speeds due to distance)
1st option : adding a stars texture on top of the space texture with a different plane and alpha blend them.That would cause a lot of fillrate due to lots of transparent areas.
2nd option : I would add little meshes in the shape of stars with very less or no transparent.That would mean a single mesh for each star and a lot of polys/verts.
3rd option : Im glad to hear any option of yours :)
How about a particle system? Build a particle system with roughly about 300-600 motion-less particles at any given time, set the lifetime to long, do something tweaking etc. You can give this a go, it will takes just 5-10 $$anonymous$$utes to setup a prototype.
That sounds quite similar to the mesh approach since it will also create a lot of meshes for particles.I am not sure but how would that give a better performance then the solutions above ? Don't take me wrong,im just trying to find the most optimum way to do this. So if you think particles are more optimum i would like to hear why in more depth if you can clarify ? :)
The particle system will be a single draw call and will handle the batching better than the other automatic options.
$$anonymous$$ind you - any form of transparency is a nightmare on iOS/Droid - so perhaps you'd want to use a non-transparent shader - or build your own "combined" star mesh to mean that your code only needed a single draw call. In terms of shaders:
Do not use a cutout shader on mobile - the fragment discard damages optimisation badly
Perhaps as stars are small transparent won't really mean a lot of overdraw - it depends on the order of the shaders (I guess do the stars first!) and the number of them
So if i understood you correctly you suggesting the second option with a optimized shared,am i correct ?(Btw i will share material and texture so it would be 1 draw call anyways)
Sure - you make a single mesh - but it's going to contain a whole lot of sets of billboards, one for each star (this is what dynamic batching / static batching is doing for you BTW, but it has limits).
BTW this is very similar to the legacy particle system's renderer - which is why I thought that was a good idea!
If the stars are moving then you will update these billboards (quad made of two triangles) each frame, you will certainly want to rotate them to face the opposite direction to the main camera's forward vector).
Off the top of my head the step would be:
Decide on the number of stars - maximum for one mesh would be around 16k
Create a mesh object
Create an array of Vector3s for the vertices
Create an array of Vector2s for the uvs
Create an array of ints for the triangles
Create the initial points (can stick them all at 0,0,0) for now -
map the UVs of the 4 points of each quad.
Create the six triangle entries for each quad referring to the 4 vertices
Update the mesh
From now on you just need to modify the vertices each frame. Keep the vertices array, update it and then set it back into the mesh each frame.
Then you need to move those vertices to the stars position in the game each frame and rotate them so that they face the negative of the Camera.main.transform.forward. Basically a star would have a position but not a rotation, you could store them in a List or a Vector3[].
Now the hard part - make the quad face the camera at the right position. Your meshes renderer would be set at 0,0,0 and you would have set the bounds for the mesh to be really huge so that it always renders.
For each of your stars you would move the position of the vertices. Actually a simple way of doing that is have a dummy object that you:
dummyTransform.forward = -Camera.main.transform.forward;
Before your loop setup a vertexIndex to 0 - then for each star:
dummyTransform.position = startPosition;
And then update the 4 vertices:
points[vertexIndex++] = dummyTransform.TransformPoint(topLeft);
/* Top R 1 */ points[vertexIndex++] = dummyTransform.TransformPoint(topRight);
/* Bot L 2 */ points[vertexIndex++] = dummyTransform.TransformPoint(bottomLeft);
/* Bot R 3 */ points[vertexIndex++] = dummyTransform.TransformPoint(bottomRight);
Where topLeft etc are the forward facing corners of a billboard in local space.
I do that for mobile impostor trees - which are slightly more complex than stars - but a particle system will take a lot of the weight of that for you. If you like the control then write your own - otherwise use a particle system and adjust the particle positions yourself if you want to.
If i understood correctly this would create a very organized,pattern like star field ? But i got your point since we map each star to the meshes there would be $$anonymous$$imal unnecessary transparent pixels which would boost the performance.$$anonymous$$aybe i can work on this idea to create a bit more irregular star field.
This would create a series of stars that you could move independently - perhaps I've missed what you are after?
Hmm ok ok i just understood you wrong.Now its clean when u said "This would create a series of stars that you could move independently".
Well i cant choose your comment as correct answer so if you conver it to an answer i would gladly mark it as answer :)
