Of course as usual - Michalis makes everybody feel inferior again …
He is no match for my glowy mushrooms of death!
are there some dll’s that can be replaced or so, to get this ?
Probably not something anyone should eat!
Well any build from the build bot should have it
Might want to recheck the Win32 “official” release. (2.73-cfa1fd1) Just downloaded it specifically to try this out, and I don’t see it in there either. (Even enabled experimental under Cycles.) Maybe it’s only in “gooseberry”?
—edit—
Going to retry again, seems like the download updated sometime after refreshing the browser. (The version I mentioned seems to be different than the one I got. Even though I just downloaded minutes ago.) 
But I’ll let you know if it’s there after trying again.
Well all of them have been updated recently except win 32 in gooseberry
Also remember that its not its own node its on the geometry node
Ok, cool. Got it working now. The fresh download made the difference. It saves time messing around setting up vertex colors, and it is powerful, but it seems limited in use to specific cases. I got some glowing edges on this stellated dodecahedron, but the fade from the edge to the flat surface seemed to require some finicky adjustment of a color ramp.
Is there any way you could get something similar working with edge-detection? This needs fairly dense meshes as it’s based on vertices, but the effect would be cool if it it could be made to work with simpler geometry as well. (At least it respects modifiers, so that works in a pinch.) Maybe edge angle and distance to edge to complement this vertex “pointiness” value as alternate options for a similar effect in the future? Or is that asking for too much?
Also did an experiment to see if it did anything with volumetrics, this only seems to be a surface calculation at the moment. (Thinking it’d be neat if I could measure 3D proximity to vertices, because reasons. 
Nothing like that yet though.)
This works only with a highly dense mesh?
Doesnt have to be highly dense but more mesh helps
Edge split modifier kills this effect:confused:
uh oh… its expected but not wanted at all lol
Anything that relies on merged faces is not going to work with edge-split since it works by way of doing an actual split rather than through a shader.
Ideally, edge-split in both the viewport and Cycles would alter the normal coordinates of the mesh itself to create a sharp edge, instead the implementation in its current state takes the easy way out (though I guess if there was a good way to mix together the ‘normal’ and ‘true normal’ coordinates…)
Ok you can bring it back with a autosmooth option rather than a split modifier
Okay, starting to test the new attribute for myself, and I have to say that there are some serious limitations with the per-vertex technique that Sergey implemented.
Sure, I can see the use for sculpts and worn edges, but those are pretty much the only situations where it can actually be useful, a couple of things that I think is required before it can become truly useful.
- -A fixed distance calculation rather than a 2-ring neighborhood one, right now you need the right topology to even get even results, and beveled/high-poly/subsurfed objects can’t use it all that well
- -The distance calculation stepping over diagonals as well, otherwise you get pinching.
I was thinking I could use it to compensate for the dark corners effect with SSS via adding energy in those regions, I guess not. In my opinion, the concept is sound, but we need to change the method for distance calculation.
Another issue that further limits its usefulness, you can get very different results just by increasing the number of the faces on the mesh, even if the topology is more or less exactly the same.
Two cubes with bevel modifier, exact same settings, exact same material. The only difference is that the left cube has 9 faces per-side (all squares) and the right just has one face per-side.
I really think that copying the ‘dirty vertex colors’ algorithm is not working here, I mentioned in the post above how the algorithm can be changed to get better results. Otherwise we’ll be seeing a flood of complaints when 2.74 is released, which is almost a given if there’s cases whee it can fail on a simple cube shape.
What I don’t know right now is if one should try their luck and report it as a bug.
It relies on mesh topology ? That doesn’t make much sense from a user pov but I guess there’s a good (technical) reason behind it…
A vertex-based data type rather than bringing in a true, per-pixel algorithm means there is no speed penalty during the actual rendering, but we need to do better than copying the ‘dirty vertex colors’ math as I’ve shown above.
I see there would be performance loss… but only if the attribute is actually connected to something ?
hahaha here’s the title -> geometry feature fails without geometry!
some people…