- User Since
- Aug 1 2010, 10:28 PM (463 w, 4 d)
Thu, Jun 13
Yes, I have not found the problem yet, still looking at particles code when I have some time, I would like to do some proper debug and profiling as Antonio did to find if I found the bottleneck, but I don't think it's a bug, it's just something to be improved.
Wed, Jun 12
No worries, I agree with you that better defaults would be good for the hair system :)
BTW not knowing a tool and trying to use it before doing a big presentation has never been a good idea, I’m sorry to hear that you are in that situation, try to apply the settings I described in the previous message and give a bit of collision thickness to the collider.
I have to disagree.
Tue, Jun 11
Here is the example with correct settings:
I'm afraid this is not an inestability problem, I mean... it is, but it's not a bug, it's due to defaults being wrong, and also the haird collision system not being the best in the world, it's not too precise.
I cannot reproduce it with the steps you said, an specific number and type of operations could be welcome to confirm this.
Sun, Jun 9
Mon, Jun 3
THANKS A LOT!!!!!
Wed, May 29
@Germano Cavalcante (mano-wii) well, right now this is a pretty important feature, I'm not sure what areas do you think that need more attention in snapping, could be great to know :) (really, no pun intented) but a common workflow in any software is to snap things to curves, since for example CAD data come in curve form and some parts of a CAD model may be constructed based on the CAD curve to allow an easy iteration.
Tue, May 28
It seems to be related to some kind of capping, with 100.000 particles * 100 interpolated children all CPU's are being used ina multithreaded task, while with 100.000 * 10 interpolated children it seems that is not running the multithreading, so it's doing a single threaded task
ok, so in 2.8 is also working, so this may be just the result of having faster particle creation and now having a much slower children creation, which in reality it's not slower, it's that now it's more obvious, I'm not sure, still doing some more tests though
It seems that the same thing worked fin in 2.79, the problem seems to be related to child particles
It seems the problem is related to children generation, when trying to generate 100.000 particles * 10 children on viewport it hangs
I tested today's master in windows, i7-5960x, without problem:
Sun, May 26
Fri, May 24
Why does this appears as buildable?
@Sam Van Hulle (sam_vh) probably what you want is a blue noise distribution pattern, this will give the impression of random and organic but at the same time will give the particles evenly distirbuted without forming clumps, somethign that now happens, I wish this could be implemented
Thu, May 23
Do a new build, code was updated yesterday if I’m right 👍
Wed, May 22
May 22 2019
same problem here, black spots at the long distance
May 21 2019
I have the same problem, important to leverage clouds of Real Sky on Eevee, it will be super powerful when this is solved, I hope you can solve it before 2.80 release :)
Following Bretch suggestion the patch has been super simplified, and it's performance is even a bit better.
- Can you provide a test file that allows us to easily verify the performance increase?
May 18 2019
I'm curious about one thing, how is this different form this @Lukas Stockner (lukasstockner97) implementation?
May 10 2019
May 8 2019
Shouldnt this option be in the solid mode pop-up rather or in addition to it being in the workbench render settings?
May 7 2019
Is this still alive?
May 1 2019
It seems that was a small temporary problem that has been already solved, I built Blender this morning and I had the problem, now I just rebuilt it and it seems everything is solved.
It also crashes when you try to open the material slot list
Apr 19 2019
For me 5+1.
Mar 27 2019
It's udnerstandable that this must be adopted for release, but right now was not something obvious for many of us, this has served as a good warning :)
@Campbell Barton (campbellbarton) do you think you could extend the "grace" period? so users can stay using the addons now that everyone is aware and addons are being translated, re enabling this IF statement, so addon devs are fully aware now, but users are not being able to work with addons, it feels like everything exploded, and it is not the case, so 2 weeks or 1 month more with the IF could be helpful for devs, and it will maintain users safe in general :)
Mar 26 2019
I've been able to reproduce the problem, but just in Linux, in windows I don't get a crash.
Mar 25 2019
@Stefan Werner (swerner) Intel said that they just uploaded 0.8.2 with that you said fixed!
This is understandable, but don't you think that you should have warned everyone clearly that this was going to happend?
Just stumbled upon this bug, what a big bug!
Mar 7 2019
Would this affect objects without bump? Because we have those terminator problems also in objects without any bump and maybe this can also soft those problems.
Feb 24 2019
Feb 12 2019
Feb 9 2019
I tired this on a Theory Studios build and it is amazing!
Jan 31 2019
Jan 11 2019
This is a pretty neat feature for sculpting!
Nov 30 2018
Nov 28 2018
Sorry, for the tokens thing, something happened to my browser.
I can´t understand why Vector Displacement not working on instances is not a bug.
Yes, I noticed it too lately, there is not much of a difference, at least not like before.
Nov 14 2018
Sorry, fixed the file link.
Nov 13 2018
Jul 14 2018
May 5 2018
I´m not sure where to put this, so I´ll put in this more generic thread, but please point me to the correct place if there is one.
May 4 2018
IMHO this should be included in Master, this is an awesome tool, for example to be able to clean up grass from grass patches that are distributed over a space, when you have to remove those parts that are inside the road but they should not, for example, this is great!
Apr 10 2018
Apr 8 2018
Any evolution regarding this? Specially now that the Code Quest started?
Mar 23 2018
I would like to add two suggestions to Alembic:
Feb 4 2018
Ok, thanks :)
Jan 30 2018
How is this going?
Jan 8 2018
Most of the time I’m from mobile, but I’ll look a way to join there :)
I’m trying to think in what I just said, to explain it in another way, once you have all the particles split it in bigger voxels, calculate each separately and interpolate the result this split could even be configurable so you could adapt it to a number of threads or parts, you could even avoid the interpolation part to have a preview, if you want the exact same result as we have now you just configure 1 thread and that’s it, if you want to require less memory during the process (and that is totally outside my small knowledge of Blender code and C++) you could configure 32 voxels for 16 threads, this way you only need in memory the working amount of particles, so less particles per voxels so theoretically in my wonderful perfect world that only exists in my mind you would need less memory per thread but more time for calculating the interpolation of the defined voxels when the are all complete... again... I’m not sure if this is a nonsense, but I’m trying to imagine how could it be solved as a logical problem :)
Since this is a voxelization process (I’m assuming that) couldn’t you split the work in bigger boxers, save in memory just the voxels if each zone limit, work each zone with one thread and once it’s completed merge or interpolate those voxels limits?
It´ñs working great, I´m prepairing a tutorial related to this.
Jan 5 2018
I assume you solved the motion blur problem yesterday because now I got Motion Blur in Cycles with the latest fracture build!
Jan 3 2018
And I just noticed your sample with the surface deform, yes, it could be similar to surface deform, but using particles instead of meshes and with the abiltiy to break those meshes based in distance from underlying particles or something similar.
On a side note, maybe this motion blur thing can be also applied to the actual Fracture Modifier results, since if we don´t bake the results to keyframed objects we don´t have motion blur, but this removes the ability to have a non broken object using the Perform Merge option, wich is super useful with glass.
Yes, think about a grid of particles, with the Molecular Addon you have the ability to make that group of particles to behave as a solid object, and using forces and collisions you can make that group to split or break, it is similar to the old days when Sotimage made use of Lagoa Unified simulation system.
But then... how does elbeem fluids do the motion blur with Cycles?
No motion blur in particle systems remeshed.
Exactly, this is very useful to be able to use fluids in production via Alembic.
Dec 31 2017
So... how is this going?
Is some alternative to this already implemented in Master, since we can take multiple geometry samples I though something could be already implemented, just asking.
Dec 5 2017
Yeah, decoupling tile sizes could be also a solution, in the end the target is to have a fast render and a fast denoiser avoiding the overhead of small tiles, so if the denoiser works better with bigger tiles the render could be divided in bigger tiles just for denoising, but since I don´t know the inners of the system I don´t know if it´s possible, but since you propose it, I assume it should be possible :)
Dec 4 2017
Why not make the denoise as a post-render pass as other render engines?
This would kill the small-tiles problem because the denoise could be done with bigger tiles, I never understood why the current implementation does the denoising at the same time of the rendering.