Using a tutorial of Allan Mckay’s I was able to link some mesh objects to PFlow particles by way of position. I however, have been less successful at linking the meshes to the particles by way of their rotation as well. The basic position link script is:
count = pCont.NumParticles() Global ViewCone = $Pyramid* as array if currenttime >= 0 then ViewCone.position = [0,0,0] for i in 1 to count do ( pCont.particleIndex = i ViewCone[i].position = pCont.particleposition )
I tried to add something like
ViewCone[i].orientation = pCont.particleorientation
; but that didn’t work. I’m not sure how to do it, or if i’ve been wrong due to syntax error etc. Can anybody help me out?
[thread=222839]This[/thread] might help i suppose… it will let you place objects to particles, even orient them. although the method done there may not exactly do what you want to achieve, but i guess the idea is there… the scripts are based from Bobo’s pflow fragments tutorial.
i hope this helps
by the way, i wasnt able to get the banking to work… i posted in the pflow thread the other day that id try and test it out… its harder than i thought… nay i have insufficient mathematics background… especialy in the fields algebra… coz i was left with the problem of getting the angles of each particle changing based on thier direction…
wait… i remember somthing, i asked something similar somewhere in the orbaz forums (www.orbaz.com/forums) about particle rotations… i think the thread title was “particle orientation” under Scripting Pflow…
(i cant check it now coz i cont open another IE window… im doing a render preview on opengl) heheh:)
I would suggest (as shown in my fragments tutorial mentioned in the thread – http://www.scriptspot.com/bobo/mxs5/pflow/pflow__Chunks_Basics.htm ) to use the transformation matrix of the particle (pCont.particleTM) and assign to the .transform property of the object.
Also, don’t forget to enable the respective channel (pCont.useTM = true) in the ChannelsUsed handler to make it available in the Proceed handler!
Fantastic, guys.
ViewCone[i].transform = pCont.particleTM
worked.
While I have you guys here, I have another question. These “viewcones” represent the “view area” of the ships chasing after each other in my pflow-driven space battle. I’m trying to create something in that so long as enemy ship is “inside” the viewcone of the good ship, the good ship will fire at the enemy ship (or at least fire anyway). Can you guys think of any way to best approach this. I figured collisions would work but whats to keep them firing and stop firing so long as the enemy ship is inside the viewcone of the good ship… Thanks for the help.
A possible approach:
Take the good ship’s transformation matrix. Set its row4 property (translation) to [0,0,0]. Assuming that the ship is moving (looking and shooting) along its Z axis, take the vector [0,0,1] and multiply it by that matrix. The result is a normal vector with origin at [0,0,0] and orientation parallel to the direction of the ship’s shooting direction. Now take the position of the possible target (bad ship), subtract the position of the good ship from it and normalize the resulting vector. Calculate the ACOS of the DOT product of these two vectors – this gives you the angle between the two vectors.
Compare the resulting angle with some threshold, for example 15 degrees. If it is equal or less, the bad ship is inside a view cone with angle of 30 degrees relatively to the looking direction! In this case, do what is necessary to shoot, for example give birth to new particles, or send the good ship to an event where it shoots, or whatever.
Hope this helps!
Cheers,
Bobo
Oy, well, it sounds like it work work, in theory, however I have no idea how to do that in MAXscript since i’m just learning it now. It makes sense from a mathematical standpoint, but I don’t know how to translate that to a scripting standpoint… Any help on your free time would be appreciated!
Here is a little demo scene implementing an auto-running Asteroids game.
http://www.scriptspot.com/bobo/mxs5/pflow/PF_Asteroids_demo_max7.zip
(The file is from Max 7, will not run in 6 and 5, sorry)
It features a single ship which moves between 3 waypoints using Find target operators. A script operator constantly writes the current ship TM to a global variable (used to communicate with other particle systems in this case).
A second PF_Source generates 10 asteroids and the bullets (although the bullets could be separated as a 3rd PF_Source if desired). A script operator writes the TMs of all asteroids to a global variable as array.
The bullets use a Script Test to detect when the ship is within a threshold angle relatively to one or more of the asteroids using the two global variables containing the ship’s and the asteroids’ TMs and gives birth to a new particle if the ship should fire. The max. number of bullets is limited – when bullets have died of Age, the ship can fire again.
A scripted test in the bullets event check each bullet relatively to the positions of known asteroids (taken from that global array). It first initializes another global array with false values for each asteroid, then sets true for those asteroids that have been hit based on a distance threshold.
Another scripted test in the asteroids event reads that global array and spawns new smaller asteroids when the corresponding value is true, killing the original asteroid.
Yet another scripted test sends asteroids to a delete event if they become smaller than a certain threshold.
The only thing that is not implemented is collision between the ship and the rocks, but it would be trivial using the same method used for the bullets. And of course, there is not flying saucer yet…
The scene is set up in 2D (XY plane), but it can be changed to 3D by increasing the height of the Asteroids’ PF_Source Icon, and by moving the 3 green Waypoints (small geospheres) to different heights to make the ship move in space instead of just in a plane…
You can change the number of asteroids, the number of bullets, the thresholds etc.
Right now, the bullets to rocks collision uses a fixed distance threshold, it can be improved to use the actual sizes of the asteroids. (might fix it later).
Also, you cannot simply increase the number of ships because there are some hard-coded assumptions that there is just one, but it is technically possible (the ships’ positions would have to be written to an array, too, and the shooting code would have to loop through them all).
Hope this helps.
Have fun!
Cheers,
Bobo
interesting read sir Bobo, I would like to play with that approach! ive been frustrated with what mathematical approaches i could use with getting angles and such… many thanks!
i also had another idea, but im not sure it it would work though…
- your ship movements are from a particle system (pflow)
- your cones are meshes following particle motion using pcont.particleTM
- now you apply a mesh select modifier on each cone. and set it to object, select the particles.
- now a script would loop through each ship to check if thier corresponding cone has selected any in the mesh select…
well, its just a vague idea, probably processor intensive. hehe.
Hey, didn’t have time to check out Bobos file yet but I might be able to help some. Here is some code that compares the direction of one abject (a) with the position of another object (b) and gives you an angle degree of the difference, like the cone you want.
[size=2]acos (dot a.dir (normalize (b.pos-a.pos)))
Firstly you should read up on vectors a bit. You can find that in the maxscript reference. Here is some explanation of the code above:
b.pos-a.pos gives you a vector going from the object a to object b.
normalize (b.pos-a.pos) gives you the normal(direction) of that vector.
a.dir is the direction(normal) of object a, wich is the way the local z-axis is pointing.
…so then you have 2 normals wich you can compare with acos (dot normal_1 normal_2)
Hope it helps some,
CML
[/size]
hi Rivendale!
thank you so much! that was as clear as water.
(jotting stuff down on my notes folder…)