Ahhh, ok, I understand now. So are you using the Geo Directly in Frost?
I did get it to work using Vertex Color Blending, silly Box#3 reports back no Vertex Colors (EDIT: something weird, it is working now, same scene just a restart) even though it will assign them, show them in the VP and render them. I had to save to prt and then load in Frost.
LOL not sure mine is much better, i’ve got some mud in there:
Yes, unfortunately the implicit surface meshing methods (Union of Spheres, Metaballs, etc.) produce jagged material boundaries. Nicer material blending is on our wish list, but for now you’ll need to use a Blend material as Bobo described.
Ok, I will welcome that when it comes 
Particles and end user vertex colors are not exactly super user friendly either though BUT they do work with Frost which is great. Thanks for the explanations Bobo (the other I had seen was in the help under First Steps 
thinkboxsoftware.com/frost-first-steps/)
Pflow, Shape Instances, and Vertex Paint, ugh that is a lot of data to push around. Of course it must just be silly of me thinking I could get this to work how I would like it, may not be possible. PFlow needs some love here somehow. I have to test how well TP works with this, I tried some earlier vertex coloring in TP didn’t really seem much easier or more correct (of course my TP skills are a tad bit limited) So far to date Krakatoa PRT and bunches of seed particles seem to be the best approach particle wise. Low density large multi-colored particle systems are just difficult.(could I be any more specific )
I was testing this out over the weekend and it is working beautifully 
This really opens all kinds of doors for procedural material editing. Any channel that you can convert into a color or black and white value in MagmaFlow (read: ANY parameter) can be used to control a material.
Want to make a material self-illuminate based on it’s velocity? Sure! How about mask off displacement based on a TP datachannel? No problem! UV’s even work fairly well if the particle count is high enough.
On that note, realflow bin files (which can be dropped right into a PRT loader) give lots of data to play with. The demo can go up to 100,000 particles, conveniently saved to different sequences based on their source for easy magmaflow adjustment. Its a great way to see how the maps work with enough samples to clearly define boundaries. The test render below is a realflow sim loaded into 2 PRT loaders meshed together in one Frost. Fun stuff…
cheers,
CZ
wow nice,
i didnt know we could do vertex coloring of frost!
would be great to have a “smart” frost shader which would allow to work with frost unique properties to shade and color the mesh,
color by velocity, density, etc. the power we have with magmaflow in krakatoa, only for frost mesh with any renderer
Probably because you did not read all the tutorials? 
It is shown at the end of the Intro to Frost:
thinkboxsoftware.com/frost-first-steps/
If you use PRT files or objects as the source in Frost, you can already use MagmaFlow to do that. So the current workaround is to dump your particles to PRT file sequence, then load with a PRT Loader and add KCMs to it. (Read the rest of the tutorials )
The plan for the future is to allow this for any input including geometry vertices, PFlow, TP etc. without the intermediate saving to PRT, but let’s see what will happen…
aye aye!
i have to admit i missed that page completely or i dont think it was up when we started using it
thanks for the great demo!! btw
i am planning on making a little realflow frost piece now to show off how great this product is!
really amazing that we have these new possibilities of shading-- very exciting
Bobo, Can you show me how to apply a diff vertex color to each prt so that Frost could use it for material blending? I managed to do vertex color blending in any other type, but with PRT’s I couldn’t get it to work. I checked here thinkboxsoftware.com/frost-g … hing-mode/ and also went through the krakatoa docs but couldn’t find an example that show it.
Thanks!
Since the Vertex Color Map in Max supports all 100 mapping channels and the Vertex Color is the Color channel in PRT, I’d suggest using Mapping2, Mapping3 etc. for material blending (assuming they are not needed for texture coordinates inside the materials).
Add a KCM to the PRT object. Wire any flow that produces a value between 0 and 1, for example if you want to blend materials based on particle velocity, you could take the Velocity channel, divide its Magnitude by the Max. velocity allowed, clamp between 0 and 1, convert to Vector and output as Mapping2. Now add a Blend Material to the PRT object and put a Vertex Color Map set to Channel 2 in the 3rd (control) slot that defines how much of each material to take. Particles moving slow will get the one material, particles moving fast will get the other. The mapping channels are present in the Frost mesh too, so the blending will apply to Frost.
Or you could use the Age/LifeSpan channels as described in this tutorial thinkboxsoftware.com/krak-ma … ng-by-age/ and output the result as a Mapping channel to control the Blending. Or you could apply a selection using Volume Select modifier, load the Selection channel in the KCM and output as a Mapping channel to do the blending…
Try it out and tell me where you fail.
just love how flexible everything is – you guys built a solid foundation with krakatoa and continue to allow the artist to create
a multitude of effects in a multitude of ways. whew… i have to try that material blending by velocity, looks fun. i had a setup
just using vectors but materials offer lots of more exploration. back to the lab!
Thanks Bobo, didn’t realize it’s THAT simple. For blending between two PRT’s it’s as simple as hooking up a vector to the color. Coloring by other channels works great too. Thanks again.
Hi there,
Here at Ingreme, we’re starting to learn how to use frost, magma and krakatoa combined with realflow sim’s. We were trying to make material blending between two liquids in the same simulation, and after reading all that you wrote we started trying many and different aproaches. When Bobo sayed to use pflow, i was a little bit scared due to high count particles we’re using in some sim’s… so we’ve tried this (see attached file) and it kind of works. Maybe we’re just having luck with the results, but i hope you can tell us if this could be a correct aproach or not.
The weird thing we’ve noticed is that even in realflow, when two different liquids connect, they go kind of “nuts” in terms of uvw. Maybe we’re doing something wrong over here…
Thanks for any info on this,
The uvw’s are clearly incorrect comparing the same texture applied to mesh in 3dsmax and realflow. Any tip on this?
Thanks again,
Hi Rui,
I need some more information regarding the mapping coordinates.
Do the PRT or BIN files coming from RealFlow contain any mapping coordinates? If they do, you would have to map your checkered map to them to get approximately what RealFlow is mapping.
With regards to Blending, when you assign [0,0,0] to one PRT Loader and [1,1,1] to another, you obviously cannot use the mixture of these two for actual texture mapping, but it should work for controlling the Blend material via a VertexColor Map (I assume that’s what the Solid Materials rendered example shows). That’s the approach this thread was about. So that should be pretty much ok since the Frost would use the influence of the closest particles to blend between 0 and 1 - if you have only particles with [0,0,0] close to a vertex, that vertex will be mapped as [0,0,0], if you have only [1,1,1] in the area you will get that, and if there are different amounts of particles around the vertex, it will show a blend of the two values. Then that would be transferred to the Blend material.
Using the MtlIndex is a bad idea because it would create a hard edge (it is per face).
You have to keep in mind that if a moving particle has a dedicated initial UVW value representing its original position in the simulation, as it moves around it will distort the mapping and produce all kinds of swirly effects. So whatever RealFlow is doing with the mapping, just make sure you bring it over via the PRT or BIN file. Use the Particle Data Viewer to peek into the channels and see what values are there and use them, or copy them to other channels via Magma as needed. If the RealFlow mapping does not come over with the particle files, we will have to discuss some more complex solutions…
Hi Bobo,
We’ve checked and the .bin aswell .prt (we’ve tested the two aproaches) have uv’s information on them. Our current problem seems to be how to translate this to Frost Mesh… can you give us directions?
I attached a file where we see the information of the bin file and a quick test from real flow, then real flow bin loader inside max and then frost loading prt files. I wonder how we can obtain correct uv’s from this prt’s (or bin) and translate it to frost… help!
Cheers!
Out of curiosity, do the UVs looks anything like the ones in RealFlow if you mesh only ONE of the files?
In other words, is it the mixing of two sequences, or the mapping interpolation of Frost that is causing the issue?
Also the mapping coordinates in the PDV show values outside of the 0.0-1.0 range. Would be interesting to see what values the RealFlow mesh has there, it could be related.
Could you please send us the particle files you’re using for one or two frames? You can send us files using our ticket system. I think you’ll need to put the files in a .ZIP file to get them through.
Hi Paul and Bobo,
Particles sent. Remember this is a super simple sim with two emmiters with same settings dropping down to a vase and colliding. This is super simple to replicate.
Bobo, I’ve done meshing using just one bin and the result is attached.
One important thing that i didn’t refer is that i’m using Frost in 3dsmax 2013 version 1.3.3.48356.
Thanks again!
Cheers,
Hi Rui,
Turns out that since RealFlow is Y up, we should have also swapped the V and W channels like we do for the other vector channels like position and velocity.
I loaded the first sim in a PRT Loader, added a Magma modifier and swapped the V and W (Y and Z in Magma) of the TextureCoord channel, then meshed with Frost in Anisotropic mode. As you can see from the screenshot, the mapping is now very close to what RealFlow produces.
We will fix this in both PRT Loader and Frost since it is actually a bug. In the mean time, please use the Magma modifier to tweak the channels.
