Just want to confirm my current understanding - PRT files are stored “unit-less” and are loaded in the current Max scene’s unit settings? But certain source files can be unit-aware (e57 for instance) and in that case are loaded at the proper scale for the scene?
I ask because here’s what I’m experiencing:
I’ve done a batch conversion of e57 source files to PRT using Frost maxscript commands.
If I load the e57 and the PRT side by side in a feet scene, the PRT source is smaller than the e57 source.
If I load the two into a meters scene, they match.
It looks like the e57 is the proper scale either way, so I’m thinking the PRT is the wrong size if I load it into a feet scene, hence ‘unitless’ and scene unit dependent. ?
This is incorrect, PRT v1.0 was not units-aware, but the current v1.1 specification supports both units scaling, and coordinate systems orientation metadata, among other things. thinkboxsoftware.com/krak-pr … le-format/
I need to check with the Frost developers whether the Frost converter is respecting the E57 units correctly, and that it is actually saving v1.1 PRT files.
If you would load the E57 in a Krakatoa 2.6.x PRT Loader, then save that to PRT using Krakatoa in Save Particles mode, you should get a PRT v1.1 file that has the same scaling as the E57.
Also, can you confirm the exact version of Frost you are running?
This is still my preferred method of converting to PRT (instead of Krakatoa’s save particles mode) because of our LiDAR workflow. I prefer to maintain the input files individually instead of combining them into one, and batching the Frost conversion via MaxScript was easier for me than setting up a rendering workflow with Krak (though I will certainly acknowledge that it would be possible, just didn’t have the need.) Thanks for the clarification re: 1.0 vs 1.1 spec.
I talked to the developer, and it is a defect in Frost - it is not respecting the E57 units right now.
I tested it myself - I loaded an E57 which I know for sure has units metadata - in fact the PRT Loader shows me it has Units In Micrometers 1d+06, which means 1 meter. However, when loaded in Frost in a scene set to Centimeters, the E57 loads 100 times smaller.
The Frost converter does not respect the units either.
So if you load an E57 in a PRT Loader, it will be in the right units.
If you load the same E57 directly in Frost, it will be in the wrong units, unless the scene happens to be in the same units as the E57 (usually Meters, or Feet).
If you convert that E57 to PRT v1.1 using Krakatoa, it will be in the right units.
If you convert that E57 to PRT using the Frost converter, it will be in the wrong units, unless 3ds Max happens to be in the same units as the E57.
We will log this to be fixed.
In the mean time, you might have to use Krakatoa and a PRT Loader at the origin of a fresh MAX scene to perform the conversion if you want to retain the units.
I can help you script the Krakatoa conversion so you don’t have to do anything by hand. It does not even require a license when performed on the workstation.
Where can I see what Units a PRT Loader is detecting? Additionally, Is there anywhere in the UI that something would show me what version a PRT file is?
To confirm - the only way to ‘convert’ with krakatoa would be to render using the save to particles mode, correct? Just want to be sure I’m not missing a piece.
To derail my own thread w/ a change of subject - I noticed that the ‘particleColorSource’ properties were deprecated in 1.5. What would be a good way of overriding RGB color on a per-PRT loader basis? I know you have the property query now, youtube.com/watch?v=WKzMae0v9t4 but querying the position of each particle in an attempt to determine what source it came to get that’s PRT loader’s wirecolor seems computationally expensive. What I’m after is a view color coding each PRT Loader individually so I can visually separate the sources. I was thinking I’d be better off just MaxScripting a basic for loop script that takes an array of objects and puts a unique magma modifier on each one with a hardcoded wirecolor node?
In the PRT Loader, click the [>>] button next to the Add/Remove buttons, and select the File Sequence Manager.
In it, you will see columns for the Units, Coordinate System etc. if the file is PRT v1.1, and no units if it is v1.0.
When I looked at the E57 file (without conversion), it showed just the Units column plus the channels, because it does contain metadata, but not the same as a PRT.
So you can infer from the content of the File Sequence Manager whether it is 1.1 (has metadata), or 1.0 (no metadata).
Well, the funny thing is there IS another way, and last week I discovered it has the same scaling issue - it still saves in v1.0 format. We will fix that too. Also, it had a bug when saving Particle Flow files, which is now fixed, but not available in the shipping build yet. That function is called FranticParticles.SaveParticleObjectsToFile(). If it was functioning correctly, I would have suggested it as a workaround. But since it has the same issue (plus some more), it cannot be used. It was added to allow baking for rendering with Krakatoa SR (stand-alone), so it wasn’t meant to be a shipping feature. It might become a shipping feature in the near future though
The color source is a complex topic, so I have posted a Blog about it thinkboxsoftware.com/krakato … art-1.html
See the section “Color me… confused”
I also wrote a new tool which will be probably in the next Krakatoa release which shows you the life of any channel along the stack, so you can see how the color is changing for any particle from base object to renderer…
In short, if the particles had no Color channel when they were saved, they will use the wirecolor of the PRT Loader automatically. But since most E57s will have a valid Color channel, you are probably ending up with colors from the scan. It would be a pity to lose that data.
There are several ways to override the color per object, including assigning a unique material to each PRT Loader - the material diffuse color will overwrite the incoming color, and Magma as you suggested.
In your specific case, I would recommend adding a Magma modifier (you can make a simple preset with an exposed color swatch). You can then set the so-called PRTViewportColor channel to the InputValue : Vector. This will modify the color in the viewports, but will not affect the renderer.
If you want the change to be seen in the renderer, just set the Color channel instead.
EDIT: Yeah, the script you posted will do the above, you can set it to use PRTViewportColor if you want that only in the viewport.
Here is an improved version of the script you posted. Instead of a fixed color taken at the time of assignment, it uses an InputScript to query to wireframe color. So if you change the object color later, the modifier will update (as soon as the PRT Loader updates, e.g. on time change).
The script uses the NodeHandle to remain name-independent, so you can rename the PRT Loader and the color will still be taken from the right object.
I also switched to a SpaceMagma so it would end up on top of the modifier stack (requires KMX 2.5 or higher). Finally, I switched it to use PRTViewportColor so it does not modify the renderer, just the viewport.
(
--http://www.thinkboxsoftware.com/kraka-magma-and-maxscript
for o in selection do
(
theMod = SpaceMagmaModifier()
addModifier o theMod
magma = theMod.magmaHolder
theOutput = magma.createNode "Output"
magma.setNodeProperty theOutput "channelName" "PRTViewportColor"
magma.setNodeProperty theOutput "channelType" "float16[3]"
theInput = magma.createNode "InputScript"
magma.setNodeProperty theInput "script" ("(maxops.getNodeByHandle "+o.inode.handle as string+").wirecolor")
magma.setNodeInput theOutput 1 theInput 1
magma.autoUpdate = true
)
)
