Can we have a higher particle limit, please? (and procedural displacement)

Hi!

I just rendered this planet with 2.2 million asteroids. This took around 4 minutes and it only used 1-2 GB of RAM, even with instancing. As you can see in the file, my problem is that in order to get that many asteroids, I needed to copy the particle spline more than 20 times and edit the random seed manually for each.

Could we just up the limit, please so we can have like 100 million particles? There are macs with over a TB of RAM now! :)

another problem I'm having is that the day/night edge of the planet is too sharp and I don't have mountain shadows.

How can I use the bump map for procedural displacement? I know there's the displacement modifier but I can only feed a texture into it, but I want to feed the material's (procedural) bump map instead.

Many thanks!
 

Attachments

  • PlanetTest2.zip
    109.5 KB · Views: 161
  • Screen Shot 2021-03-27 at 9.24.25 PM.png
    Screen Shot 2021-03-27 at 9.24.25 PM.png
    225.9 KB · Views: 188
  • planet.jpg
    planet.jpg
    456.8 KB · Views: 190
Last edited:
* I experimented with a single particle mesh (plus 3 nodes) on a flattened torus.
* Subdividing a standard torus x6 gives some 2 million polys (=> particles).
* Which is approximately what your population of asteroids is.
* Of course, increasing the sections of the torus blows out the number of asteroids in the PM.
asteroids.png

* If you need >1 rings, either use n tori or base the PM on selected poly selections of the base torus.
 
Last edited:
For the Terminator issue you'll need to adjust a decent "Softness" value at your light source/Shadow and for a more "bumpy" look you can bake the planet texture and take the "composite-node" to mix the result with your bump - which makes it a pretty workload if you're planning an animation. I increased the light a bit:
Terminator.gif
 
How can I use the bump map for procedural displacement? I know there's the displacement modifier but I can only feed a texture into it, but I want to feed the material's (procedural) bump map instead.
It's not possible yet, but you can bake a procedural texture to an equirectangular map and then use it with the displacement modifier.
The default sphere UV mapping is already compatible with the modifier so there is no need to unwrap, just bake to UV1.
 
Last edited:
Ok, This worked!

Although I would really prefer to do this via the material in the renderer only without having to do this bake, since I need a crazy amount of polygons to make this look good. To have good detail, I set the divisions of the planet to 250/250 and used a subdivision modifier with 5 iterations, resulting in over 32 million polygons for the planet alone that are displaced by a 4096x4096 texture o_O I had to turn it off in the viewport because this eats my GPU (Vega 64) for breakfast and makesCheetah 3D pretty unresponsive.Once in the renderer, it works quite well, though.

Next, I'll figure out a way to add an atmosphere. :D
 

Attachments

  • planet2.jpg
    planet2.jpg
    371 KB · Views: 182
I'd go a different way by using the particle emitter setting up a birth-rate of 100k from an emitter: Mesh which is just a few polygon rings. Let it run for ca 3 sec. The asteroids shape is a tiny "Tetrahedron truncated"Polyhedra; Make sure to decrease the Display➝Visible to a very low value to maintain camera transformations.

AlienPlanet.jpg
 
Oh, that works too! I used a particle spawner for a different project but that was for things that were moving on only a single axis. Didn't know it worked via mesh too!

This wouldn't work for rendering an animation, I suppose since the asteroids already need to be in place, though.

I'm having a problem with the animation now. Rendering an animation at 1280x720 with 2 samples per pixel right now. The rendering of the frames itself is very fast (only a couple of seconds) but there is about a minute in-between the frames before it starts rendering a new one.

It seems to me like Cheetah 3D is setting up the geometry anew for every frame instead of changing the camera transform (the only thing that's animated in my scene). On my 8-core CPU it uses all available CPU only while rendering and sits at a little over 100% CPU (single core) while switching to the next frame.
 
Last edited:
Ooh, that's useful!

Still have to figure out how to render this faster. my CPU usage chart looks like this
 

Attachments

  • Screen Shot 2021-03-29 at 5.20.23 PM.png
    Screen Shot 2021-03-29 at 5.20.23 PM.png
    378.2 KB · Views: 180
That's a strange behaviour: I rendered 60 frames/2 samples full HD in 90sec:
PlanetAnim60frames.jpg

This is the max res for this forum:

AlienPlanetsmall.gif
:eek:

Another method to render partially animation is to move/adjust the scroller at the timeline:
PartialAnimation.gif
 
Last edited:
Did you tesselate your planet?

I just tried the same scene on a 16-core Mac Pro and it's the same problem. (just slightly faster because when it actually renders the frame it's over twice as fast as the 8-core iMac pro, but the switch between the frames seems to be single-threaded).

When I reduce the amount of subdivisions of the planet, it's much faster. It really seems to be the number of polygons that are being prepared for the scene.
 

Attachments

  • Screen Shot 2021-03-29 at 8.08.59 PM.png
    Screen Shot 2021-03-29 at 8.08.59 PM.png
    362.1 KB · Views: 166
Ah - thanks, found it: The green part is the 90sec render of the animation from above on an M1 MacMini:
CPUhistory.jpg
 
can you check what happens when you create a sphere with 250/250 divisions and put a subdivision modifier with 5 iterations on it (disable it in the viewport before you apply the modifier, otherwise cheetah 3D will be unresponsive)?

If I render an animation with that the time between the frames gets very long and I think it might have something to do with the fact that the subdivision modifier's integration property is animatable and it doesn't cache the geometry.

I feel like the ability o directly to displacement via the material would potentially help with that.
 
Last edited:
I do not see the need for this approach as my 65k planetary sphere works already fine with a decent bump map and no terminator image visible. Sorry. I tried with 250x250/level 4 SubDiv and with just 16GB unified Ram Swap started to get used and I'm not comfortable doing so.
By no means this is a practically workflow you'll find in an animation studio I believe.
 
Yeah, I think the better workflow would be to tesselate on-demand based on what's in view and the distance to the objects, but I don't see a way to do this in Cheetah 3D. (This can even be done on the GPU using tessellation shaders).

What I could do is chop the planet up into separate LODs manually based on where the camera moves.
 
Back
Top