[HOU-1839] rayserver instancer speed

[bdancer]

> oh, this happened by accident in the example scene. the productionscene should have just on packing level (but I'll check).

One pack level is usually a rayserver, then copy to points makes one more rayserver for point instances.
I've pushed a fix to not make a raysever if pack level has no instances.
So, time should be almost the same now (but still slower a bit).

But if you actually have nested copy-to-points, it'll be slower and there not much could be done (but I'll try to find some ways for sure).
You either use a lot of RAM without rayserver or use rayserver and things will be slower.

Basically, you could count RAM approximately like that: 1 instance with rayserver take ~168 bytes, 1 instance without rayserver take minimum (depending on instanced geometry) ~800 bytes.

Only rayserver supports true nested instancing. For example, if you have 2 levels of packed copy-to-points (lets say 10x10 and then 10x10 again), deeper level will become 1 instance for the upper level so you'll have 100 instances of 10x10, while for non-rayserver case you'll have 10x10x10x10 and that's where RAM will grow...

[ronald_a]

Thanks for the explanation. That's very good to know.

If the fix is in tomorrows build, I will give it a try right away. I'm a bit worried, that I will need to go over two million instances, so I'll take anything that will bring down rendertimes in case I need to use rayserver. I will have no nested packed primitives for this project - but maybe the next one

Do I understand correctly that this is also a NUMA related issue as well?

[ronald_a]

Hey bdancer , just tested the new build and it is awesome. On the NUMA machine, total frame time is even a couple of seconds LOWER WITH(!) ray server than without even with just around one million instances!

Unrelated to this topic I do however experience problems with uvmapped textures in the scene which seem to be completely off in placement compared to VFH [Info] * Build number:7023 hash:9561d9f from 28 Apr 2020 05:03.

[Gosho.Genchev]

Hey, ronald ,

the UV issue was fixed as well starting with today's builds.

Hope that helps!

[ronald_a]

Thanks for letting me know and I'm already using today's build. The instancer's renderspeed issues also seems to be fixed for now as long as we use only one level of packed primitives. It would be great if speed could also be increased for deeper hierachies as I am sure we will come accross this sooner or later.

[racoonart]

Sorry for digging out that older thread but I have a few questions about the rayserver and this seemed to be the best place to ask.

I have an enviroment scene with about 14k scattered instances (1-level deep packed primitives via copy to points sop).

When I render with rayserver turned off:
- it takes around 1 minute for startup
- 6m58s for rendering the frame
- over 40 gb ram usage

When I turn rayserver on:
- startup is almost immediate, around 5s
- 6m40s rendertime
- around 25 gb ram usage

So, I tried to find more information about what the ray server does but apart from some scattered information in the forum and a few details about bytes per instance I couldn't find much (even less in the docs). This seems to be a crucial switch for instancing so I am a bit surprised, especially due to this:

3. There is no need to use rayserver for 24K instances, those could be easily rendered without; rayserver should be used for >1M instances which may simply won't fit in memory (on most machines) using "non-rayserver" instancer.

As I said, I have just 14k instances, and the difference in startup and ram usage is quite massive, so I might be missing something here.

[ronald_a]

rayserver will in most cases (if not all) use less ram and almost always start up faster. As long as you only have one level of packed prims, there is really no reason (that I know of) not to use it . It's another story when you have multiple levels of packed primitives, because then, rayserver in its current state will render a lot slower (we are talking x3 to x5 and more). it will still start faster and use less memory. I hope in the future, this limitation will be lifted.

[racoonart]

Thanks ronald!
It may be worth doing a bit more "tutoring" on that in the docs then. I only stumbled upon it while looking through the vray obj properties due to the long startup times. And I only found it odd because I am used to different behaviour from vray in max with those numbers of instances.