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
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
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
Somehow, a particle system distributed with an empty Density Vgroup will put all the particles in the middle of the terrain.
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.
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
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…
some facts from forestpack:
- clean borders works with any size grassblades.
- transparency depth render config affect clean border option
- clean borders slowdown the calcs, forestpack has option to calc it in rendertime only
- viewport pointcloud preview use clean borders if rendertime only option is off
a possible workflow:
- check individual blades boundingbox crossing border limit…
- for each blade crossing the border limit check lowest-Z vertex if inside or outside of the limit…
- if inside, vertexcolor entire element (linked mesh) to white else vertexcolor element to black…
- use vertexcolor on opacity material slot.
*or use color from emitter (white texture) for opacity channel only… anything outside emitter is black.
- can instances have individual vertexcolor (some override)?
not inside a particle system
think you is this possible with shader nodes? using the trick for lowest-z vertex from each element?..(if lowest-z vertex is inside, entire element get white color… if outside get black color… shader node result is connect to opacity material slot)
I have been seeing so many fantastic things made with shader nodes and math… then I think maybe this can possible and elevate your scatter addon for another level with clean edges.
Flaw 20 no particles intersection / bounding boxes
Particles intersect with each other’s
Scattering a curve could be really amazing, and having no dedicated tools for placing, moving particles individually is welcome
Flaw 21 no bounding boxes
Speaking of bounding boxes, a really simple and important features that could be implemented is limiting the particles at the border so that the bounding box don’t go beyond the boundaries of the emitter.
this is a really basic feature that should be implemented as a simple boolean toggle.
Idea 22 Emit from material.
it could be really handy to choose the emission surface depending on the material attribution of the geometry.
For example, the particles will be emitted only on the face that have “Grass” material. The user could assign his material with a pointer.
skatter propose some nice ideas like skatter along a curve, or place indicidually.
Well i notice blender works also much better with linked data vs appended data. You can do a test for this with the addon. I havent tested this. But i made this render for a shirt i wanted to propose for Mr Hubert
Its a model from Nasa and was quite heavy on polys. Animating the imported model was slugish in the viewport. But doing it with a linked model, it was way better and smooth.
I believe Clarisse also sort of works in that manner, it doesnt have all the data inside the app.
Still wonder why a linked version of the model inside Blender animates much faster, i mean its still sthowing the object in the viewport.
Well perhaps what could be done, just an idea here. Is that it make a part of the psys near the border into real mesh on rendertime and also adds boolean part. Then after render this gets deleted. Though this would mean longer render startup as his probably needs to calculate more mesh data
I found that displacement does not work on instances, I mean, different instances cannot have different displacement outcome.
And if we calculate the pure mesh data then we eliminate the leverage of having instances because we would have to have the mesh data in memory.
The only way I can think of is having a proper shader inside cycles that actually visually removes goemetry but it’s not affected by transparency limits, like a true/false shader that ignore bounces that go through them, something like that, that will not slowdown the render and will not be affected by transparent bounces.
I hope this will be implemented.
In this thread: https://blenderartists.org/t/100-reward-for-the-one-who-can-distribute-particles-from-a-cycles-node-non-destructively/1178466 you were told that Cycles is not data transformation tool, but rendering engine.
I beg to differ. At least from node usability perspective. Because what else is displacement if not data transformation? If Cycles - or at least elements of it - can change vertex location…
I’m not a developer, but maybe there is an option to adapt displacement pipe to convey instead transformation data plain greyscale values taken from node setup and write to vertex color/weight?
Because that’d be absolutely fu**ing amazing.
I must take back parts of what I said.
I’ve mistaken Displace modifier and Displace Node.
So updated idea would be:
What if instead outputing particle coordinates from Cycles, do the exact opposite? Such as the particle system could output to Cycles? Where the user could take particle input and combine it with other nodes. That is very close to Particle Nodes I assume. And there is also new hair object type planned in the 2020 roadmap.