koobas.hobune.stream
How to create a distant asteroid field?
Hi,
I want to create an asteroid field, which is visible from a distance, what do I use, is there an universal solution for this?
What I currently use: A particle system, which emits asteroids and when I get close they are replaced with actual asteroids. The texture for the particle system renderer is updated constantly using a separate camera, so the asteroids look better. I use the Texture Sheet Animation to simulate multiple asteroids. The problem with this solution is that it takes many draw calls and that there is no way to determine which frame(asteroid) does the particle use from the Texture Sheet Animation, so the Instantiate asteroids look different then the particles.
Can I access the Texture Sheet Animation frame property for a particle?
This is how it currently looks: Before Instantiate: 
After:
I think if I were approaching this problem, I'd want to leverage LOD (pro feature, but you can roll a passable LOD system on your own) and dynamic batching. Your particle idea is a smart one, but it won't give you the clean, seamless, functional results you're seeking.
For your other question, AFAIK, the current frame of a particle can only be discovered by using what I call age management, wherein each specific particle's age is repeatedly clamped to lie within a certain range. It's the only way to manipulate certain shuriken change-over-time modules like sprite animation. By controlling and knowing a particle's age, and by selecting the whole-sheet-over-lifetime option in the sheet animator module, you can know the particle's position on the atlas. This is not ideal for many obvious reasons, but it can be done.
Hi, I wrote my own LOD to change the mesh according to the distance, the problem was with 1500 object it still lowered the frame rate to 10-30. With the particle system I was able to handle 1000-1500 objects with no problem, but then I was unable to seamlessly change to a prefab. Currently I use 6 different textures for 3 asteroids and create a screen capture of them, which I use for the particle system. Is there a way where I can batch the 6 textures to one material to lower the draw calls? (Or it works differently?)
I'm not clear whether your speaking about meshes or particles in the latter half of that comment. If your asteroid mesh archetypes need 3 different textures, you could atlas them and change the uvs on your models accordingly to use only one material for all 3 variants. This will only save you a few draw calls though, assu$$anonymous$$g dynamic batching is working for you. The question doesn't seem to apply to particle systems, since I assume you've already atlas-ed the particle sprites based on your original question.
There isn't a great OOTB way to do what you're trying to accomplish with the distant-particles-are-placeholders thing. You just aren't going to be able to hide the transition into a 3d model unless it's very distant, like, 2% of screen real estate distant.
Even if you get the right model per particle, its orientation will not match a billboard sprite. Then there's getting light and fog to play along, and so on.
I guess if you really nailed the texture-getter and lighting and didn't $$anonymous$$d the orientation inconsistency, you could spawn your asteroid model behind its corresponding particle, then fade out the particle's alpha over time to attempt to hide the transition. You could also avoid the get-the-right-texture problem by using an individual particle system per asteroid archetype and only take a draw call hit relative to the number of variants.
I use a camera which moves with the ship and has a few asteroids as child items, to match the light close to the ship, I was planning to use them as prefabs. Also I use particles, not meshes, the asteroids in-front of the ship rotate invert to the ship and the camera uses the picture of them as texture to the particle system, so the particles do not rotate with the ship.
Thanks for the quick answers, I think I got a few new ideas.
Oh! Now I think I grasp what you're doing. Very interesting idea if I now understand correctly, but it sounds a lot like an uphill battle you might avoid with a different approach.
Leveraging dynamic batching, and optimizing your LOD system and other aspects of drawing and instantiation could win back the milliseconds your particle approach will supposedly save you.
hi, made some progress and begin to use particle systems with mesh-es they look good, and I can handle big enough asteroid fields, but I'm back to my original problem kind of. Does the (pro) LOD change mesh-es for particle systems?
This may be an old thread, but if anyone else is interested in the problem: one easy and realistic way to reduce the problem is to simply make a (realistically) more sparse asteroid field, because in real life I doubt asteroids are clustered as densely as in so many video games and movies (think about it). Simply spawn a smaller number nearby and then have distant billboards with a "foggy" pattern to simulate the more distant parts of the field. In between, have smaller billboards for individual asteroids at mid-distance, then replace them with meshes as you get closer. The latter can all be batched since they use the same material.
