You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
so ive been scratching my head here, and maybe i missed something but when i try to render a frame (i tested a two frame animation as well) and have my particles visible in the render, the only way i can get them to show up, is if i have them viewable in the viewport first.
so i need to disable "hide particles" in each of the systems, change the dispaly mode to final , and then reolad the frame, and only then when i render are the particles viewable..
i can confirm it does work with the command line render. but it would be nice to be able to use the internal renderer as well...and for still frames...maybe we can get a command line render for jus the frame...
im on blender 3.1, ff 1.4.0 and using a modified version of the waterfall a1 template.
thanks
The text was updated successfully, but these errors were encountered:
I'll mark this as a known issue and add some more info to this thread so that it can be easier to find.
This is caused by a long-standing design issue in Blender where large amounts of geometry may not be synced correctly with the renderer due to conflicts with the viewport. The workaround for this issue is to render from the command line. The command line tools in the sidebar menu can be helpful for this:
As of FLIP Fluids v1.4.0, the command line tools have a feature for starting a single frame render. An alternative workaround can be to uncheck the hide particles option, but this is not always guaranteed to work.
A Blender developer made this issue as stable as they could at the time, but it cannot be perfectly stable. It was mentioned that this would be handled in regular development (Comment Here).
This issue seems to be random and can be dependent on the system. For example, some artists will never run into these problems while others will experience this frequently.
Frequency of incorrect renders (or crashes) usually increase as the amount of geometry increases.
I would almost always recommend rendering from the command line for large geometry scenes. There is a huge improvement in stability as well as performance and resource usage benefits.
rlguy
changed the title
white water not showing up in render, unless hide particles is unchecked or if using the command line renderer...
Whitewater not showing up in render, unless hide particles is unchecked or if using the command line renderer
Jun 13, 2022
Hey!
so intrestingly enough i was runing into this render crash issue...even with the comand line render.
I managed to isolate it to the optix renderer using both my cpu and gpu.
once i removed my cpu from the optix render, it seems to not be ending the render beofre its done.
For this im rendering on a alienware m15R7 with a3080ti and a ryzen 9 6900X.
thanks again for the help identifying the issues!! love this plugin since day 1 of the release and love this community!!
rlguy
changed the title
Whitewater not showing up in render, unless hide particles is unchecked or if using the command line renderer
[Blender Bug] Whitewater not showing up in render, unless hide particles is unchecked or if using the command line renderer
Jul 24, 2023
so ive been scratching my head here, and maybe i missed something but when i try to render a frame (i tested a two frame animation as well) and have my particles visible in the render, the only way i can get them to show up, is if i have them viewable in the viewport first.
so i need to disable "hide particles" in each of the systems, change the dispaly mode to final , and then reolad the frame, and only then when i render are the particles viewable..
i can confirm it does work with the command line render. but it would be nice to be able to use the internal renderer as well...and for still frames...maybe we can get a command line render for jus the frame...
im on blender 3.1, ff 1.4.0 and using a modified version of the waterfall a1 template.
thanks
The text was updated successfully, but these errors were encountered: