Viewport Shading 'Attribute' Option Broken for Instanced Geometry #106563
Operating system: Windows 10
Graphics card: Nvidia GTX 2080
Worked: 3.4, 3.4.1
When instancing a mesh to another meshes vertices, the Solid Viewport Color Option 'Attribute' is no longer displaying the vertex color data.
Create A Sphere, and using "Vertex Paint Mode" Paint a color onto the sphere.
Using geometry nodes set up the following, Group Input (Geometry) -> Mesh to points - > Instance on points -> Realize Instances -> Output (Geometry)
Set a simple sphere as the object to be instanced.
Set Shading mode to 'Solid'.
Hi there! From my understanding, this is just because the material is not assigned/assigned-wrong.
If you use 3.4 and the working file, switch to the material preview, everything would be white as well. But if you assigned the correct material for instances like shown below, everything would be fine (both in 3.4 and 3.5, have to use material preview).
I believe the issue is that 3.5 used a newer attribute structure for storing vertex color, so the solid mode doesn't show the vertex color directly, as vertex color is now a kind of generic attribute. Not sure if this is really a bug but that's likely the cause.
@HooglyBoogly Do you think this is a bug? Or should we still have solid mode to show vertex color or is this intentional?
Hi, thanks for the report, but this feature didn't work as intended and was just removed, you need to explicitly select the color attribute in the list now.
- And since the nodes don't yet pass information about the selected attribute, you can't do that for the generated geometry yet.
I've been using this to visualize color from a .ply point cloud.
Currently Blender doesn't colorize vertices for .ply and points clouds and this was the only way i can get it to show. By generating geometry at each of the vertices and have ir inherit the vertex colors. (This is using a rewrite of the .ply importer by Michael Prostkas).
It imports the.ply colors as vertex colors and with ~20 million verts or more being able to visialize it in the solid mode rather than Material mode has been quicker.
I sounds like a similar problem to the UV map not being selected when created, because some anonymous UV map gets selected.
I can have a look if it's the same problem. Though if it is I think it'll need some discussion to figure out a fix.
Or maybe it's just a case of populating the list based on evaluated geometry? I'll try to have look.
I wrote out a long version of more research I've done into this, but I don't think it's necessary.
To simply put it, since blender can't display/render vertices with color currently, geometry has to be instanced to each point. Average Point clouds I've worked on from scans can have upwards of 20 million points. Even with just triangles instanced to each point, that's 60 million points just to visualize a single point cloud's color.
I think it would be wise to avoid only showing this in material preview. (If my understanding of the difference between solid, and material preview is correct) Visualizing the point cloud in Material preview would be heavier than solid mode since material preview tries to apply some form of lighting, where as solid mode can just display flat colors. (Correct me if I'm wrong, I very well may be.) Optimization here is still very helpful.
I'd raise my tiny singular hand in the Blender crowd for continued support or visualizing vertex color in Solid - Attribute mode.
Thanks for coming to my TED talk. Hope you're having a good day!
I have done some preliminary research into this. It's a completely different problem from the thing's I knew something about ;-)
As far as I can see it currently 'works as intended'. As in the color attributes of the instanced object are used and not the attribute at the instancer level.
To be able to also use the color attribute at the instancer level would need some way to select that behavior I guess.
Best would be (imo) to get Attribute rendering in solid mode working for Pointcloud objects (or does it already? I couldn't get it to work, but I'm no expert). After all that's what Pointclouds are for.
Hmmm. My question would then be, What has changed between 3.4 and 3.5 that it is no longer pulling the color attribute from the instancer level for instances.
3.4 was able to pull that color data through, whether it was intended to or not, it has been pulling the color data through to the instances.
I'm attaching a sample .ply file I pulled from a creative commons library scan. It includes a geometry nodes setup I've been using. It's a bit messy, but as of today I am using 3.4 to visualize .ply data scans and its working great!
I agree, the best would be to get that type of support, but I'm not sure how easy that task would be. Blender doesn't natively support showing / rendering point clouds. As far as I can tell, blender just views each point as a vertex and since Blender can't render individual vertices it can't natively show/display vertex colors. This is why blender uses vertex color modes that use "Face Corners" so it has a face/polygon to render. (According to what I've found, I too could be missing something as I'm not an expert)
There is (the start of) point cloud support if you turn it on from the experimental features in the preferences.
Also, both solid mode and cycles have point cloud rendering, and according to the docs at least cycles should respect the 'color' attribute. Though in my (short) experiments I didn't really get it to work (because of incompetence on my side probably ;-) )
You can create a point cloud object in GN by using
Mesh to Points and outputting that as geometry.
Interesting, where is that documentation? I haven't seen anything related to seeing point clouds color data in Solid or in Cycles when I first started looking doing this.
And even though the PointCloud object is not in the Add menu without turning on the experimental features, I think it is what GN generates when you finish off your tree with a
Mesh to Points node.
But I personally can't get colored output working. Whatever I try the points are always white. I'm not sure yet if it's something I do wrong or a bug worth investigating...
edit: It was my own problem.
You need to explicitly set the material in GN, as the material on the original object is lost when converting to points.
Could you test if this would be a workable solution? Or is cycles too slow? Cycles with an emissive material, no lights and a very low sample count should be pretty quick I guess.
Right, currently in my pipeline I am already using the Mesh to Points. When Blender is importing the .ply file, it is just importing them as standard vertices as far as I can tell.
My issue is that I am using the point cloud to build from. I am not trying to render the point cloud itself.
I am using the point cloud, which is a LiDar scan, to build a structure from these scans.
In order to optimize and maintain efficiency I am trying to visualize the colors inside the solid view. The colors help me line up separate scans, and visualize what is a counter, or sign, etc...
It would be great if vertices could display color in the viewport, but since that isn't possible that is why I have built this GN system. I convert the .ply vertices to points, and then instance geometry on top that is inheriting the vertex colors from the .ply file.
3.4 was allowing me to use the colors in the solid view. Somewhere between 3.4 and 3.5 the ability to show attribute colors in the solid viewport broke or was 'rewired'. This is the functionality I'm needing to try and recover.
Did you already try to do it in cycles rendered mode with a very low sample count and an emission shader? Because in my experience that can sometimes be just as fast as solid mode. That example ply of the ship you uploaded above results in a perfectly solid viewport performance with cycles+emission-shader+sample count set to 5 .
I have one idea left for a patch that might make it behave like in 3.4, but I still need to test that and I don't yet fully grasp the flow of attribute data in the solid mode drawing path.
Alright, I've done more testing with this. Sorry, I think I've misunderstood what you were asking/suggesting.
So first things first. I did load in my building project in rendered view and I'm impressed. It actually handled it very smoothly. However, I am running on Dual 4070 ti's with a Threadripper, so my experience is not the norm. I'll have to test on a different machine.
Just like you, I can't get color out of the point cloud. I can get grey scale though... So that's odd. See attached image.
I can get the color data, and Cycles is treating it like a point cloud. Its rendering spheres on points.
Performance isn't too bad ~ 50 million verts. Especially if I plug the color straight into the Material output, and not use a shader at all. One thing I was missing while working in this workflow was X-ray mode.
Solid mode has X-ray, Rendered view does not. I was heavily using X-ray mode to see the
geometry I was creating through the point cloud. I may be able to work through that, but any shader solutions are more time consuming, opening the material and adjust alpha, or transparency vs. hitting Alt-Z.
The noise fuzzies are distracting, but not bad. I was just using 8 samples.
All in all Rendered mode, does work but it does seem to be more intense although my Gpu's are ramping up more often in rendered view even with the low sample count. They were never ramping up in solid view.
I don't know if its a long term solution, but it does work. I still think having a way to visualize colors in solid mode is a better way for people in my situation using point cloud data as structural reference.
Let me know what you find out about a patch or if you have anymore questions or anything else you'd like me to test!
Hm, sadly my hunch wasn't correct. But there's definitely something wrong going on.
I've found out that if I apply the modifier and then go to the 'Color Attributes' panel in the mesh data, no attribute is active. Which I thought my patch/idea would fix but it doesn't.
I'll try to investigate some more.
I think I've found the root cause of this.
Since the active/default_color_attribute is now passed by string instead of using the 'active layer' system from CustomData there is no longer an 'active/default' layer in the realized instances.
The only thing I don't understand is that I thought this was already in place in 3.4? Will have to investigate that.
I have an idea for a patch that would fix it, just need to find some time to actually implement it.
Interesting, so does that mean that technically 3.4 isn't supposed to work when doing this either? Ha ha.
Well I'm glad you have an idea of what's going on. Please let me know if there is anything I can do to help. I'm not competent in coding, but I'm happy to test, etc... Get more info for you.
Interesting, so does that mean that technically 3.4 isn't supposed to work when doing this either? Ha ha.
No it probably means I misremembered stuff ;-)
Will confirm because 1) we have a PR that would fix the issue 2) it now clear why this fix is needed.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?