Is it somehow possible to create/calculate motion vectors in Magmaflow?
Particles exported from Xenodream do not have any velocity channel, and bringing millions of particles in PFlow is not really an option…
Any suggestions?
Martin
Right now there is no good way to do it with MagmaFlow because it is not possible to compare the positions of two particles on two frames to determine their motion over time. I have suggested such tools in the past, but we will see what the future will bring…
It would be possible to script though - read two PRT files using the MAXScript interfaces we have provided, and generate a new PRT file with velocities. This assumes that there are unique IDs in the PRTs, or the order/count does not change over time.
Thanks for the info Bobo…
The Xenodream PRT’s do contain an ID channel and they also have a fixed order and number of particles - so perhaps this is the way to go? The only question then, is would the script approach be too slow when dealing with approx. 5 mill particles?
You won’t know until you try. Obviously, it will have to happen offline each time you export new PRTs. New PRTs will be produced which you will then load. So it probably doesn’t matter how long it takes since it is not real time anyway…
Is there any documentation on how to setup the script, apart from the reference found here software.primefocusworld.com/sof … _value.php
There was a thread in the Krakatoa Beta forum
viewtopic.php?f=61&t=4220
which shows how to use the In and Out streams to combine particle data.
In your case, you would have to create two PRT Loaders, one with Offset of 0 and the other with Offset of 1 and read particles from both, combine into a single stream and save out to a new PRT file. I might write an example for you if I can find the time (I am in production crunch right now, and I don’t directly work for Thinkbox support at the moment).
OK, I did a quick test with the Teapot demo from the Introductory tutorial.
The PRT Sequence contained 1 million particles, with constant count and order.
I created a PRT Loader with Offset 0 and another with Offset -1. Set the Custom Ranges of both to the valid frame ranges to avoid missing frames.
I read the two streams via MAXScript, subtract the first position from the second, multiply by the frame rate and write back the Position and the Velocity vectors to the new stream.
It took around 4 seconds per frame, so with 5 million particles it will be about 20 seconds per frame. Not very fast, but usable.
Once it was done, I loaded the new sequence in a 3rd PRT Loader and compared the Velocities calculated by my script to the velocities saved in the original files and they were about the same. In fact, the velocity from PFlow described where the particle would go according to frame step integration, but the particles were saved with 1/2 frame integration, so the saved vector did not point exactly at the next frame’s position. With the new PRT, it did.
Here is my quick and dirty test code. If you have changing particle count over time, you will have to do a lot more figuring out the matching IDs and it would be slower (unless you preload the one frame in memory in a MAXScript array and do searches in it).
[code]
(
PRTLoader1 = $PRT_Loader01
PRTLoader2 = $PRT_Loader02
for t = 0 to 100 do
(
st = timestamp()
sliderTime = t
theFile = FranticParticles.ReplaceSequenceNumber (getDir #temp + "\\_TestVelocity_0000.prt") t
theOutStream = KrakatoaParticleOStream theFile #("Position float32[3]", "Velocity float16[3]")
--Grab the input streams from both PRT Loaders
theStream1 = FranticParticles.GetPRTObjectIStream PRTLoader1
theStream2 = FranticParticles.GetPRTObjectIStream PRTLoader2
--Get the Channel Layouts of one Stream - they will be the same anyway
theChannels1 = theStream1.GetChannels()
--Find where the Position channel is inside the definition
posIndex1 = findItem (for i in theChannels1 collect i[1]) "Position"
--Loop until one of the objects runs out of particles
done = false
while not done do
(
theData1 = theStream1.readParticle() --get a particle from both streams
theData2 = theStream2.readParticle()
if theData1 == undefined or theData2 == undefined then --if either one is empty, stop looping
(
done = true
)
else --if both are still vald, get the position and color values from both and write to the PRT file
(
thePos1 = theData1[posIndex1]
thePos2 = theData2[posIndex1]
theVel = (thePos2-thePos1)*FrameRate
theOutStream.writeParticle #(thePos1, theVel)
)
)
--Close all in and out streams
theStream1.close()
theStream2.close()
theOutStream.close()
format "%\n" ((timestamp()-st)/1000.0)
)
)[/code]
Thanks a bunch!! I’ll try it out in the weekend…
So far so good - I have managed to write a new PRT sequence using the script… However, the new PRT loader is “jumping” back and forth on the x axis. Also, it seems that the color channel is not transferred properly to the new PRT - all the output particles have the same color…
The screenshots below show the input and output particle data -
INPUT:
OUTPUT:
Hi Martin,
I think you misunderstood my post.
I did not post THE solution to your problem.
I posted an EXAMPLE of how to use the methods in the In and Out streams in MAXScript so you can write your own script.
Big difference 
The script does not copy the color because I did not care about the color when I was writing it. You have to add code to handle the color or any other channel if you need it.
Also, my example script assumes all particles on all frames are perfectly aligned ID-wise, which might or might not be true in your case - cannot tell without seeing the actual PRTs.
In short, you will have to take the example I wrote and tweak it to work in your case. Or, if you can create a very simple sequence with 1000 particles per frame and post it, I might be able to look into the issues and expand the script for you.
Hi Bobo,
Yes, of course - I do realize that the script you posted was not final in any way… I’ll have a go at tweaking it and see if I can come up with a solution
In the meanwhile here is a 100 frames with 1000 particles in each, just in case you want to take a look at it…
http://rapidshare.com/files/443255638/XD_VELOCITY_TEST.rar
Cheers,
Martin