What's causing fussy detail in my smoke sim?

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!

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.

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

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 :slight_smile:

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.

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.

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 :smile:

#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

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

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

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

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 :slight_smile: 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 :wink:

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…

Well I’m proud of phx. It is great, that you have that many user feedback. Can you please tell something about recently added user requested feature ?

Btw - I thought the opposite - requesting the feature again and again by different ppl should rise the priority, not lower it. I think paid plugin community has some rights :wink: Also, I think you underestimate your collegues ability to participate in all that forum/vimeo/linkedin requests. You are not alone!

Or you’re…

Of course votes from different people add up. I’m sure you are aware of the latest Phoenix developments, but there are the 3.12 new features from November, all of them by request: Chaos Docs. Instancing and X-Ref-ing for max were the tasks with most user votes in the Phoenix history every, so they naturally came first.

Since 3.12, we’ve been adding to the nightlies render elements for GPU volumetrics, because GPU rendering needs to be feature complete with everything available on CPU. We just upgraded OpenVDB from version 3 to 5 so we can read vdb particles which was also requested a lot (this would bring back your request for resimulating Phoenix sims over Houdini sims, that became impossible since Phx 3.0 because the FLIP solver needs particles for resim). There is now a new texture slot in the volume shader for modulating or replacing fire opacity, since so far only fire color could be affected by textures, and this is needed so we can completely deconstruct the volume shader into a more customizable set of units that can be connected any way you want - this is one of the most voted features ATM. Exporting vertex velocity to ABC for moblur from Max and Maya also had many votes and is now in the nightlies as well.

There is nothing on simulation in the above and there is a reason for this. Soon we’ll be doing some private testing on several new nodes that are not in the nightlies currently, involving some of the advanced Phoenix users who are good at giving clear constructive feedback.

I’m very sorry, John, for hijacking your thread. I hope I have shed some light on the dark mysterious ways of task prioritization not just for the ever-skeptical Paul, but for anyone interested as well :slight_smile:

Tho, I’m still sceptical, vdb particles is a game changer! Why you didn’t tell anyone :slight_smile:

It’s in the nightlies for a couple of days and I haven’t updated the nightly changelog yet.

Never apologize for anything Svetlin, your team is going lightning fast in the development and improvement of the product and I understand you only have so many resources to call on!