How much instances can I render?

[kiryha]

I am building a forest...

I have a 160 kb tree cloned with a Copy To Points node (packing enabled). The maximum amount of trees I was able to render with Mantra is around 13 000 which is the way less from what I was expected (7708: Fatal error: Segmentation fault).
So I wonder if its something wrong with my expectations or with a setup? I was thinking if I have a low poly count model I can populate much more dense forest, or it is more or less normal for my configuration?

Lenovo laptop with Win 10 x 64
Houdini 16.5
Processor    Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz, 2712 Mhz, 4 Core(s), 8 Logical Processor(s)
RAM 64 GB

GEO_CITY_22.hipnc

procTree_A_03.bgeo.sc

[LaidlawFX]

You should probably use the instanter node at the object level instead of the copy to point sop. In addition you should use a delayed load archive to to set up delayed load archives for your scene it may not be required, but it should help by keeping it in memory better. You should be able to render millions easily.  

[kiryha]

I guess the instancer node has the same math under the hood... I can recall some discussions about it here. How can I setup a delayed load archive? 

What I discovered, though. My tree is built from nested instances as well: leaves are copied across branches (packed Copy To Points) and branches copied across trunk (packed Copy To Points). That's why the source tree is only 160 kb.
But if I collapse nested instances to a geometry (which become around 20 Mb) the rendering is going fine and I can render way more trees. It's a bit wired for me! Anybody can explain this behavior?

[LaidlawFX]

The nested instances would definitely be an issue as that is a lot of calls per an asset.  That's definitely a X^# computation nightmare.

The math is similar under the hood for sop and instancer, but people tend to do very dirty things in sops as they don't understand how to work them, nor do they work with them cleanly. You can merge and do anything in SOPs, placing a pyro sim with a instance cloud. Being a CG janitor for years I have seen people screw that option all the time. Generally it never happens in Object Instancer setups. You can then tweak the render settings on your render engine a lot more efficiently. Even though you can do something doesn't mean it's the best method.

To set up the Delayed Load, if you are using the object instancer. In a material net drop a Delayed Load Procedural and assigned your flattened geometry. On your instanced geometry node go to Render > Geometry > Procedural Shader and assign the shader. What this should do is load the object into memory only once like a packed geometry, but as the render buckets move into say a blank area it will drop it from the memory. Or in the case of more tree types you would only load the geometry you need. Additionally you can balance your render tree and bucket sizes to compensate. In some case you may just want to brute force and have it loaded once in memory and not drop it ever as the loading and unloading to memory will cause more time than it's worth. 

 

[kiryha]

12 hours ago, LaidlawFX said:

The nested instances would definitely be an issue as that is a lot of calls per an asset. 

 

This is very wired and counterintuitive... Such setup works great in MtoA for example... Anyway if collapsing nested instances works, let it be.

My next issue with the forest — scene generation time and HDD space: 

Time. Is it possible with Apprentice to bake forest once (like export to *.ass with Arnold) and use this in my scene instead of generating it each time I render? Is it IFD workflow (I did not get if I can use it with Apprentice license)?
Space. As far as I understand, if my instances do not fit in RAM, they are saved on disk (C:\Users\kiryha\AppData\Local\Temp\houdini_temp\ifds\storage\*.bgeo.sc). The files are huge and I am out of disk space. Can I change this location? 

Can I setup Delayed Load with Copy to Points instead of instancer? I Don't want to use instancer because I need to bake it somehow on disk and load in my HDA.

[kiryha]

Also. If I use Copy to Points inside For Loop to clone several different trees, I can't render too much as well. If I merge several Copy to Points nodes, I can render easily 100 times more. 
Am missing something here, or its limitation of the loop?

Edited November 13, 2018 by kiryha

[LaidlawFX]

3 hours ago, kiryha said:

This is very wired and counterintuitive... Such setup works great in MtoA for example... Anyway if collapsing nested instances works, let it be.

Collapsing the amount of calls is a very old fallback, still used in optimized renderers like game engines today. Generally it's done in a pre-compile pass with out one's knowledge. I'm guessing MtoA is collapsing a bunch of those calls under the hood if you are actually instancing leaves on top of instanced trees. Are you using another plugin to actually set those up, or are you doing exactly as described? Mantra is smart, but since it has a lot of flexibility you can still make it choke quite easily.

3 hours ago, kiryha said:

 Is it possible with Apprentice 

Not sure about the ability with apprentice on something of this scope. So there could be limits I am not aware of.

