Using Sketchup with Skatter and VIZPARK models
The Sketchup plugin Skatter has become an essential plugin to have for landscaping in Sketchup. I want to show you in this tutorial how it works with Maxwell and especially the fact that all of the VIZPARK vegetation libraries are already compatible when using Maxwell + Skatter, by loading the MXS versions of the VIZPARK libraries as references inside of Sketchup, which you can then s(K)atter. I’ll also go through how to create your own Skatter presets using MXS Reference files.
skatter’s “Render only” feature
For the moment, the Maxwell Sketchup plugin does not work with Skatters “Render only” functionality (but this will change in the future). In the case of working with scattered MXS references, the advantages this feature has for Maxwell users is that it allows you to use the “Preview limit” feature in Skatter so you only see a portion of the scattered bounding boxes in the viewport to keep viewport navigation running smoothly. The other advantage is that generation time is shorter when using hundreds of thousands of instances because the viewport generation itself then takes much more time that what the actual scatter generation takes.
The viewport navigation only becomes an issue if you have over 50 000 or so bounding boxes visible in the viewport. But even so, there are two ways to comfortably work with many more instances which I’ll explain in detail below. First though, I just wanted to mention my findings regarding Sketchup memory usage and generation time, both with the Render Only feature on and off.
I first applied one of the grass presets to a 300m2 plane and Render Only on. I set preview limit to only 5000 so it would have very little impact on RAM usage or viewport generation time.
- Skatter creates almost 1 million points, and SU RAM usage goes to about 2.8GB. Total time was 15 seconds (incl. 5 seconds viewport redraw time). To note is that only one CPU core is used for this, which is probably SUs “fault”.
- I then changed the preset so it would generate only 1000 points to see if SUs RAM is freed up. It did decrease a bit but stayed at around 1.8GB. I also tried closing the Skatter window but RAM remained the same.
- Now I switch Render only off (when it’s off the Preview limit parameter doesn’t matter, it will display all generated instances regardless). RAM usage went to about 3.6GB and generation time went to 69s (of which 59s for view redraw).
- I pressed render to see how long it takes to export the 1 million instances: about 5min 10sec, RAM usage increased to a max of 5GB at the end of the export.
So all this to show you’re certainly not limited to a few thousand instances even with Render only off, at least as far as Maxwell is concerned. There are two things you can do to make the workflow easier:
- Actually use “Render only” when setting up your scene, so you can use the Preview limit to have a rough idea of where your instances will be in the scene, and when you’re ready to render, switch off Render only, Recalculate the Skatter(s) and then press render.
- Not use “Render only” at all and as soon as the Skatter group is created, move it to its own layer and hide the layer while working on the rest of your scene. If you later wish to edit this Skatter group, unhide the layer (it may take a few seconds for them to appear in the viewport depending on how many there are), right-click the group in the viewport and choose Edit Skatter group. If you wish to run a preview using FIRE, unhide the Skatter group layer, activate FIRE and let it start rendering, then you can hide the layer again so you can navigate smoothly through your scene, while still seeing the Skatter instances in FIRE. Also, there is the option in the Maxwell plugin to render hidden layers (found in the plugin options). So this lets you leave the Skatter layer(s) hidden and when you hit render, the plugin will still export all of your Skatter instances. Of course, this only works if you don’t have any other hidden layers in your scene which you want to remain hidden. If that’s the case you have two options: unhide all Skatter layers before rendering, or export the scene to Studio and hide the unwanted layers there and hit render.
Skatter’s default library presets
I also quickly tested a few of the library presets that ship with Skatter. They are compatible with Maxwell, and the grass materials have thinSSS applied, although the material is pretty simple and there is no shiny layer added, or bump. Works ok for a quick setup although I think the grass materials I created for the VIZPARK grass models will be more realistic 🙂 The VIZPARK models are also more detailed and use up to 4 different textures. Just to quickly show two examples, a lawn on a 20m2 plane (only a few thousand instances were needed for this, so the generation/export was pretty much instant):
using MXS References and Skatter
Use the Load MXS Reference button in the Maxwell plugin toolbar, and load each reference you want to use. There are no materials to create or assign, they are already contained in the MXS file itself. So it’s just a matter of loading the MXS Ref and placing it somewhere in your scene, then create your Skatter group as usual by selecting a Group in SU, then select the MXS Reference(s) as the objects you want to scatter and click Re-Generate in Skatter.
So that’s all there is to it. The fact that the VIZPARK vegetation libraries include MXS files is a huge advantage. It means that they are effectively already compatible with any application that has a Maxwell plugin. In fact, even if the libraries had .skp files, I would still prefer to use the MXS References because even one high polygon object is enough to make the SU viewport slow, so I would display the .skp file as a bounding box anyway. I don’t see an advantage to using .SKP files compared to loading the MXS References (which are always displayed as a bounding box).
To avoid any possible confusion, when I talk about an “MXS Reference file”, I’m really just talking about a regular Maxwell scene file, that’s referenced inside your main application. It will only be loaded into your main scene at render time and this has several advantages (for more details see the Maxwell manual)
So it’s not a special kind of MXS file, it’s just…an MXS file. You can easily create your own, and they don’t need to contain only one model, they can contain a whole city if you wish. There are only a couple of important things to keep in mind when you create an MXS which will be used as a reference:
- It’s important that the model in your MXS file is at the scene origin (0,0,0) so that it will appear where you intended in your scene. In regards to MXS files created with Sketchup – if you see the MXS reference appears offset in the render, make sure to properly set the axis origin in your SU model, before exporting it to an MXS file.
- You can’t have other MXS references in your MXS file, which you also intend to use as a reference. In other words you can’t have two or more levels of MXS References.
Creating the MXS is simply exporting your scene using the Maxwell plugin. In SU there is a dedicated button for that, called “Export MXS” – simple enough. I think all the Maxwell plugins have that functionality. To ensure that the MXS file is usable on another computer or a render farm, make sure any assets (meaning textures, ies files, ior files, HDR files…) used in the scene are located in the same folder as the MXS file, or in a subfolder to it named “textures”. The plugin automatically does this for you when you export an MXS, if you have the option “Pack & Go” set to Yes in the plugins Output options.
Creating your own skatter presets using mxs reference files
I won’t copy all the info about creating Skatter presets mentioned in their manual (you can have a look in the “Library” section of their manual for details), I’ll just mention an extra step that is necessary for creating presets that use MXS References:
- Set up your skatter as you wish (distribution, spacing etc.), using as many MXS reference files as you want. For example you can create a lawn using 6 different VIZPARK grass MXS models.
- Click the floppy disk icon in the Skatter dialog to save the current skatter as a preset. It’s a good idea to have a render image to use as a thumbnail for the preset. Resolution should be 200x150px. You can also choose to save your MXS Skatter preset in a custom folder.
- Skatter creates in that folder one “<Presetname>.sklib” file which contains the Skatter settings, and one .skp SU file for each of the MXS references used in the preset.
- This is the extra step for MXS presets: you need to open each of these .skp files and you’ll see it’s just a cube – the connection with the MXS Reference has been lost. So what you simply have to do is delete that cube, and reload the corresponding MXS file into this scene and resave it. That’s it. Just make sure to place the bounding box of the MXS Reference in the center of the scene.
Some general tips about using Skatter
- The “Uniform” distribution method, along with about 40-60% jitter on both X and Y works very well if you want to quickly generate lots of instances which are evenly distributed (with some randomness), and which don’t end up overlapping each other too much. It’s well suited for covering large areas with patches of grass, or making huge forests. If you use the other method, “Randomize”, for these purposes, you will have to create a lot more instances to avoid empty areas and you usually end up with too many instances overlapping each other.
- Related to too much overlap, Skatter does have the Collision option, but this can add a lot of calculation time when instance numbers start getting into the hundreds of thousands. So the Randomize method combined with Collision on, is more suited for scattering things that really do need to avoid overlap but are limited in number, like big/medium rocks, shrubs etc. Smaller forests can also use Randomize + Collision as two trees right next to each other looks weird.
- When creating things like a lawn with the MXS References from the VIZPARK Real Grass bundle, try to avoid too much overlap between references as this will slow down the rendering. Just have enough overlap to avoid any apparent holes in the lawn. In general, the less overlap between instances, the more efficient the render.
This example uses trees and grass from the Real Trees I and Real Grass bundle. The Skatter camera clipping feature was used to keep the number of instances down to only what the camera sees (which makes sense most of the time), “Uniform” distribution for the trees with 50% Jitter, and also Collision detection with the “Size multiplier” set to 25%. So this shrinks the collision “trigger” to be only 25% of a trees bounding box, making for a thicker forest.
This created about 33 000 trees and 35 000 grass objects so generation + export time was really very short. Just to keep the viewport smooth I did put the trees and grass on their own separate layers and hid them until export time.
Not forgetting Maxwell Studio and its scatter tool
It’s worth mentioning that the MXS References are still very useful for those of you who don’t use Sketchup + Skatter, and only have Maxwell Studio to create Maxwell scenes. The albeit simpler scattering tool available in Studio can still be enough in many cases for scattering MXS references to create a lawn or a forrest on a piece of geometry.
I have to say I really enjoyed using Skatter, you almost don’t need a manual to understand what does what and it still offers sophisticated options including filtering based on geometry height or slope, camera view/distance, painting scatter areas, and a very easy workflow for creating your own presets.
I also wanted to show with this post that the Maxwell MXS Reference functionality works great with Skatter and so even though VIZPARK doesn’t have native Sketchup Maxwell files, they aren’t really needed because we have the MXS References which work with any Maxwell plugin. All their collections are in effect already compatible with Skatter and Sketchup + Maxwell.