Get the (standard) particles information
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/10/2012 at 15:04, xxxxxxxx wrote:
I only know of that solution in Py as well.
I just have a Null as a child then get them
childs via cache GetChildren().Should there be a more direct way I'd also be happy:)
Cheers
Lennart -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/10/2012 at 19:30, xxxxxxxx wrote:
Ok, I found out some stuff (by trial & error)
I created a document with an emitter that shoots particles. The document also contains a Null. After attaching the following code to the emitter, the Null follows the first particle. No orientation, just position:
import c4d import struct def GetDouble(p,buffer) : # each double takes up 8 bytes num=struct.unpack("d",buffer[p*8:(p*8)+8]) return float(num[0]) def main() : emitter=op.GetObject() # yes, the particles data is in the Tparticle tag of the emitter p_tag=emitter.GetTag(c4d.Tparticle) if p_tag is None: return null=doc.SearchObject("Null") if null is None:return # GetLowlevelDataAddressR is for read-only # GetLowlevelDataAddressW will allow the writing also # The SDK has them badly spelled # The "level" is spelled "Level" in the SDK buffer=p_tag.GetLowlevelDataAddressR() pos=c4d.Vector(GetDouble(0,buffer),GetDouble(1,buffer),GetDouble(2,buffer)) null.SetAbsPos(pos)
The SDK states that the particle information is:
Position (vector)
Direction (vector)
Wing (Vector)
Lifetime (float)
Bits (bits)Well on the first 24 bytes of the ByteSeq buffer we have, in fact, Position:
Position.x - Bytes 0 to 7
Position.y - Bytes 8 to 15
Position.z - Bytes 16 to 23The direction is as follows:
Direction.x - Bytes 24 to 31
Direction.y - Bytes 32 to 39
Direction.z - Bytes 40 to 47The Wing is as follows:
Wing.x - Bytes 48 to 55
Wing.y - Bytes 56 to 63
Wing.z - Bytes 64 to 71The direction returns what looks like the orientation of the emitter itself (kind of).
The wing... I really don't know how to interpret it. It looks like the Speed vector. But I would like that anyone more versed on particles to tell me.
From bytes 72 to 79 there is a double that grows slowly from 0.0000 in increments of 0.04 at each frame. That is consistent with my document as it is set to 25 fps, because 1/25 is 0.04
The problem is that it keeps growing even after the particle is gone.
That is because I haven't found out how to know how many particles are alive and whether the particle is alive or not. That is probably in the bits information but I really don't know how to interpret that.
So, with all I found out so far, would anyone help out into finding some more? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/10/2012 at 07:25, xxxxxxxx wrote:
Interesting Rui.
I don't have time atm to study this, so any input is most appreciated.
(Regarding Standard Particle Life , I -think- the "internal" particles are always live
but are only hidden/scaled over life. Anyone must correct me if I'm wrong)Cheers
Lennart -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/10/2012 at 08:57, xxxxxxxx wrote:
I think this post might be of interest: https://developers.maxon.net/forum/topic/5919/6005_tparticle-data-not-available-in-python&PID=26813#26813
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/10/2012 at 09:23, xxxxxxxx wrote:
That solution only works if there are objects as childs of the emitter and the "Show Objects" option is on.
I want to be able to access the particle values even if there are no objects being created.
And the good news are... I DID IT!!!
Check out the code:import c4d import struct # return the number of active particles def P_count(buffer) : count=0 for i in range(len(buffer)/88) : index=i*88 bits=int(struct.unpack("B",buffer[index+80:index+81])[0]) count+=(bits!=0) return count # return the ALIVE value of the particle p (0 or 1) def P_alive(p,buffer) : index=p*88 bits=int(struct.unpack("B",buffer[index+80:index+81])[0]) return (bits & 2) >> 1 # return the VISIBLE value of the particle p (0 or 1) def P_visible(p,buffer) : index=p*88 bits=int(struct.unpack("B",buffer[index+80:index+81])[0]) return (bits & 1) # returns the vector of the current position of particle p def P_position(p,buffer) : index=p*88 return c4d.Vector(struct.unpack("d",buffer[index:index+8])[0],struct.unpack("d",buffer[index+8:index+16])[0],struct.unpack("d",buffer[index+16:index+24])[0]) # returns the vector of the current direction of particle p def P_direction(p,buffer) : index=p*88 return c4d.Vector(struct.unpack("d",buffer[index+24:index+32])[0],struct.unpack("d",buffer[index+32:index+40])[0],struct.unpack("d",buffer[index+40:index+48])[0]) # returns the vector of the current wing of particle p def P_wing(p,buffer) : index=p*88 return c4d.Vector(struct.unpack("d",buffer[index+48:index+56])[0],struct.unpack("d",buffer[index+56:index+64])[0],struct.unpack("d",buffer[index+64:index+72])[0]) # returns the life of particle p (double) def P_lifetime(p,buffer) : index=p*88 return struct.unpack("d",buffer[index+72:index+80]) def main() : emitter=op.GetObject() p_tag=emitter.GetTag(c4d.Tparticle) if p_tag is None: return buffer=p_tag.GetLowlevelDataAddressW() count=P_count(buffer) # gets the number of active particles for i in range(count) : print "Particle "+str(i) # print the particle number print P_alive(i,buffer) # print the active state of the particle print P_visible(i,buffer) # print the visibility of the particle print P_position(i,buffer) # print the current position of the particle print P_direction(i,buffer) # print the current direction of the particle print P_wing(i,buffer) # print the current wing of the particle print P_lifetime(i,buffer) # print the lifespan value of the particle print " "
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/10/2012 at 09:25, xxxxxxxx wrote:
Now I only have two doubts.
The direction is not returning the particle direction but it is, in fact, returning a value that corresponds, somehow, to the direction of the emitter.
And I don't know how to interpret the wing value.
Could someone help me out on this? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/10/2012 at 01:10, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Now I only have two doubts.
The direction is not returning the particle direction but it is, in fact, returning a value that corresponds, somehow, to the direction of the emitter.
And I don't know how to interpret the wing value.
Could someone help me out on this?All the information you're getting about a particle is listed and explained in the members of c4d.modules.particles.Particle (Python documentation).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/10/2012 at 01:13, xxxxxxxx wrote:
Originally posted by xxxxxxxx
That solution only works if there are objects as childs of the emitter and the "Show Objects" option is on.
I want to be able to access the particle values even if there are no objects being created.
And the good news are... I DID IT!!!Ah ok, I understand now why you couldn't use this solution. Glad you found how to read the particles data.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 05/10/2012 at 08:28, xxxxxxxx wrote:
However, the information in the SDK about the standard particles is almost non-existent.
Shouldn't it be more clear? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/10/2012 at 02:36, xxxxxxxx wrote:
Originally posted by xxxxxxxx
However, the information in the SDK about the standard particles is almost non-existent.
Shouldn't it be more clear?Have you looked into the Python docs (not COFFEE) at the page for the class c4d.modules.particles.Particle? I don't think there's more to add.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/10/2012 at 05:25, xxxxxxxx wrote:
Yes, I have looked into it, Yannick.
It tells me what information is present but it doesn't tell me where it is, how to get it, etc. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/10/2012 at 06:03, xxxxxxxx wrote:
Originally posted by xxxxxxxx
However, the information in the SDK about the standard particles is almost non-existent.
Shouldn't it be more clear?Yes, it should.
Cheers,
André -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/10/2012 at 07:53, xxxxxxxx wrote:
Also, besides not telling us how to get the raw data, it doesn't tells us how to get the elements out of the data.
As you can see from my exemplar above, it is not a straightforward method.Rui Batista
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/10/2012 at 09:03, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Also, besides not telling us how to get the raw data, it doesn't tells us how to get the elements out of the data.
As you can see from my exemplar above, it is not a straightforward method.Rui Batista
The C++ documentation states that the array of particles is private (ParticleTag docs' page).
In fact the issue is: the C++ SDK's ParticleObject class isn't wrapped in Python. This class allows to easily access the particle array without having to figure how the particles are stored in memory. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/10/2012 at 09:37, xxxxxxxx wrote:
So, should it be in the python SDK in the current form?
Because, as it is now, it shows information that is not accessible directly.Rui Batista
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 09/10/2012 at 01:42, xxxxxxxx wrote:
Originally posted by xxxxxxxx
So, should it be in the python SDK in the current form?
Because, as it is now, it shows information that is not accessible directly.Particle class is used when overriding ObjectData.ModifyParticles(). I think it was wrapped for that purpose. But yes, it should be possible to access directly the particles in an emitter with the Python SDK.