Slow modifier stack performance

[Anonymous]

i am testing some stuff with volume select and subdivision  and am having very bad performance as soon as the subd reaches a certain level:

- if i dont use the volume select but just subdivide the whole geometry, viewport performance is great. seems like the object is cached im ram.

- if i try to subdivide the volume selection which is then defined by a moving object, the framerate dips to single digits without my cpu being maxed out.

my question is:

is this an issue of modifier stack not being multithreaded?

[Anonymous]

fwiw it definitely seems that volume select is the bottleneck here.

whenever i use it on a slightly denser mesh, the framerate of movable intersecting objects is disastrous.

so this thread title can aswell be read as "volume selection slow performance".

is there any chance of having a fix here?

[jon.bell]

Hi Denis,

I wanted to follow up with you on this issue. Were you able to test this further and see if the slowdown manifests just with the Volume Select modifier, or does it seem connected to other modifiers as well?

In addition, do you have a test scene you could send us, or reproducible steps that we could test in our offices?

Please let me know, and I hope to hear from you soon.

Best regards,

Jon A. Bell

Autodesk Technical Support

[Anonymous]

hi jon,

many thanks for picking the thread up.

appreciate your interest alot.

i have infact made further tests and can send you some files.

however this video from thinkbox shows the problem in the best possible way. it is exactly the issue i am having:

https://www.youtube.com/watch?v=zZio0PE5UE0

it is also the workaround i am demoing atm. 

the genome modifier does a far better job so i dont have a choice but to get the plugin if i want to get things done.

it just appears that native volume select is one of those legacy modifiers that apparently is not multithreaded.

the meshes chug at 4 fps while my cpu and gpu remain at 10% workload.

obviously things would benefit from some optimizing.

thank you,

d

[Anonymous]

this thread got buried quick. i hope no one minds pulling it up.

it would be nice to know if there can be some improvements with volume selection modifier or is it bound to stay in the state it is.

its one of the basic issues again where we have to buy third party plugins to have a well functioning software.

[Anonymous]

---

@Anonymous wrote:

this thread got buried quick. i hope no one minds pulling it up.

it would be nice to know if there can be some improvements with volume selection modifier or is it bound to stay in the state it is.

its one of the basic issues again where we have to buy third party plugins to have a well functioning software.

---

No sorry, it`s not possible. You know Thinkbox software has this secret magical algorithm that makes Genome ultrafast.Unfortunatley the don`t wanna share it with the rest of the world. 😞

Seriously, what kind of answer do you expect and from whom? Can it improved in performance and functionality? Of course it`s possible.Will it happen?

Yes, if there`s enough demand for it.

[Anonymous]

"Yes, if there`s enough demand for it."

hence my mentioning it and not letting it drop off. 

any other suggestions, other then this wonderful cynicism you have going there?

[jon.bell]

Denis,

This thread has definitely not been buried -- I've reviewed your comparison video and have logged a defect in our developer database ("Volume Select in 3ds Max slow compared with Genome Plugin.")

I'll be alerted if there are any changes on this, and will let the community know. Thanks again for your help.

Best regards,

Jon A. Bell

Autodesk Technical Support

[Anonymous]

---

@Anonymous wrote:

any other suggestions, other then this wonderful cynicism you have going there?

---

Sure, keep one of the  participating mesh objects as simple as possible. Either the selecting mesh volume or the underlying mesh

I think in most setups the selecting mesh volume can be simple and the mesh with VolSelect more complex.

Try to add complexity AFTER Vol.Select. For example by using Turbosmooth or Tesselate.

Stay away from editablePoly and especially editPoly in the stack. Strictly use editableMesh for better realtime playback.

If you use Turbosmooth on top of the stack: Turn it off completely->Rightclick->Off in viewport.It effects interactive performance even when Iterations are set to zero.

In 3dsmax2017 for example  1k vert mesh volume intersecting  a 80k vertices mesh get me 25-30fps. Depends on hardware of course.

CPU usage is 30%

edit: It was with a 80k mesh plane i was testing. Sorry.

[Anonymous]

so your answer to my lacking high poly mesh performance is not to use high poly meshes? your really think i am cranking up the polycount for the hell of it?

here is the deal:

i am rendering some landscapes in octane which does not have rendertime subdivision. what you see in viewport is what you get poly wise.

obviously scenes get heavy really quickly and the only way to deal with the memory cap is to have only the visible portion of terrain in higher subdivisions.

i am using a camera with a simple mesh gizmo as a parent. this simple mesh also defines the volume select region.

the setup works and everywhere the camera looks is subdivided. once the camera moves however, things grinds to a halt.

the cpu consumpiton stays low so there is a need of optimizing here.

i would use opensubdiv with gpu function but placing any modifier over it does not work.

also it sucks that only meshsmooth has the ability to subdivide select portions only, which is the whole point.

have not tried tesellating. maybe will give it a go.