He’s not. System.Array.Copy is for built-in .NET arrays, it doesn’t work with the Array class.
Neither, it’s Mono (.NET).
That doesn’t copy an array, it merely makes a reference.
C# and JS (and Boo) all use Mono, so no, it’s not done differently.
I’m not sure what this loop is doing, since it’s using emitters[0] for every iteration. You mean “emitters[e]”? Edit: also, I think you can’t assign individual elements to ParticleEmitter.particles. It’s probably the same as e.g. Mesh.vertices, where you have to assign the entire array at once, you can’t write to individual items directly.
Thanks for the replies guys. Sorry, I should have explained the context. I am using C#. I want to create one large array of particles that contains multiple sets of ParticleEmitter particle arrays, in order to overcome the mesh size limit of 16,250 particles.
First I tried built-in arrays since that’s the best choice, but I couldn’t figure out a built-in way to copy just a subset of the array. So then I tried ArrayList, but I had trouble in one spot trying to cast to Particle, so I gave up on it. Then I tried a List<>, which worked just fine, but it’s a little too slow at 20-25 fps in-editor. Then I found out about Array.Copy, and now I am at Arrays.
Yes, I was originally doing emitters[e], emitters is an array of ParticleEmitter objects. emitters[0].particles is the first ParticleEmitter element, and it is valid to assign an array to its particles, which I was originally trying to do.
But you might have something there, maybe somehow my count is off and I’m not actually assigning every particle? Here’s the real code:
Right now there are two emitters in the array, both maxed out at 16,250 particles. particleIndices[0] is 0, and 1 is 16250. I figured at least the first one would work…
It is unclear to me why you need to place them in a single place. You could reference to each ParticleEmitter separately, but perhaps I do not fully understand your intentions.
If it is necessary to place them together, could a structure help ? http://msdn.microsoft.com/en-us/library/aa288471(v=vs.71).aspx
Thanks! This is a strange attractor calculation. I want to separate the attractors from the particle systems so that I can support multiple systems.
In fact, at first I did keep them separate. But for some reason, when I tried to attach my script to each particle system and have them reference the attractors, I could only get one of the systems to reference the attractors correctly. Frustrated, I decided to have a completely separate manager-style object, and then reference the attractors and the particle emitters. And since I was doing that, I started with an array of arrays, but that wasn’t working very well, so I moved to putting everything all in one.
Eventually, I’d like to have the positions and velocities in a texture using a pixel shader, which means one array. Some day…
My system is completely deterministic, so really I only need to do #1 and #3. The particles don’t know or care about each other, they just move according to the gravity of the attractors.
And I’m only using multiple emitters because I maxed out the first one at 16,250 particles. Otherwise I’d just use one emitter with 30 particles.
Sadly no, baking is out because I want the particles to be fully dynamic, since now I have the ability to move the attractors around in real-time. Although if I was really good at math (I’m not), I could find a way to shortcut the calculation, sort of like how noise optimizations work. Honestly though, the calculation itself isn’t that bad.
Your question did prompt me to use the profiler, and in doing so I found that I was looking up the attractor GameObject position for every particle for every attractor, which is quite expensive. So I just store the positions as Vector3s in an array and grab that, which is much faster.
So now I’m back up to 60fps in-editor with two maxed emitters and 5 attractors. Thanks for the motivation