Is it possible that the debugger values for position are in world space whereas the ones used in the actual flow are in local space?
I have a flow where particle colors are being mapped based on Z-elevation. I have ‘use node transform’ enabled on the PRT Loader. When my PRTLoader is not transformed, and my points are oriented vertically (at different elevations) the colors map as expected. When I rotate the PRT Loader, the colors still map appropriately (as if in local/untransformed space) but the values shown in the debugger are the transformed values, so when I rotate the vertical points to a horizontal orientation, the debugger shows the resulting color values should all be identical for points at the same elevation, however the viewport and rendered result show different colors across the points. If I add a ‘toWorld’ operator into the flow, then the rendered results match what is shown in the debugger.
I can get the results I want without issue, but my question lies around the discrepancy between what is shown in the debugger versus what is actually being calculated at render time, makes it hard to debug properly in certain circumstances.
This is correct, the values you are seeing are transformed into world space, because the Debugger is using the same approach as the Particle Data Viewer. I would consider this a bug though
It uses the FranticParticles.GetPRTObjectIStream() MAXScript method to read the data from the top of the modifier stack, but I disable all modifiers above the current Magma modifier so only the relevant portion of the stack is evaluated. The result is the world space state of the particles in render mode, that’s the data that will actually be rendered by Krakatoa.
It would be possible to disable the Use Node Transform of the PRT Loader while performing the Debugging and the data would be in object space (well, it would be still in world space, but the node transforms of the PRT Loader would not be applied, so world and object space would be coincident). I added it to the code to test and it worked. The same is possible with PRT Volume which has an InWorldSpace option, but not for all other PRT objects like PRT Maker, PRT FumeFX etc.
So for now the Debugger will show a warning that tells you what space the Position, Velocity, Normal and Tangent channels are. For 90% of the cases (PRT Loaders and PRT Volumes), you will be getting the object space data you want.
For the other PRT object types, we will have to implement core access to object space data in the FranticParticles.GetPRTObjectIStream() interface which is not trivial and won’t happen today.
The updated scripts are zipped and attached below. To install,
*Download the ZIP file
*In Administrator mode, go to the Thinkbox\Krakatoa\Scripts folder and back up the original files “Krakatoa_MagmaFlow.ms” and “Krakatoa_MagmaFlowManager.ms”
*Unzip the attached files into the folder
*Restart Max.
Keep in mind this change is 30 minutes old and might be buggy. Please report any issues with it in this thread. Krakatoa_MagmaFlow_20120131.zip (74.3 KB)
For your information, we have modified the Particle Stream Interface used to read this data to support both Object and World space data and the upcoming v2.0.2 update of Krakatoa MX 2 will use the former in the Debugger and the latter in the Particle Data Viewer, providing full consistency.
The script I posted is thus just a temporary workaround, once we post the new build all this will happen internally.
