particles appear 100s of time at the same place in random #44177

New Issue

mathieu menuet · 2015-03-29T16:23:26+02:00

mathieu menuet commented

2015-03-29 16:23:26 +02:00

System Information
Win7 x64

Blender Version
Broken: 2.74
Worked: 2.72b

Short description of error
Particle system with hair and object as duplicate only have limited amount of spots to spawn duplicates which make it impossible to fill an area.

Exact steps for others to reproduce the error
Open attached blend file (nothing fancy, default scene with 2 objects and 1 hair particle system) and increase particle count, they all appear on already used points.
bug_particles_random.blend

By the way, as the particle code is really seriously breaking appart, it would be nice to have a nice working workaround in the mean time. The current one is to replace particles with planes in working versions of Blender like 2.72 or 2.69, make duplicate real, join them and use duplifaces on the resulting objects.
Problem is, it makes render really slow and takes lot of memory, as we have to make the planes transparent.
It would be nice to have a way to make the children (particles) visible for render without the parent (the planes)
Thanks

**System Information** Win7 x64 **Blender Version** Broken: 2.74 Worked: 2.72b **Short description of error** Particle system with hair and object as duplicate only have limited amount of spots to spawn duplicates which make it impossible to fill an area. **Exact steps for others to reproduce the error** Open attached blend file (nothing fancy, default scene with 2 objects and 1 hair particle system) and increase particle count, they all appear on already used points. [bug_particles_random.blend](https://archive.blender.org/developer/F156113/bug_particles_random.blend) By the way, as the particle code is really seriously breaking appart, it would be nice to have a nice working workaround in the mean time. The current one is to replace particles with planes in working versions of Blender like 2.72 or 2.69, make duplicate real, join them and use duplifaces on the resulting objects. Problem is, it makes render really slow and takes lot of memory, as we have to make the planes transparent. It would be nice to have a way to make the children (particles) visible for render without the parent (the planes) Thanks

mathieu menuet commented

2015-03-29 16:23:27 +02:00

Changed status to: 'Open'

mathieu menuet commented

2015-03-29 16:23:27 +02:00

Added subscriber: @bliblubli

Lukas Tönne was assigned by Bastien Montagne

2015-03-30 11:04:37 +02:00

Bastien Montagne commented

2015-03-30 11:04:37 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2015-03-30 11:04:37 +02:00

Can confirm, Lukas, think this one is for you?

Lukas Tönne commented

2015-03-30 12:01:24 +02:00

This is likely because of the bad way in which particles generate random numbers: it creates a static array of 1000 random values, then selects a value for the different randomization purposes (such as selecting points on a face) based simply on the particle index. This inevitably leads to repetition quite easily. Not something that is easily fixable ...

mathieu menuet commented

2015-03-30 13:01:57 +02:00

It's a regression actually, it works in 2.72b.
What about the workaround of enabling the possibility of hiding the parent without hiding the children? It would be the equivalent of the "hide emitter" option in particle systems. Until the particle code is rewritten, we seriously need robust workarounds.

It's a regression actually, it works in 2.72b. What about the workaround of enabling the possibility of hiding the parent without hiding the children? It would be the equivalent of the "hide emitter" option in particle systems. Until the particle code is rewritten, we seriously need robust workarounds.

Carlo Andreacchio commented

2015-04-15 03:26:37 +02:00

Added subscriber: @candreacchio

Adam Friesen commented

2015-04-15 04:23:52 +02:00

Added subscriber: @Ace_Dragon

Adam Friesen commented

2015-04-15 04:23:52 +02:00

Yup the particle functionality is completely useless now, the system completely caved in on the alter of hacking in a hair system for Gooseberry apparently (how are they even managing with that).

What should be done now is remove the particle code entirely and replace it with a basic system good for simple effects and object distribution until it can be made into a new, shiny, and very robust system. It means reducing the particle code back to where it was in version 2.40 or so, but with a much better foundation. I wouldn't even wait until the Gooseberry project is done, leave the broken system in the Gooseberry branch only until then.

It would be better than leaving the broken particles in place or (even worse), just remove the particle button and explain why Blender 2.75 is the only 3D-related software on the planet with no particles.

Yup the particle functionality is completely useless now, the system completely caved in on the alter of hacking in a hair system for Gooseberry apparently (how are they even managing with that). What should be done now is remove the particle code entirely and replace it with a basic system good for simple effects and object distribution until it can be made into a new, shiny, and very robust system. It means reducing the particle code back to where it was in version 2.40 or so, but with a much better foundation. I wouldn't even wait until the Gooseberry project is done, leave the broken system in the Gooseberry branch only until then. It would be better than leaving the broken particles in place or (even worse), just remove the particle button and explain why Blender 2.75 is the only 3D-related software on the planet with no particles.

mathieu menuet commented

2015-04-15 07:56:34 +02:00

??? completely remove particles is a bit overreacting? Maybe do the same as for the Depsgraph, give both version parallel, user can choose in the options which one to use (stable simple one or unpredictable full featured one). Maybe take the code from May 2012 as a base : http://phonybone.planetblender.org/ ? 3 years already but it was working and with nodes!

Adam Friesen commented

2015-04-15 18:23:45 +02:00

Well we need to take into account the fact that the random number generator is the absolute most basic function there is for a particle system (every other feature depends on it). If the generator is broken, then you don't have much in the way of an proper system.

Blender is now in that boat pretty much, and it was suggested that the issues run deep. Hence why it's suggested that the only way forward is to go ahead with an entirely new system right now so users at least have a more stable and predictable system with much better code, even though it's to be said that it would be more basic but with the promise of major enhancements coming in future releases.

Well we need to take into account the fact that the random number generator is the absolute most basic function there is for a particle system (every other feature depends on it). If the generator is broken, then you don't have much in the way of an proper system. Blender is now in that boat pretty much, and it was suggested that the issues run deep. Hence why it's suggested that the only way forward is to go ahead with an entirely new system right now so users at least have a more stable and predictable system with much better code, even though it's to be said that it *would* be more basic but with the promise of major enhancements coming in future releases.

Carlo Andreacchio commented

2015-04-16 00:46:47 +02:00

To be honest there are 3 particle bugs now (two of them are the same) and (more than likely) are all caused from this commit: fe8fad54b1

The bug reports in question are:
#44177
#44312
#44353
#43981

Reverting this patch for the main branch of blender would be the best course of action until a more solid solution is created.

To be honest there are 3 particle bugs now (two of them are the same) and (more than likely) are all caused from this commit: fe8fad54b1 The bug reports in question are: #44177 #44312 #44353 #43981 Reverting this patch for the main branch of blender would be the best course of action until a more solid solution is created.

ronan ducluzeau commented

2015-04-16 11:31:45 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2015-04-16 11:31:45 +02:00

bliblubli.
i have a workaround.
Duplicate emitter mesh. Subdivide it a lot with remesh or detail flood fill button in sculpt mode. Then, use decimate modifier to decrease faces count to desired particles amount.

Emit a particle system from 1 particle/face of duplicate. Then, copy this particle system to mesh wanted as an emitter.
Enter particule mode to keep it.

bliblubli. i have a workaround. Duplicate emitter mesh. Subdivide it a lot with remesh or detail flood fill button in sculpt mode. Then, use decimate modifier to decrease faces count to desired particles amount. Emit a particle system from 1 particle/face of duplicate. Then, copy this particle system to mesh wanted as an emitter. Enter particule mode to keep it.

Carlo Andreacchio commented

2015-04-16 12:05:13 +02:00

The work around we have been using is generating 256 particles and using interpolated children for the rest...

Workarounds should not be needed though and this should be fixed.

The work around we have been using is generating 256 particles and using interpolated children for the rest... Workarounds should not be needed though and this should be fixed.

mathieu menuet commented

2015-04-17 11:58:31 +02:00

thanks zeauro, but our workaround list start to be pretty big regarding only the particles and it all cost a lot of resources so in the end money. Also workaround have their side effects too and don't allow easy modifications. I think you gave me the workaround with dupliface, thanks a lot for that but have a look here: https://developer.blender.org/T44206?workflow=create . In the end, it was a lot of work and we had to revert everything. Now our production is on 2.72b and I test intensively to hopefully be able to have 2.75 in our pipeline.
Any news on those particle nodes from 3 years ago? I couldn't find any info, just that it was financed by the BF.

thanks zeauro, but our workaround list start to be pretty big regarding only the particles and it all cost a lot of resources so in the end money. Also workaround have their side effects too and don't allow easy modifications. I think you gave me the workaround with dupliface, thanks a lot for that but have a look here: https://developer.blender.org/T44206?workflow=create . In the end, it was a lot of work and we had to revert everything. Now our production is on 2.72b and I test intensively to hopefully be able to have 2.75 in our pipeline. Any news on those particle nodes from 3 years ago? I couldn't find any info, just that it was financed by the BF.

mathieu menuet commented

2015-04-18 15:25:16 +02:00

In #44177#303161, @zeauro wrote:
bliblubli.
i have a workaround.
Duplicate emitter mesh. Subdivide it a lot with remesh or detail flood fill button in sculpt mode. Then, use decimate modifier to decrease faces count to desired particles amount.

Emit a particle system from 1 particle/face of duplicate. Then, copy this particle system to mesh wanted as an emitter.
Enter particule mode to keep it.

Thanks for the explanation, it may be the reason why our 200+ core machine gives very random results also. It may also be not thread safe. Would be nice if the changes could be reverted back.

> In #44177#303161, @zeauro wrote: > bliblubli. > i have a workaround. > Duplicate emitter mesh. Subdivide it a lot with remesh or detail flood fill button in sculpt mode. Then, use decimate modifier to decrease faces count to desired particles amount. > > Emit a particle system from 1 particle/face of duplicate. Then, copy this particle system to mesh wanted as an emitter. > Enter particule mode to keep it. Thanks for the explanation, it may be the reason why our 200+ core machine gives very random results also. It may also be not thread safe. Would be nice if the changes could be reverted back.

Tom Allen commented

2015-04-23 04:30:47 +02:00

Added subscriber: @guitartom47