Maybe because distance density culling and because your system don’t calculate culling by each frame
Flaw 7
The Weight proximity modifier is really important, using it allow us to do “boolean” operation on the particles.
the current problem with this “Weight proximity” modifier is that we can only do operation with one vgroup at the time.
so if we want X objects to substact weight from let’s say 5 particles system, 5 modifiers will be needed (if we want to keey having different vgroup influence per psys of course, and it is really important to do so)
having a modifier that can substract multiples vgroup at the time could be much much more useful and maybe performance friendly
of couse, another more easy solution could be implemented for users than this modifier. ( a node form ?)
4 Likes
Flaw 8
with random rotation we can randomize the particles on the local xy.
with random rotation phase we can randomize the particles on the local z.
with random scale we can randomize the scale of the particles on local xyz.
but why not having it vector Based ?
And why random phase is from 0 to 2 ?
How can something be 200% random ? 100% is more than enough. It should be from 0 to 1.
rotation randomisation
-x
-y
-z
scale randomisation
-x
-y
-z
this seems more logical and give more possibilities over its randomness. right now it’s kind of a bit confusing 
“phase” being z, “rotation” being xy.
also another things that is confusing is that there too option for controlling the scale of the particle.
either with the scale ratio or the hair length. only one is necessery, and it should be a 1:1 ratio by default.
Flaw 9
there’s a texture mixing calculation type avaible in the code but not avaible for users ?
5 Likes
Because it’s something completely different.
I guess @Alberto is talking of frustum culling. That way geometry that lie outside of the cameras viewing frustum get culled before rendering. You have to think of what you are saving when. Anything that gets done before rendering itself can cause a lot of workload and won’t get better by frustum culling. If you are processing hundrets of thousands of particle positions you can’t cull anything here before the position and/or dimension is final and the rendering doesn’t really have to be the bottleneck, but the computations before. Another thing here is if you put less elements into a scene with that camera check you implemented and then blenders culling skips anything outside the camera, you are saving multiple times, because you calculated less elements, you generated less and by changing the camera view even less remains on screen.
2 Likes
Flaw 10
maybe a bugs ? -> representation of particles inacurate in the viewport
first case:
-
the rotation is set to random and count display on 1%
but somehow at 1% all the particles rotation are not random. so using the display % is actually a bad way of previewing what will happend with particles distribution. -
second case: having two textures influencing density/length will make the particles representation in the viewport totally inacurate when chaging the values. an edit mode refresh is needed to make them precise.
Flaw 11
PERFORMANCE ISSUE of course
- lot of particle’ instances slow down blender. other sofwate can handle instances much much better at a much much higher count !
- it seems that the outline overlay is drastically slowing down blender performance on high particle count. something wrong with this design, maybe ignore particles with the outline.
Flaw 12
No float number support for particle display % ?
when working on really dense grass field, 1% isn’t enough.
the ability to go below 1% is necessary for a lot of cases.
1 Like
Flaw 13
huge problem for animation, any modifiers that influence particles density vgroup will change the seed of the particles. i tried this with every >Emission>source> distributions options. nothing works. particles seed change every time.
this is just a simple weightpaint set up.
we should have an option for hiding particles influenced by a vgroup, instead of regrouping all particles in the painted area.
3 Likes
Flaw 14
particle seed in viewport is unpredictible.
Sometimes, when changing values in the particles parameters, textures or modifiers, the displayed particles in the viewport are not in the same place they will be in the final render.
this is a big deal for important object on your scenes like trees and big foliage.
i couldn’t identify the cause of that. the “viewport seed” just behave strangely
the only counter to this annoying ‘bug’ (?) is the user constantly toggling edit mode on/off or toggle viewport visibility on/off
Idea:
in my addon i propose safety features:
if the obj scattered is too high (after X polys) the addon will automatically set the particles to a bouning box
if the polycount is too high, the display % will automatically adjust accordingly to not go after Y displayed in viewport
if the polycount is wayyy too high, the addon will automatically hide the particle system from display.
thoses features could prevent blender for crashing to a sh-ton of peoples
1 Like
of course we can take a look to clarisse ifx
this program is just magic, it can show off millions of object, billions of particles live in the rendered viewport
i don’t understand how they can achieve this
having blender 2.8x viewport being a lot more optimized for instances and particles is a must for any environement artists who’d like or who are using blender.
3 Likes
Flaw 15
in the particle length vertex group. all the particles that are on 0 length (not visible on screen) are still slowing down the viewport. this is quite bad. thoses particles don’t exist. why are the viewport still slow anyway ? something / 0 = 0 so why “0 particles” are still influencing the viewport ?
how to test that:
-create a huge terrain
-create way too many particles to handle
-create vgroup, adn paint with vweight paint only a small zone with intensity of 1.
-attribute this vgroup to the particle system
-see by yourself that the viewport is still slow. even if the majority of particles are not visible on screen at all.
https://docs.blender.org/manual/en/dev/physics/particles/mode.html#bpy-types-particleedit
Uncheck the Keep root position check box in the tool settings
1 Like
my bad, deleted the idea
Important idea: Cut Edges of a Particle System.
Forest pack use a really cool technique to have clean borders ! must watch !!! it is only 4 minutes…
unfortunately impossible to do within an addon
1 Like
This is hard to do not because of Blender but because of Cycles.
I mean, to do that you should be able to modify the instances geometry to delete the parts that are outside of the area, and that would make the goemetry to stop being an instance.
The other possible solution is using shaders, maybe using displacement to scale the outside elements to 0, but you should be able to define a way to mark those elements as “rogue” so the displace can affect them, but I’m not sure how to define the scale to 0 using displacement and how to mark those elements.
This is something I fought with without luck so far.
2:11 “edge mode: uses the lowest Z vertex of eaches of the items individual elements to check if they’re outside of the scatter area, if this is the case, only the individual element is removed, creating a clean edge because the geometry itself is not slliced”
i don’t get it…
what is a “Z vertex”
so i heard from a forest pack user that this “Cut Edge” technique is not really done at a geometry level but at shading level, where’s a procedural b/w texture is influencing Vray opacity. giving the illusion that the egrass border is clean.
not sure about that but well it could work.
But well, having “Clean edges” is a really important feature that shouldn’t be overlooked
Flaw 16
what is the possible reason an object need to be aligned on the Y axis to be straight in the particle system ? why would you want that ?
This is really really annoying for all the poeples using the particle system for scattering (the majority), it’s an extra unnecessary step that’s seem totally absurd.
An object is always aligned on the Z axis, so let it work straight out of the box.
we are forced to turn the object -90* apply it’s rotation and return at orginial rotation with a +90* to get things straight again. this is really annoying
Flaw 17
Somehow, a particle system distributed with an empty Density Vgroup will put all the particles in the middle of the terrain.
1 Like
Flaw 18
editing the scattered object position via Particle edit mode is really amazing ! but we are not using hair anymore, it could be more usefeul for the user to see the object or even just an origin point instead of an hair geometry.
maybe the particle edit mode could be a bit stripped down of some functionalities with just some really basic brushes ? (if the user use the particle system ad a scattering soluction of course)
(ex: particle selection, cursor, add particle, remove particle, change particle size and moving particle?)
“Lowest-Z vertex”, not “lowest Z-vertex”. When they check which grass blades to remove, they look only at the vertex with the lowest z, that is, the root of the blade. Other vertices are not considered:
“the geometry is not sliced”, so, in this picture, blade 4 will be fully intact even though part of it is over the pavement, because its root is in the soil; while blade 5 is culled even though most of it is over the soil, because its root is in the pavement.
3 Likes
i see! nice ! thanks for the explanation
the problem is that we don’t scatter the grass in individual blade but in patches of maybe 30x30cm of various grasblades.
with this 30x30cm patch parameters, i don’t understand how it could work ? as analysing every loose geometry inside of this object is not a solution as it cannot be culled anymore
edit:
quote from the video: eaches of the items individual elements
so indeed they are analysing each loose geometry of the patch.
this sound like an really cumputer intensive method.
even after the elements are found, how are we supposed to remove them ? as removing them will remove them everywhere too…
1 Like