Displacement taking lots of ram in certain conditions

[maru]

I am starting a forum thread instead of Mantis report because I think it is more convenient in this case, but just let me know if I should move to Mantis.

[based on helpdesk report]
scene: big lowpoly object with fine displacement, very high output resolution (let's say 5k x 5k)

Corona 1.1: the mesh needs to be subdivided manually, displacement is calculated based on screen size and max subdiv values - reasonable amount of ram is used in case of extreme subdivision as screen size is limited by max subdivs

Corona 1.2: no manual subdivision, excessive amount of ram is used as there is no max subdivs and Corona needs to do a lot of work to decide where the tiny subdivisions should be

Fix:
a) increase screen size at the cost of quality
b) enable filtering/blurring for the displacement map at the cost of some detail
c) leave all the settings as they are, but subdivide the mesh like in 1.1 to make it easier for Corona to decide how to subdivide the mesh (I think this is why it helps)

I think something like automatic "pre-subdivision" of lowpoly (low mesh density?) objects could help here.

In attachment is an example: 1 - lowpoly object, 2 - same object with subdivide modifier

[PROH]

hmmm... just tried a small comparison with the opposite result:

SetUp: Displacement screen size 1px, 1 Box 2x2x2m with Vizpark's "VP Berlin Aged Wall" (material from Corona site) - displacement in the material is disabled and the map is instanced to CoronaDisplacementModifier

Test 1 - Box parameter set to 1 for all sides. Test 2 - Box parameter set to 10 for all sides.

Now, I tried several angles and distances, and every time test 1 gives lower primitive count, higher Rays/s and slightly lower memory consumption. So maybe CoronaDisplacementModifier works better than displacement by material?

[romullus]

In V1.2 screen size may be set much higher than in V1.1 to get comparable quality displacement. I found that i rarely have to go lower than default 2 value with new displacement. If people out of habit set this to 1 or lower straight away, no wonder why they get much higher RAM consumption.

@PROH, try with box that has 3x3x3 segments - for even rectangular topology it gives least amount of polys with new displacement from my experience (6x6x6, 12x12x12, 24x24x24, etc works too) :]

[PROH]

Hi romullus. Thanks for the tip. Just tried it out, and 3, 6 and even 12 does give a lower count than 10 - and almost as low as 1. FWIW in this simple test 1 is still the fastest (only tried it with CoronaDisplacementModifier yet).

But thanks again for the tip.

[maru]

logged on mantis, no interest, so moving to resolved