What's causing fussy detail in my smoke sim?

[joconnell]

Hi Svetlin!

I've gotten some really useful stuff out of phoenix recently but there's a few more things I'd like to improve further if possible. When generating clouds as per your static clouds tutorial,I get some lovely results but there's some very small broken up fussy balls of smoke in there too that I'd like to get rid of. It's kind of like we want 3 sizes of noise - the big overall silhouette shapes, the tiny bits of breakup along the edges and then some kind of middle size. The circles areas are too small and too frequent to look good, any ideas which parameter would be a good target to remove these? I've had some success bringing down the randomize amount but are there any other obvious things in there I'm missing?

Using build 3.12.01 - 2019011028833

Cheers!

[Svetlin.Nikolov]

Hey, summoning Hammer Chen who made the cloud setup. How does it look without the random noise? It would counter the conservation effect and indeed make the detail more uniform.

[joconnell]

Running it again with random 0 now then, back in 8 hours

[joconnell]

It'd be nice to be able to mask / vary these effects by other channels too - like having the randomize driven by vorticity for example so you'd have some way of localizing effects. We've talked about having various volume masking / calming options before which'd be great for fixing glitches or addressing client notes. We've a simple boat scene with the issue of waves building up at the front of a moving grid (scene coming over to you once it's cleared) which'd benefit from some masking controls but as you've said, you've a long list of things you want to do

[Svetlin.Nikolov]

Oh wow, why so long? How many frames is this simulation? If you are basing on the cloud tutorial, its idea is to burst out the cloud with a high discharge and this is compensated by high SPF. However, if you have lower source outgoing velocity, you can also reduce the steps per frame so they won't smooth out and lose detail of the sim. Conservation also seems quite low to me - with low conservation the sim won't roll that much and will not behave quite like a fluid, but instead will just spread out.

[Svetlin.Nikolov]

Ah, the ocean borders are high on the TODO list. I've found a couple of issues with ocean border conditions left from early development that must be rewritten, like most of the code left from Phoenix 2 and pre-release Phoenix 3 already has. I'm getting interrupted these last 2 days and can't get back to the ocean borders yet though. I hope to be able to work on them soon again.

[joconnell]

Brilliant, Martijn will be happy to hear about the borders! It's a 100 frame sim on my side, I'm also trying to offset a few discharges as clouds have newer and older areas so we can get a bit more variation by having old areas that can go through more dissipation and new areas that have lots of crisp detail!

Time to run some wedges

[squintnic]

#subscribing to this
I have tried a number of times to get clouds in phoenix (based on that hammer chen tut) but not quite nailed it yet and also have the finer detail issue

[hammerbchen]

Hi John O'Connell,

Here are the settings from my other cloud scene. The idea here is allowing cloud form naturally from a plane. Budding off from a plan naturally. So for those tiny details, it's better to let them form naturally instead of forcing them by adding too much noise to it. With that said, try to lower your vorticity, increase the Conservation quality. You might want to change your conservation type to PCG.

On the other hand, it's not just morphology; shader also plays an important role for a realistic cloud. And the intensity of your key light is also essential. You might want to increase your light intensity. The Phoenix FD's smoke scattering should set to Ray-traced. For (much) faster rendering, you can use V-Ray NEXT GPU for the Ray-traced scattering.


Best,

Hammer

[hammerbchen]

One more tip: you can run a sim with (relatively) small grid-res; them up-res by using Resimulation, with Amp. Method = Interpolate.

[Paul Oblomov]

Yeah, shader is a pain. I wonder, can we hire someone, to write the code.

[Svetlin.Nikolov]

Paul, you can hire anyone you want for anything you like However, is there anything specific you can contribute to this discussion in a constructive way?

[joconnell]

Thanks for the tips Hammer, I haven't tried any other conservation methods yet so I'll definitely give that one a go!

[Paul Oblomov]

Oh, Svetlin, I just want ppl to know, that no matter how good your cloud look like in viewport you can't match the look of real clouds. Don't you remember that "render disney cloud challenge" ? And while chaos guys don't think it is of high priority - I'm thinking of hiring someone, who can help everyone here in creating stunning clouds and atmosphere, since you just don't have ANY way of rendering film quality clouds with vray You think, that I should create another topic? Maybe it is a good idea, what you guys think?

I remember you said it will take two weeks to create that shader. So, we can approximate the price and now can go croudfunding platform. The problem is that writing simple osl code - we can't since it is vray limitation. So, it should be phx shader I suppose... It would be a great experience, since we're not a big guy like ILM or SIP or Weta with its own rnd team.

What you guys think?

And about your question - I was closer to the topic of the thread than you, with thoughts about an ocean borders

[Svetlin.Nikolov]

Now this is the right way to communicate. One last thing would be to agree on the specific request - you are talking about ray traced multiple scattering, correct?

I feel I need to talk to you about the Phoenix roadmap and prioritizing though. One thing that I assume is common sense is that me and my colleagues get input all over the place - facebook, PMs, youtube, vimeo, linkedin, skype, emails, as well as the supposedly official channels of support and forums. This is positive, I want to know about all issues and everything everybody needs. If the day was so and so hours long and the team was infinite in size, all requests would have been started work on immediately. Since this is not the case, there is prioritizing. Since less than a third of the communication happens on the forums, there are issues or requests we are working on that are never mentioned here. Aside from that, we have many ideas that are not requested, that improve simulation and rendering, and there are things not every user of the sofware could easily imagine or see available in other software. There has to be a balance between bugfixing, new features and missing functionality. There has to be a balance between improving the solvers and the rendering. There are things we are working on that are not in the nightlies and we cant speak about. There are also internal tasks like improving the build system, installer, preparing releases, helping other teams, fixing what has broken in Phoenix due to external changes, such as max, maya, 3rd party sdk changes, or vray changes. Some of this stuff requires days just to get the software back into the state it was originally, so it wont be broken.

Not everything me and the team does will be immediately visible. Not everything anyone requests will be done immediately, but it will be done eventually because obviously it's a win win for everybody to have the software as good as it can be or even better.

You have to understand that even though I track my time to the minute, I cannot always provide an account for what our short term or long term plans are to anyone outside the company. Once a request is made, either about a bug or feature, we reproduce and log it. Repeating the same request or blaming us won't change it's priority or make it happen sooner. Just the opposite - time I spend on the forums or being distracted by rude behavior is time Not spent writing code or solving problems.

Let's get some work done now...