With baked physics it works.
So now you are supposed to bake physics before rendering it. In previous versions, it was not mandatory to bake physics for animation render.

Maybe this helps:
I had a similar issue a few weeks ago, and somebody on blenderexchange gave me the hint: You need to Bake the physics before starting the render. Otherwise it will not show in render.
Have you baked the physics?

Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue (only ONE issue per report!), precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

Same issue reported on T58892.
Ok, I'm not sure if I'm allowed to do this here... let me know...
I have tested this one and I found that to solve this you need to change particle type manually. When you change the particle type to hair the particle type is set to "path" on "render as" option in the render dropdown inside the particle system. You need to set the particles to halo again and they will show up in the viewport again.

Well, in most cases we want to keep texspace from orig mesh (i.e. not take into account changes from modifier stack). Otherwise, you get fluctuating texturing when modifiers change bounds of the geometry. So question here is: do we want/need to make an exception for domain of smoke sim (and maybe others? Though iirc fluid e.g. generated geometry, not a 3D texture…)?

So this is not a drawing issue. The texspace should be set accordingly for the adaptive domains (which is only valid on the evaluated mesh since it changes size).

Well, following those exact steps, it also crashes for me with current master (and 2.8 too).

I agree! I'll change the status to Invalid.

If it is indeed a driver issue, there is not much we can do.

But it's actually very likely, that the driver is the actual problem.

I'm not able to change my drivers right now and I'll probably can't do it ever, because I'll change to another system soon.

Did you try the latest drivers available for your card?

The fragments still happen in the latest build, but it seems impossible to capture a screenshot of them, eventhough they keep reoccuring.

The same here. Any attempt to enter in "Particle Edit" closes the software immediately. This with the last Beta, and with the previous Beta, and the alphas too.

The same here. Any attempt to enter in "Particle Edit" closes the software immediately. This with the last Beta, and with the previous Beta, and the alphas too.

Any updates?

roger :)

We do not close this now. We will close it when my patch has been accepted or if it is decided to keep it as it is now.

Does that mean i have to close the thread now? Sorry if my question sound silly. I'm still learning. I read your tooltip. Like that formula part.

Before getting into drivers, please show a screenshot of the artifacts. It may be a duplicate or temporary glitch that is already fixed in the latest build.

I put in your card on the nvidia website (or so I hope) and got this link:
https://www.nvidia.com/Download/driverResults.aspx/120732/en-us
Your driver seems to be a bit older:
https://www.nvidia.com/download/driverResults.aspx/99994/en

I've submitted a fix: D4042

My driver version is 341.95, I can't find any drivers for it.

Are you using the latest drivers for your quadro card?

Thanks! I haven't tried it yet but I trust you guys on the status change :)

That case is handled below. You can also compare the code with master, the clmd = NULL is clearly missing.

@Sergey Sharybin (sergey): thx for checking, will doublecheck again tomorrow (the idea of keeping the cache, had the impression it was not set to NULL on purpose... -- if I dont find anything suspicious, will commit tomorrow)

@Philipp Oeser (lichtwerk), you r patch actually seems correct. modifier_free() will free memory used by clmd, and it is supposed to be set to NULL there. I guess this line was lost in one of the other fixes/refactors.

The crash has been resolved by rBb97cd0e6908. The cycle is still there, but doesn't seem affecting stability and there is no clear way of solving it from the dependency graph side.

Please attach a .blend showing the problem.

In fact, I believe this is a drawing issue, probably smoke draw code assuming texspace would be the one of the final evaluated mesh or something like that? Smoke simulation code itself at least is not affected by that afaict, it computes its own bbox…