UV Unwrap and beyond

I’m attaching a TOX here that has maybe a useful technique embedded in it, but is more of a talking point about a broader RFE / technique I’d like to bring up for discussion.

In the file, my initiating desire was to be able to target a point on a surface via uv coordinate in order to inform where another POP system might “grow” or attract to along the other POP’s surface. The current way I thought to do this is to convert the “source” POP to texture data in order to use uv coordinates to locate the “growing” POP via mesh uv style coordinate space. The example attached is simply copying simple pop geo onto these derived points, not doing any simulation work yet.

First thing this revealed was that UV Unwrap mode for render doesn’t seem to work yet for POPs ( unless I’m missing something but i assume the Tex attribute or another defined one just needs to be allowed to function here? Not sure the complexities) but this would be great to have in any case for parity with SOPs. So I’m doing the unwrap manually in POPs and in the lowest example green annotation use multi-buffers to get the various attributes out into texture buffers to lookup. The yellow annotation area is my working process and comparison with the SOP unwrap, the three techniques are switchable via the parent “Lookup mode” parameter.

The unwrap feature would be great, but this for me brings up the larger “lookup” concept as a feature set to be brought more generally to POPs. This relates to volumes and Josef’s T3D stuff as well ( and maybe has/neighbor stuff also though I haven’t thought through that functional overlap yet). In my lower teal annotation I am pondering a generalized 2D/3D coordinate lookup technique and RFE that might enable us to use a beefed up Sort and Lookup Attribute POPs to get a way to “sample” POPs like we do textures, with interpolation and wrapping style configurations included. This might skip the need to convert to textures and just get to looking up a source POP directly via coordinates. See that lowest annotation for more detailed thoughts.

As always, I’m not sure how this gets sorted under the hood or what the pitfalls are but I assume since we do it with textures it could possibly be enabled for general POP data?

But maybe there’s something special about texture lookup compared to a ground up way to sample and interpolate… I could see the beefed up Lookup Attribute POP ( or seperate Lookup Coordinates POP? or maybe just called Sample POP?) having the same kind of parameter blocks as the current Lookup Attribute but with the ability to define texture style interp and extend/wrap modes.

This of course would then allow volumetric data to be imbued with arbitrary data above 4 components as well, something I’m sure Josef and Tekt are interested in and likely working on? Maybe generally points to how we get to SDF and volumetrics in POPs…

And as always again, maybe I missed something and this is already possible without conversion to texture? In fact I bet it is in some way, just seems like a bunch of work! Anyone done this?

Anyways, here’s my exploration:
uv_lookup_testing_and_thoughts.tox (58.2 KB)

Hey, I checked and UV unwrap seems to work with POPs, but the default on the Render TOP has the texture coordinate attribute as ‘uv’ instead of ‘Tex’ as it should be. If you change that it seems to work.

I’ll leave the rest of the notes to Vincent/Guillaume

Oh wow, totally missed that parameter, thanks malcolm… derp sorry, will update my file to utilize that instead. I think the other stuff still merits discussion i hope!

Hey Peter, yeah that default on TOP render should have been “Tex” so it works out of the box with default POPs attributes - we might also prefix these Tex Coord Attributes param names (you’ll find them on MATs as well, if you unfold texture params) with POP since they only apply to POPs

Otherwise cool example, thanks for sharing, I think rasterization (uv unwrap render for tex coord lookup and voxelization/sdf for 3d lookups) is probably the fastest for these kind of lookups, though the tradeoff is precision/memory usage.

For 3d lookups, for points (clouds), the hash/spatial grid is an alternative indeed, that’s in the work along with some kind of attribute transfer POP, which is another to look at it I think, for polys we would need some efficient spatial data structure (ray POP is looping on all polys currently)

I’ll add it as an RFE to streamline these kinds of workflow!

Thanks Vincent. Cool to hear about the spatial stuff and a transfer POP!

Here’s an update to this technique. I tried going down the render TOP UV Unwrap route but came against inaccuracies because of the way it rasterizes to the normalized uv space, where as what I really wanted was true sampling of the POP within its texture space so I came up with a POP to TOP method that works for well ordered point sets ( raw “meshes” that have row/column point sorts that match how POP to TOP lays out its pixels. I think the initial thoughts I had in the first post are still pertinent for this use case in a modified way. See inside the component in the green annotation for further thoughts re: 2D/3D grid sorting in combination with a more flexible POP to TOP ( that can output various resolutions and maybe eventually 3D?).

surface_sampling_tests_refined_post.tox (82.6 KB)

Been experimenting with this stuff a bit more and realizing that in order to have a POP assembled to match how a uv mesh might work one needs to be relatively rigid with how it is constructed that you would likely have most of the data needed ahead of time to do this technique as I’ve posted without the need for sorting in the way I’ve asked since the topology would be so rigid.

I still think some of these items may be of use ( sorting into an index point list that can conform to xy(z) cell dimensions, and POP to TOP resolution tweakings) but now I’m wondering about sampling/transfer stuff has Vincent mentioned in order to simulate creeping/growing over a surface that might not be so rigidly constructed ( take the teapot for instance with a bunch of uv islands) where I assume we would need to cast a ray in a direction and find the next closest surface location and ideally corresponding uv and other attributes to move to… so yeah I like those thoughts of Vincent’s about transfer/spatial sampling…

Re “a way to sample POPs like we do textures, with interpolation and wrapping style configurations included”.

You may have noticed the concept of “dimension” in the last posted build. Where I want to head with this is to be able to treat rows x cols x slices x whatever of regularly-organized point lists, in a way that has no dependency on the primitives that connects them, but just in the organization of the points.

Already you can see in the middle-click popup info (and new python functions and Analyze POP) that where a POP can be viewed as a multi-dimensional set of points, it’s dimension sizes are set in the POPs where possible and then passed on from POP to POP so the structure is not lost.

So you have your points arranged in grids in your example, but then you want to access them them as multi-dimensional grids. You can move them to TOPs and lookup there, but I want to do the same thing natively in POPs (and maybe sacrifice some TOP-efficiency but gain by not converting to TOPs).

So if the Lookup Attribute POP could take 2, 3, 4 … any number of arguments in UVWxxx 0-1 space, or using indexes, with interpolation and wraparound handled, then you can do a lot of this in POPs. So I’m considering something like a Lookup Dimension POP that does this. And we’re putting in new built-in variables so a point knows its address (Indexes and normalized indexes) in the multi-dimensional point space.

Yes this doesn’t handle multiple unwraps in one POP, but maybe it could if they all had the same rows and columns and that just adds one dimension.