Sup guys, I was wondering if there is any way to access vertex paint data from within a blueprint. Im wanting to use it to spawn components on specific part of the surface similar to how the foilage tool works Id imagine.
Thanks
1 Like
You can’t access vertex colours from Blueprint. I do believe you can get at them via C++ (StaticMesh should have a struct containing all that data), but the process of exposing it to Blueprint would be a little involved.
Yeah Ive had abit of a think about it and I might possibly be able to do it with physical materials, it would take a fair amount of traces detecting which surfaces have which materials. I think it would be far more optimized if I worked from the vertex paint information forwards rather than going backwards before going forwards.
That’s not what I mean at all.
I mean you can probably get it from UStaticMesh::RenderData::LODResources::ColorVertexBuffer
I don’t think I’d want that exposed to Blueprint by default though, it’s dangerously inappropriate.
Id prefer not to have to resort to c++ for everything. There has been numerous instances where things have been hidden because apparently Im a child with a new toy and my parents dont want it broken. That is kinda why we’re here though isnt it.
Thanks though I’ll check that out and see how far gone it really is in terms of getting it into Blueprint.
I wouldn’t even try to get it into Blueprint. You’re looking at a fairly intrinsic data buffer that will often contain tens of thousands of entries.
I would however perhaps try and write a small set of functions that do what you need them to do, and expose those functions for you to use within Blueprint; i.e. write a specific function that returns a vertex colour from a given point.
It’s also possible that this data may simply be inaccessible without full source access. I couldn’t say what UE4 is doing under the hood with static meshes!
Well upon further investigation I think using StaticMeshComponent as opposed to StaticMesh might work better. This saves me having to pipe data in from all different meshes into a manager class instead using each Blueprint as a manager for its Components, it should be alittle more directly accessible in this manner too.
You do have a good point, I hadnt considered the size of the datasets, I just went on the assumption that iterating the dataset would be less cpu intensive than tracing the entire surface. I guess the beauty of traces is that the resolution is independent from the density of the mesh polygons but the vertex data holds the correct Z at which to spawn the decals where tracing would only cache that data it wouldnt be updated if the mesh deforms say under displacement.
Using a similar notation: StaticMeshComponent::LODData::LODInfo::PaintedVertices
This does indeed seem to be accessible so this will be my starting point, I was thinking of making a component that can search through the owners component list and return the vertex information. How to do that though, I honestly have no clue, TArray should be easy enough to iterate and pass through to TArrays perhaps sorted by primary color.
I honestly have little interest in learning c++, I mean Im chugging through slowly but all it does is hold me back. I would love nothing more than to have a pet code monkey right about now.
FVector GetTest()
{
return LODData[0].PaintedVertices[0].Position;
}
Okay so I tried this as a test in a custom component extending UStaticMeshComponent but I get the errors:
cStaticMeshComponent.cpp(17): error C2065: 'LODData' : undeclared identifier
cStaticMeshComponent.cpp(17): error C2228: left of '.PaintedVertices' must have class/struct/union
cStaticMeshComponent.cpp(17): error C2228: left of '.Position' must have class/struct/union
Im not sure why it cant find LODData, perhaps because its not fund in public: declaration space. I dunno, maybe Ive done something stupidly wrong.
LODData is a public member (and it’s not preprocessed out by the editor-only directives), so it should be accessible in a subclass of UStaticMeshComponent.
Only thing I can think of is that you’re missing an include.
As an FYI, if UE4 is similar as UE3, static meshes placed in the editor will not have a component at run time (they are just static meshes collected into a single actor). If your stuff is only running in the editor though (is that possible in blueprint?), you might be fine.
What type of include would I be missing? The structures are defined in UStaticMeshComponent but perhaps its because they are in the global scope. I’ll try including UStaticMeshComponent and see if that helps.
I dont plan to use this with straight StaticMesh Actors but I’ll create Blueprints and assign the StaticMeshes to the Components, then I can access the vertex data for each component as required.
Okay so I worked out what the issue is and it seemed to compile okay and I have another issue to deal with (yet another corrupted project via the headertool garbling my ■■■■). I’ll mark this as answered for now, thanks for your help.
I have the same problem and an idea which uses tessalation. For me it dosen’t work because its a VR project in which I can’t afford tessalation. Perhaps you could change the height of the vertex paint channel just a litlle bit by using tesselation (world dsplacement). In the line trace you could get the hit location and make a comparasion to the world position of the untessalated part of the material. Haven’t thought that through, perhaps it works.
I am making a plugin where i try to detect the painted vertice colors RGBA, it works well in editor using LODData.paintedvertices but in cooked it gets serialized and the array returns 0.
Anyone know how to get access to the painted vertice colors in cooked, not just editor?
Maybe you can deserialize a mesh in runtime and thus get access to it?
Thanks