How to set up particle array, I specified conditions?

Apr 16, 2009 at 9:45 AM
Edited Apr 16, 2009 at 9:47 AM
snow.particles

<particle name="snow" blend="alpha" texture="flake.png">
<logic>
<once>
........
</once>
<frame>
.........
<if_less arg0="position.y" arg1="0">  
 -------------->><if_less arg0="position.y" arg1="myPosition[i].y">
<if_less arg0="position.x" arg1="myPosition[i].x">
<set target="velocity.x" arg0="0"/>
<set target="velocity.y" arg0="0"/>
<set target="velocity.z" arg0="0"/>

<div target="local0" arg0="age" arg1="life"/>
<sub target="alpha" arg0="1" arg1="local0"/>
</if_less>

....
</frame>
</logic>
</particle>

I want this arg1="0" conditions ,I changed to the specified  arg1="myPosition[i].y", for example, 

vector3 [] myPosition = new vector3 [4]; 
position [0] = new vector3 (1,1,1); 
position [1] = new vector3 (2,2,2);
position [2] = new vector3 (3,3,3); 
position [3] = new vector3 (4,4,4);


But also how to set up a for loop?
 if_less arg0="position.x" arg1="myPosition[i].x"
 if_less arg0="position.y" arg1="myPosition[i].y"
 if_less arg0="position.z" arg1="myPosition[i].y"
Coordinator
Apr 16, 2009 at 10:45 AM
The particle system exposes 16 global variables you can set. These values are named global0 to global15. You currently cannot index them as an array.
Apr 16, 2009 at 12:42 PM
How can snow, fall on the ground have their ups and downs of it?
Apr 16, 2009 at 2:27 PM
Edited Apr 16, 2009 at 3:13 PM

I am sorry, my bad English

..................
        ↓
    snow

..................
------------- 0
GroundPlane

<if_less arg0="position.y" arg1="0">
<set target="velocity.x" arg0="0"/>
<set target="velocity.y" arg0="0"/>
<set target="velocity.z" arg0="0"/>

........................
          ↓
      snow

         .......
........         .........
____/ ̄ ̄\_____ 0
Irregular plane

<if_less arg0="position.y" arg1="?????">
<set target="velocity.x" arg0="0"/>
<set target="velocity.y" arg0="0"/>
<set target="velocity.z" arg0="0"/>

Coordinator
Apr 16, 2009 at 11:19 PM
That sort of effect is currently beyond the scope of what the particle system supports. Simply because it would be very hard to implement efficiently (especially because the particle system must be able to run on both the CPU and GPU).
I'm considering what can be done to support such effects, but I don't see it as a particularly important feature and is a low priority.
Apr 17, 2009 at 8:26 AM
Just to complete the thought cycle, this job is perfectly suited to a particle dynamics module.  By keeping physical simulation separate from particle rendering, you'll be able to develop the motion without requiring confusing changes to the particle system renderer.

Physics middleware solutions offer particle dynamics features, which are well-suited to this task.  The ideal program flow is usually something like this:
- create a batch of particles and set the environment parameters (geometry, external forces)
- ** run physical simulation, which moves the particles
- get the particle state vector from the physical simulation
- draw the particle state vector in a batch (using the xen particle system or drawprimitives)
- repeat **

Coordinator
Apr 17, 2009 at 9:52 PM
While I think I understand what you are saying, I hope you'll understand that I think it's well outside the scope of what the system is currently trying to do. It would also be a question of what users would take advantage of such a system, let alone understand how it worked. It's the sort of thing that's very game specific.
Apr 18, 2009 at 1:32 AM
@yty

Read this article: http://www.ziggyware.com/readarticle.php?article_id=127&rowstart=3
You will not be able to use Xen to do that but if all you want is snow then you might as well just implement what they have in that tutorial.

@StatusUnknow

You really should consider adding a shader level physics/simulation engine for the particle system. You're already storing position and velocity data in textures on the GPU so why not allow the user to call custom pixel shaders which update the position textures? Is there some Xen limitation that would make this difficult? That way yty could store a bump map texture on the GPU and check for collisions in a custom shader...

off topic: It might be time to look for team members, you have done some truley amazing things so far but a one man team can only push so far. I totally understand that its not easy to find people who know what they are doing though. Maybe you could talk to some of the high profile XNA contributers on the xna forums? Oh and have you worked on any other projects in the past? =)
Apr 18, 2009 at 1:36 AM
Oh yea I definitely understand.  The implication was for yty-- use a physics api (not xen!) for moving the particles, xen for drawing them.  Much less pulling out hair that way. ;)

Coordinator
Apr 18, 2009 at 3:26 AM
Edited Apr 18, 2009 at 3:27 AM

To arriu,

