- User Since
- Nov 15 2004, 1:25 PM (752 w, 5 d)
Thu, Apr 4
Tue, Apr 2
Mar 20 2019
@Sergey Sharybin (sergey) - I see you just fixed another issue with rigid bodies and particles, could you have a look at this one too?
Mar 1 2019
The thing that seems unintuitive, is that it *does* update if Dyntopo is enabled, which should be heavier.
Feb 6 2019
Feb 4 2019
When in particle mode...
I just tried it, the loading seems to be fixed.
Dec 13 2018
Dec 11 2018
So we can actually commit with thread_count = 0;, in the hope that later on Blender gets optimized to actually take advantage of more threads.
Dec 10 2018
We could commit this with thread count set to 2 and the audaspace changes left out, for the purpose of getting the small speedup.
Dec 8 2018
Dec 5 2018
Maybe all this is doing is making the ffmpeg encoding run in its own thread separate from the Blender main thread, which saves a little bit of time. But it's not actually encoding multiple frames in parallel, and something else is needed to do that?
Dec 4 2018
FF_THREAD_FRAME is slightly faster than FF_THREAD_SLICE
In the tests so far, this has had an approximately 20% speedup.
Nov 29 2018
I'm still getting this crash in the latest build.
Nov 28 2018
Hi Phillip, I re-pulled the latest sources and did a "make clean" ( and also a clean build from Visual Studio ), and the issue now seems to be resolved!
Nov 27 2018
does this happen with Factory Settings as well?
Hi @Philipp Oeser (lichtwerk), this is still happening here for me ( in the build from the latest source - 32ab0647a53 ).
Another interesting related issue. If you replace step 4) Rigid Body with 4a) Soft Body and optionally 4b) Toggle off Goal, then the hair particles do follow the new physics position of the cube when you press play after step 8)
So, hair seems to work with Soft Body physics updates and not Rigid Body physics updates.
Nov 25 2018
Note that, if you carry out the above steps and skip 7), the ( non-hair ) particle effects do follow the cube.
Nov 22 2018
I'm still seeing this on the latest version, try selecting this vertex before running Vertex Connect
Nov 15 2018
Nov 13 2018
I had tried to build locally, but I was getting a crash - and did indeed download the latest BuildBot build, which didn't seem to have the commit.
Nov 12 2018
Nov 7 2018
If I change the camera clip start, it has an effect on the visibility of the smoke.
Nov 4 2018
I see the crash when I click on the other vertex across from the initially selected one, and then run Vertex Connect ( not Vertex Connect Path ).
Nov 3 2018
Well the "show backside" has a performance cost associated to it, and it is unnecessary for certain objects (think a simple glass plane).
Nov 2 2018
Just to add to this, I see the problem in 2.8 when I take these steps...
Oct 30 2018
Oct 26 2018
I've added a fix for this, I just need to get permissions set up to push it to the repo.
Oct 24 2018
Hi Bastien, if you make a full copy of the scene and then delete the scene, it works fine.
If you can give me a few pointers as to where to look, I can have a look at fixing it myself and hopefully submitting a patch. I recently downloaded and compiled the sources and can now debug with Visual Studio, if you're OK with sharing some of your knowledge of this area, I'll try to use that to fix the issue.
Oct 23 2018
It would be great if this was a togglable option.
Oct 22 2018
A better fallback for Rendered mode might be LookDev, rather than Solid?
Oct 21 2018
Oct 20 2018
May 25 2018
Ah, no probs :) I had raised another bug before I read this. Where is the best way to report issues like this? I know the Intel graphics chipsets aren't as powerful as NVidia / ATI, but they are more common.
A bit more info - the same thing is shown when in Edit mode.