3 hours ago, kiryha said:

My next issue with the forest — scene generation time and HDD space: 

Time. Is it possible with Apprentice to bake forest once (like export to *.ass with Arnold) and use this in my scene instead of generating it each time I render? Is it IFD workflow (I did not get if I can use it with Apprentice license)?
Space. As far as I understand, if my instances do not fit in RAM, they are saved on disk (C:\Users\kiryha\AppData\Local\Temp\houdini_temp\ifds\storage\*.bgeo.sc). The files are huge and I am out of disk space. Can I change this location? 

Can I setup Delayed Load with Copy to Points instead of instancer? I Don't want to use instancer because I need to bake it somehow on disk and load in my HDA.

You can batch your environment into as many chunks as you want to best feed it to any engine. Whether your delayed load is a single tree or a cluster of trees just depends on your environment. Pre-baking into different IFDs(same as .ass) will help load issues for sure. How you batch that is up to you and varies per a scene. The Delayed Load is a pointer file for those pieces of geometry in the final .ifd for the scene. You can look at the ifd for the scene and see the actual path to that file as opposed to the geometry in the ifd. If your ifd is larger than a few mb you can tell you'll have issues already. Make sure you convert your incoming geometry into a native file format like .bgeo so it does not need to process it at render time. You can use a Mantra Archive if need be that will pack the materials and strip the attributes, too. You can do this in SOPs, too. .bgeosc will be the fast and most compressed for mantra. Make sure you are not using fbx or .obj as it will need to do conversion each time. You can also use alembic delayed load to avoid this conversion issue too. 

Anytime a computer program can not keep the process in RAM and has to save it disk should be a large warning flag. When a program goes from RAM to saving on disk process time will jump dramatically. So you need to balance your processing load correspondingly. You can change the $TEMP and $HOUDINI_TEMP_DIR to an SSD drive, but like I said if you are fallign back on that it's a bit worrisome.

One of the things with time may be the density of the meshes in the scene. You may want to use some LODs. A render engine can reduce one large poly to a pixel easily, but a large number of polys in a pixel it will take longer to process. From games processing of forest what type of density do you have in your leaves is important. Are you leaves 100points, or only the bare minimum for the shape. Also are you using Alpha or Opacity to handle any texture based leaves? Opacity means more tracing. Which leads me to another culprit on time. I take it you are using an environment light for the scene. I would say check how many samples your are sending out from the light and mantra to get the render smoothness. One really dense meshes this can eat up more time.

I actually do not know if you can use delayed load on copy to point. But you can use the instances attribute on your points to point to a any object that has the delayed load shader assigned to it. I'm guessing the Delayed Load may not be the final answer. You could actually be having a few other problems too. I admit I did not actually look at your scene file

[LaidlawFX]

Looking at the scene file, having depth of field, motion blur, pixel samples set to 8 by 8, diffuse limit to 1, on your ROP will slow it down a bunch. You should balance your samples more.

Your tree is insanely dense at 106,318 prims when fully unpacked. You definitely need to do a second pass at your assets. Your instanced tree for a forest is not a hero tree. Even for a hero tree this is way too dense. You'll certainly want LODs too. Especially for the dense part of your forest. It's not surprising at all why it is taking so long to render.

[kiryha]

I even did not come to a rendering time, all it was about generating a scene and starting render. With For Loop node I was not able to start rendering, using just Copy To Points solve the issue.

I wonder if I can use several models with SOP Instancer? Can I export to bgeo the result of instancing (bake the forest)?

> is insanely dense at 106,318 prims
Well... There are a lot of forest renderings is being posted every day, when they use Evermotion or other models (way way more heavy) with an insane number of polygons and copies... And all this working fine. I was thinking these days we don't care about polycount too much.

[merlino]

I think you should use an Instance node for each tree model. I just rendered 133.000 trees with no problems, unpacking the geometry. Also you shouldn't set mantra parameters that way, it's not the way to go. You should put the pixel sample on 3x3 and work on the "noise level", and increasing the Max Ray Samples. For example: I use to render just a square of my frame (Shift+LMB on the render view) and check the render time, than lower the "noise level" and increase the Max Ray Sample searching for a compromise between render time and quality. Sometime I use 27+ Max Ray Samples (still with 3x3 pixel samples) as final quality. You should play with that.

[davpe]

here. your scene rendered in 6 minutes on my laptop, with close to zero startup time, and consumed 700 mb of ram.

what I did - first of all, the reason for your high startup times and crazy memory demands were actually nested packed primitives. nesting itself would't be an issue if you weren't nested thousands of packed prims... that actually makes packed geometry more expensive than rendering just plain meshes. just have one packed prim per tree - or maybe two if you want to separate leaves and wood. so if you unpack completely your tree and pack it again as one primitive, you should see much better performance.

another thing is your render settings were completely overkill in some points - like ray limits. with trees or very detailed geometry i find having pixel samples quite high as needed so 8x8 is fine, but setting ray limits to zero made almost no visual difference (in this particular render) and renders faster. you don't necessarily want to have zeroes in ray limits at the end of the day, but point is to cut it as low as you can (and what you've had set there was definitely overkill for this king of rendering). also, rendering a depth of field is something I have never seen done on any project in any vfx house. very expensive to render, and if you don't get it right you have to render the whole thing again. maybe in some very special case renders it makes sense, but generally you do that in comp.

regarding instancing in general, i don't think instance object is any faster than copy SOP in it's essence, as a few people mentioned here. it's just that copy SOP gives you more freedom to do stuff and that naturally leads to longer cook times. instance object simply forces you to obey the most efficient workflow. copy SOP in loop is actually the most efficient workflow if you need more than just a bunch of static objects distributed over the points. but if you do a very simple instancing like you do in your scene it actually doesn't make sense to use loops as you're not using any of it's benefits. (but still I haven't found it slow to cook, it was like maybe a half of a second??)

[kiryha]

I ended up removing nested packed primitives, but the main reason of issue was Copy To Points in the loop (I don't know another way to copy different assets). When I get rid of the loop (use separate Copy to Points for each tree variation) I got my render.

Do I have secondary lighting with diffuse limit = 0? I thought no. Between 0 and 1 huge difference....

[davpe]

i disagree with you. render the attached scene. copy sop in loop, frame finished in 6 mins on my laptop.

yes diffuse bounce made a big difference. it depends what you need thou and you don't always need it for aerial shots like this. many times I successfully used a trick with another lowres enviro light with low importance sampling - so it's super blurry but it still retains shadows of bigger shapes - this makes a great job bringing dark areas up. if you're far enough nobody can tell whether it's a fake, and it renders super fast, plus you have extra control over your contrast levels. of course it depends on many factors if you can use that trick or not - you just may need that bounce to make it look right sometimes, but for wide shots with many tiny details this can be very useful. just saying

[kiryha]

You mean my scene, GEO_CITY_22.hipnc? I am not able to render it at home, not enough memory (copy only one tree)... will try at my laptop tomorrow again. But I am pretty sure it would be the same, that's why I post it here

[davpe]

oh sorry, i forgot to attach that hipfile. will do once i get back to my desk. i just rewired your setup a bit and it really isn't any slower.

[davpe]

the hipfile

GEO_CITY_22_loop_fast.hipnc

[kiryha]

Correct, your scene is rendering at my PC! But I can't understand what did you change to be able to fix mine. I notice only material assignment, but I don't need it in this case, I can assign one material after the copy to points.

[davpe]

well as I said... packing trees into 1 primitive helped a lot. and then i don't think you can assign a material to packed prims. it's best if it already is a part of packed geo. there are ways how to post-apply materials to packed geo, but doing what you did does not work. i don't know thou why it had such a huge impact on render startup time. i would simple expect it will not work and you'll get a blank material render or something... in any way, don't do this  if you absolutely need to apply material to geometry that already has been packed you can use material stylesheets (this can also result in poor performance with big shots, so be careful) or there is Edit Packed SOP (haven't used this one much so not sure about possible performance penalties). anyways, the best thing is just to have materials packed together with geo and then maybe do in-shader variations per instance if this is what you're after.

cheers.

[Atom]

In these cases, it may be better to use the instance node, as Merlino suggests, instead of the CopyToPoints. This makes it more compatible with other render systems. Using this setup you can render both to Mantra and Redshift. With the previous setup if you try to render to Redshift, it will try to make a giant piece of geometry out of the CopyToPoints result which can easily fill up a 32Gb machine. If you use the instance node, both render systems hang out around 4GB or so.

ap_instance_forest_122228.hiplc

Edited December 22, 2018 by Atom

[goldleaf]

You could try PolySoups + Packed Prims to efficiently get super high geometry counts.

One of the SESI devs did that to render a trillion cubes: https://www.sidefx.com/forum/topic/30134/#post-138595