Let me outline the issue I’m grappling with through describing a few of the states a sop passes through before it gets to my c++ sop.
- OBJ file loaded in via file in SOP:
points: P[3]
vertex: N[3], uv[3]
- sop passes through a texture SOP, which creates a second set of UVs bringing the vertex uv attribute from 3 wide to 6 wide, Still as vertex attributes. My understanding is UV’s are always vertex attributes because there will almost certainly be seams where normals and other attributes are shared/smoothed - is this logic correct?
points: P[3]
vertex: N[3], uv[6]
- next the sop passes through an attribute create SOP. With all flags on, Normals are recomputed and moved to point attributes, Tangents are added to vertex attributes.
points: P[3], N[3]
vertex: uv[6], T[4]
- next I load the SOP into my custom cpp SOP, which is intended to do some mesh processing, essentially recreating the input, but with some changes/updates/modifications to the attributes, and custom attributes.
I am running into challenges thinking about how best to process a mesh that has important stuff on both point and vertex attributes that I need to aggregate.
For example I need normals and tangents for one particular calculation, but seeing as they may be split between points and verts, or they may not, how do I handle this in an elegant way?
Do I just flatten out my vertices so that there are no longer points to consider, so that every triangle has unique points?
Will this make upload to the GPU or downstream performance heavier in anyway?
To be clear, this is a last stop calculation before getting uploaded to the GPU, I have no plans for this sop chain needing to be modified more after this final cpp sop.
The thought of digging into direct to GPU executeVBO() function instead of the cpu one seems somewhat logical here since I think it requires describing the geometry in a totally unwound way anyways? Or is that thinking incorrect?
Thanks!