Phoenix FD RAM usage in 2017

[crimea]

Hi.

I've already sent a detailed support message to you guys a week ago, but haven't heard from you, and we are getting very tired of this as it is basically making phoenix useless for us.

The issue described in the message through the technical support feature was this:


We've been using Phoenix FD for our vessels in ocean animations for a couple of years now, and recently upgraded our machines from max 2014 to 2017, and upgraded phoenix and vray as well. Phoenix went from 3.00.01 to 3.04.00, but we have a big issue with this newer version where the ocean subdivs don't do as much, yet make the horizon terribly noisy, and makes it use much more system RAM, to the point where it's impossible to go as high as we used to. Look here for a comparison:
https://imgur.com/a/Q8hOW

Has this been fixed already in some version? Are we the only ones getting this result?

Here's a summary of some more tests I did:

3ds max 2014
Build 3.00.01 (official) (September 13 2016)
PHX sim box made in 3.00.01
ocean subdivs 12
render window memory used: P:21000M V:22000M
system memory used: 30GB
(Looks good, and uses little RAM)

3ds max 2017
Build 3.04.00 (patch) (June 09 2017)
PHX sim box made in 3.00.01
ocean subdivs 8
render window memory used: P:32000MB V:73000MB
system memory used: ~55-60GB
(Looks bad, and uses too much RAM)

3ds max 2017
Build 3.04.00 (patch) (June 09 2017)
PHX sim box made in 3.04.00
ocean subdivs 5
render window memory used: P:28000MB V:32000MB
system memory used: 32,5GB
(Looks very bad, and uses OK amount RAM)

3ds max 2017
Build 3.04.00 (patch) (June 09 2017)
PHX sim box made in 3.04.00
ocean subdivs 8
render window memory used: P:41000MB V:44000MB
system memory used: 80,2GB
(Looks bad, and uses too much RAM)


Thanks.

[Svetlin.Nikolov]

Hey,

I'm sorry Support didn't manage to get to your message!

Can you please try a very latest nightly build of Phoenix and check the RAM usage there. Also, what is the Horizon Roughness value you are using? It was separated as a new parameter after 3.00.01 and controls how noisy the horizon is. Also there were several issues fixed with the way the ocean subdivs work in animation and with a moving camera, so finally their value in 3.04 does not correspond to the value in 3.00.01 and must be lowered in order to get the same poly count (and RAM usage). If this doesn't help, would it be possible to send over a scene which we can profile?

Thanks!

[crimea]

Hi.

Thank you for your response.

I can't see the phoenix nightlies on the site with the other nightlies like vray for blender. Could I get access to post in the regular forums also? Regarding horizon roughness, I did try using this as well, but all it does is make the horizon look like a mirror if raised, and if lowered it starts looking like 3.00.01, so it doesn't help too much.

Thanks.

[Svetlin.Nikolov]

Hey,

Check this here: https://forums.chaosgroup.com/forum/...nightly-builds

Note that 8 and 12 subdivs are huge values - this means that each screen pixel will produce 8x8 polys in the ocean mesh, and 12x12 respectively, which is why the RAM usage rockets. Using 4 to 6 should be enough and using more V-Ray subdivs would clear the noise on the horizon. One of the issues in 3.00.01 was that the actual subdivs were capped and from a certain point on increasing them did not make a difference, which caused some incurable flickering of the near part of the ocean.

Please ping me after you check the nightlies - there were a couple more issues fixed with the ocean subdivs since June, and if possible, send over a scene and we'll see what can be improved

Cheers!

[crimea]

Thanks, sent support a mail.

For those tests I was using 1-16 image sampler subdivs at 0.01 noise threshold, which is better quality than we often render with in production.

I did a new test with with 1-32 @ 0.005, but this didn't help much, and is way overkill in terms of sampling everything else. Ocean subdivs at 8. The sample rate pass even shows green in the horizon, so would need much lower noise threshold, but that would for sure slow everything else down way too much.

Also tried with horizon roughness of 0.2 and ocean subdivs at 5 (same image sampler settings above), but near the horizon - not the actual horizon, it was still too noisy with this darker type of noise as in the images in the first post. With the horizon roughness at 0.2 the horizon disappears too much also.

I will test 3.40.00 with 3ds max 2014 just to see if I get the same things happening there, and give nightlies a go afterwards, and after that I will post scene for you to try out. Does that sound like a good plan?

Thanks again!

[Svetlin.Nikolov]