The trouble is that whatever is implemented ideally needs to work on the CPU processor as well. If I went down the road of allowing gpu only script in the particle system, then it's getting to the point where you might as well just write a custom system from scratch.
I've said in the past, ParticleSystem is just a class to generate data. The better option may simply be opening up the Particle Drawer's a bit, so other classes can more easily use them.
I'm not saying it's a bad idea, I'm just saying right now I don't see it as being a high priority. The system is already very complex, and there is always a tipping point between effort-reward.

As a personal viewpoint, I seriously doubt the majority of players would care if falling snow actually 'realistically' hits the ground.. And fades out. Feel free to disagree, but considering the effort involved, the technical challenges and overhead, is it really worth it? Would they even notice it in the first place? (Or would they just notice where it goes wrong and you get snow hovering in midair..) Wouldn't they prefer the game be a bit more fun? :-)

As for contributions. I'm quite willing to accept contributions.
Many people send in bug fixes and other little tweaks. And of course, anyone is free to rip the code apart and do what they will with it.
I've only had two people ask to become part of the team, one was very early on and I didn't feel his views matched my own. The other guy I didn't reject outright, but he wasn't all that happy with my answer. You can read my reply to him here: http://xen.codeplex.com/Thread/View.aspx?ThreadId=50882 (This also should give an insight to my thoughts on the project).

It's best to consider Xen as two projects. One, the core library, is something I'll be making few changes to and keeping quite a tight grip over. Ex, on the other hand, is 'extensions / experiments' where things are a bit more free. I'd be happy to accept additions into Ex provided I felt they would be useful for a large number of people, and I'd also be happy for, say, Xen.Community, or something similar.
Heck, I'm perfectly happy for someone to create their own offshoot of the entire project on codeplex.
There are people making cool things with xen, and I'm really keen to see how they turn out. There are people using parts of it in commercial apps, a user recently contacted me to say he'll be making a particle system editor and who knows what crazy things Garbled is doing :-) Would I integrate these things? If they fit and were a benefit to users, yes. Of course I would.

> Oh and have you worked on any other projects in the past? =)

Yes. During the day I'm a professional game programmer, so that counts. I've also been involved with a number of community projects such as Half-Life mods, in various roles, from mapping to project management. So I feel I have a pretty good handle on how things are going, and I also have experience of how things can go wrong with community projects.

Hope that clears some things up.
Cheers.

Apr 18, 2009 at 5:41 AM
> The trouble is that whatever is implemented ideally needs to work on the CPU processor as well.

I agree with you on that. Its pretty great that you have kept CPU and GPU code seamless so far.

> The better option may simply be opening up the Particle Drawer's a bit, so other classes can more easily use them.

This sounds like a good idea. Looking at the code, it might be a lot of work but I believe it could be useful.
Would it be possible to open up the billboard/velocity billboard classes such that they can be used without a particle system?

> Yes. During the day I'm a professional game programmer, so that counts. I've also been involved with a number of community projects such as Half-Life mods, in various roles, from mapping to project management. So I feel I have a pretty good handle on how things are going, and I also have experience of how things can go wrong with community projects.

Who do you develop for? Has your team released anything yet? Are any of your mods successful? I know success is relative lol but I'd love to check them out.
Apr 18, 2009 at 5:18 PM
Edited Apr 18, 2009 at 5:30 PM
Why particle system must be able to run this cpu and gpu? 

Are you saying that we should add a nvdia phyx physics engine to do this effect is better? 

Arriu ,very grateful to the provision of the article, I will learn it. 

I want to do is a role to play in the snow in the fall when people stop exercising, or irregular particles into the region on a campaign stop, and the region has been the dynamic changes. Heightmaps approach to the use and detection of particles should be done and can not be achieved.
Coordinator
Apr 18, 2009 at 10:16 PM

When you use a xen particle system, it will process the particles partly on the CPU, and partly on the GPU (on supporting systems).

So, any of the <logic> you write will run as a GPU shader on the xbox 360 and on PCs supporting shader model 3, vertex texture fetch, and the texture formats used. On PCs that don't support those, the particle logic code is run on the CPU as .net code.
Further, all <emitter> code and particle creation/deletion is run on the CPU.

The GPU is significantly more efficient at processing particle behaviour, especially on the xbox (which does not support the CPU processor). It's also much more efficient to draw the particles, as position / size / .. data is already on the gpu and doesn't need to be transferred every frame.

Apr 21, 2009 at 7:52 AM
"Are you saying that we should add a nvdia phyx physics engine to do this effect is better?"

That depends on your requirements; you could also just write your own function or shader kernel.  If you're not currently using physics middleware, then please research carefully before making a decision.  There are architectural and deployment restrictions to be aware of.

In any case I wouldn't throw the baby out with the bathwater.. there is a middle ground to this.  The xen particle system is a powerful tool for rendering procedural effects, so in my day to day I would personally use it to beautify the appearance of coarse physical systems, not expect it to run my simulations.