It’s frustrating that we must maintain a maintenance subscription to get compatibility to the annual release. I use Frost and love it, but a 2.0 release that requires a new license for a minimum amount of features is annoying. is there anyway to add 2017 compatibility to older versions?
- The full Frost 2.0 feature list is not available yet - it is not what is in the first Beta drop.
- Frost 2.0 is up to two times faster than 1.x. That might not be a feature, but we were toying with the idea of Frost 2.0 being just 2x faster with no new features and it sounded like a possible plan. However, we knew someone would be upset by that, so we are working on adding other things you have not seen yet.
In my tests, the Naiad River dataset meshed 1.89x faster, which includes the PRT loading. Render time according to Max Summary went from 4898 seconds to 2591 seconds for 190 frames animation. YMMV.
Here is a (not so) subtle teaser of another feature that might be coming to Frost 2.0…
Created using a single PRT Volume from one extruded text shape using Magma to control the geometry distribution, PRT Surface from a plane with Magma to control the scaling of the grass blades, rendered in V-Ray (v3.30.04 or higher required).
Contains over one million particles distributing that many V-Ray instances.
This is interesting…I was just going to start to do some speed/memory testing of Frost vs Vray Instancer. This makes me think I shouldn’t waste my time…
I am doing my tests using Frost 2.0 and VRay Instancer.
Frost 2.0 instancing preparation is right now single-threaded (VRay Instancer has an experimental multi-threaded feature which I tested too). We will probably try to multi-thread that.
I created 1 million particles using PFlow and made sure they were cached in memory.
I assigned a Teapot primitive as the shape to both Frost 2.0 and VRay Instancer.
With default Teapot (4 segments, 1024 faces, no material!), the memory in both went from 4.7GB to 11.4GB.
2m13s : Frost MX 2.0 Beta with VRay 3.3 Instances in Max 2015
2m53s : VRay 3.3 Instancer Single Threaded
2m37s : VRay 3.3 Instances Multi Threaded
2m17s : Frost MX 2.0 Beta with VRay 3.4 Instances in Max 2016
2m37s: VRay 3.4 Instancer Single Threaded
2m16s: VRay 3.4 Instances Multi Threaded
This is the total render time from hitting the render button to finishing the 800x600 image.
The actual render time was about 1m35s, so the rest was the instancing.
As you can see, Frost MX single-threaded was 40 seconds faster than VRay Instancer single-threaded in VRay 3.3, and 20 seconds faster in VRay 3.4.
The multi-threaded mode of VRay 3.4 got faster than 3.3 and made them equal in this case.
Next thing was to see what happens when the face count goes up.
Memory usage was consistently the same, all tests are from VRay 3.3 (my fist run)
1 million 6 segs Teapots via PFlow (2304 faces * 1 million = 2+ billion faces)
2m42s : Frost VRay Instances
3m16s : VRay Instancer Single Threaded
2m50s : VRay Instancer Multi Threaded
1 million 8 segs Teapots via PFlow (4096 faces * 1 million = 4 billion faces)
2m42s : Frost VRay Instances
3m24s : VRay Instancer Single Threaded
2m47s : VRay Instancer Multi Threaded
1 million 16 segs Teapots via PFlow (16384 faces * 1 million = 16 billion faces)
3m38s : Frost VRay Instances
4m15s : VRay Instancer Single Threaded
2m55s : VRay Instancer Multi Threaded
1 million 32 segs Teapots via PFlow (65536 faces * 1 million = 65 billion faces)
7m27s : Frost VRay Inst:
8m13s : VRay Instancer Single Threaded
3m53s : VRay Instancer Multi Threaded
As you can see, adding more polygons to the shape does NOT increase memory usage, but it increases preparation time.
The actual render time was constantly 1m35s, just the instancing took longer.
Frost was consistently faster than Single-Threaded VRay Instancer, but not by much.
You can see that Mutli-Threading pays off with heavier meshes, so we will definitely try to add that too.
The next thing I discovered was stunning - assigning a material to the object REDUCES the memory usage. It appears that VRay assigns a default material to each instance if there isn’t one already, and this can eat up GBs of RAM!
For example, I did 1 million copies of the Buddha statue (221K faces) and the memory usage went up from 4 to 12.2 GB. With a Standard Material assigned, it went only to 9.6 GB! So I will rerun the above tests with the teapots using a material and report the results…
Neither of these tests would have worked with the old Frost. I don’t think that you could get more than 200K instances of a teapot in 32 GB of RAM with it, while now I can do a million Buddhas and use only 5GB if I have a material assigned.
More info to come…
Bobo, this is fantastic. The problem I was just running into was Frost 1.x was chewing up memory with 1 milion points and crashing max, which is why Vray Instancer was so useful, although I was wishing I could use a PRT Surface 
.
The only ? now is you say this ‘may’ be in Frost 2.0. What is the likelihood? It seems like you’re pretty far along.
Well, when I posted that it “may” be in Frost 2.0, I had not seen it in a build yet. 
So I asked Paul to give me something, and using our the very first iteration I made the image you saw above, on my first day of testing.
Now it is a week later and we are about to drop a Beta build in the coming days that has it in.
However, the Animation playback control (random offsets, Magma channel controlling timing) is still not working in the current build. We understand that it is an important feature, but we might post a Beta build without it (if you enable Animation offsets, nothing renders), and then work on fixing it for the next Beta drop. Or wait for it to be fixed before we post anything… We will see.
Obviously, the benefit of Frost V-Ray instancing is the advanced Magma controls over which shape goes to which particle, which material will be used on each shape, which frame of an animation will be played etc. We also intend to look into adding Non-Uniform scaling which Frost currently does not allow (all scaling is performed uniformly along all 3 axes). It would make randomization of trees and grasses even better.
As promised, I rerun the million teapots test with a Standard Material assigned. As expected, the memory usage (starting from 4GB according to Task Manager before hitting render) went up to 8.5 GB, as compared to 11.5 GB when rendering the same scene in the same version of Max and V-Ray without a material! So no material on 1 million instances can cost 3 GB of RAM… This was absolutely identical to rendering the much bigger Buddha mesh under the same conditions, so I was actually able to predict the outcome even before I rendered the teapots.
Will make sure this is documented somewhere.
I reported the problem to Vlado and the material issue should be fixed in the latest nightly builds of V-Ray (after Friday, July 8).
So no need to document anything after all
Oh, great.
This is just the material issue right? Not the slave rendering as trimesh?
Right, Vlado fixed the material issue.
Thank you for reporting this! I’ll be sure to test this before our next update.
The new 2.02 build talks about the MaterialID. Is this only in conjunction with the newer build of Vray?
Basically, Material IDs should now work the same whether “Use V-Ray Instancing” is on or off. It should work with any supported version of V-Ray (3.1 or higher). What version of V-Ray do you use? We might be able to support an earlier version if you need it.
Did you maybe find a bug? Or something doesn’t work how you’d like?
I haven’t tried it at all yet, but I don’t like to download the nightly build of Vray if I don’t have to. I’m running 3.4 so it should be fine. I’ll give it a try this weekend. Thanks, Paul.
I discovered a bug while testing today - if a shape has multiple Material IDs already (say, a Box primitive is picked), and the distribution object is a PRT object with a Magma setting the MtlIndex channel, and Frost is set to use the MtlIndex channel, there will be an error and V-Ray will not render any instances due to a mismatching channel format (int32 coming from Magma, uint16 expected by Frost). However, if I pick a Sphere or another primitive that has only one Material ID assigned at birth, it works without problems and the Magma can control the material assignment.
I have reported this and Paul is looking into it.
In addition, rendering with the built-in plane shapes as V-Ray instances was crashing both 2016 and 2017. Paul has already fixed this internally.
EDIT: And then Paul fixed them and posted a new 2.0.3 build 
EDIT 2: One of the MtlIndex problems is still around though. I will provide Paul with a sample scene to reproduce. Workaround: Don’t pass a MtlIndex from Magma if NOT using the MtlIndex mode in Frost. Just disable the modifier or the output node.