Roger that! In case we aren't able to replicate the results from earlier versions with the latest one, we have to do what's needed to find what needs tweaking or fixing - thank you for raising this and sorry for the inconvenience!

[crimea]

Tried 3.04.00 in 3ds max 2014, and it produced sort of a mixture between [3.00.01+2014] and [3.04.00+2017]; the strong dark noise was gone so that was great, but RAM usage shot up again. So, best result with 3.04.00 was a not that greatly defined horizon and too smooth waves.:

https://i.imgur.com/LuK2Y0l.jpg
https://i.imgur.com/PBJ7xyo.jpg

Still waiting for nightlies access for phoenix builds, only have vray.

Another thing I was thinking about, max 2014 has vray 3.4 installed, while max 2017 has vray 3.6 - this might be worth testing, or?

Also, I forgot to say, but the same dark noise and RAM issues do occur when using pure ocean as well. However, if I just make a plane with vraydisplacement modifier with ocean tex, then it looks perfect and uses reasonable amounts of RAM.

[Svetlin.Nikolov]

Ah, yes - the V-Ray version is a very important factor - ocean rendering has changed several times due to changes in V-Ray.

Pure ocean versus simulator + ocean should look the same way indeed. It's also expected that the vraydisplacement would really look the best possible way and use the least amount of RAM since it's procedural and exists dynamically only during the rendering, while the ocean mesh is baked at pre-render and is left for the renderer to deal with. We have to implement isosurface rendering not just for a container, but for the ocean as well - this way we'll be able to get the results of the vraydisplacement, combined with a simulation container blended with the ocean, lower RAM usage, but potentially lower rendering speed...

I'm running some tests at the moment as well and will see how to improve the horizon...

[crimea]

Thanks for looking in to it. Do you still wish to have a test scene that showcases the issue?

After some more testing, I've found that it's something to do with reflections that's causing it. If the reflections have a lower glossiness like 0.85 the problem fades away. Currently I'm experimenting with blending a 1.0 glossiness water material with a ~0.85 glossiness water using a falloff. It seems to produce nice results, but it takes a bit longer to sample of course.

Also, newest phoenix nightly made the issue area look 10% better in the pixels closer to the camera, but didn't fix it unfortunately.

How to proceed? Just make a test scene for you?

[Paul Oblomov]

Are you using ggx ? Try blinn.

[crimea]

Hi Paul.

I've tried all of them except ward, currently settled on blinn. Also many of the other settings like glossy fresnel, cut-off, turning off transparency, reflect on backside, double-sided, but only thing that has had any great impact has been lowering reflection glossiness.

[crimea]

Ok, scene attached. Also attached what it looks like when I render.

[Svetlin.Nikolov]

Thank you, I hope I'll have some good news soon

[crimea]

Me too Looking forward to what you find.

[Svetlin.Nikolov]

Hey, so a few notes:
- Reflection Glossiness ~0.84 really seems to suit the horizon better than ~0.9 or 1.0 - I even changed the ocean preset to use it as a default for tomorrow's nightlies.
- Turned on Refraction in your liquid material as well, and this allows to enable fog color as well. However, note that if you choose to use fog color in a V-Ray mtl, you should not use an open geometry sheet such as the ocean. This is why I plugged a VRayPlane underneath the ocean and set it to black diffuse. Without this, underwater foam coloring would not work - you will get the liquid mesh to render the exact same way, but the underwater foam will always remain white and will not be affected by the fog color until you close the volume with a plane (or just use a closed volume, but for the ocean I can't think of another way to do it). This is also new to the Ocean toolbar preset from about a month back
- Turned off the Horizon Roughness completely - we've introduced this parameter for compatibility with old scenes, but I don't think it produces good results and furthermore its effect varies drastically with changing the render resolution.
- Boosted the Ocean Tex's Level of Detail to 25. This will bring back the detail in the near ocean areas. This is another important change since 3.00.01 - it's added for cases where you have a strongly reflective ocean surface with objects dipped into the ocean and a moving camera - in these cases a very strong detail causes unpleasant flickering, so now by default the Ocean Tex with LOD of 10 produces a little less detail than before, along with the other fixes that went into this problem.
- And for the sake of completeness - the Ocean Subdivs were capped to 2 in 3.00.01 so no matter how high you boosted them, the RAM usage would not skyrocket, so now after this limitation is removed, 5 subdivs really mean 25 times more polygons per pixel..