SDK Feature Request: Polys from point and UV selection scan

Vorlath

New member
First request is the ability to get the polygons associated with a point. Right now, it seems that you must get the edges from the points and from the edges, you get the polygons. This isn't that big a deal, but seems like there should be a better way to do this. It would be nice to be able to get the edges from a polygon as well.

Right now, it's points -> edges -> polygons -> points. Going the other way is really painful (except for edges to points).

The second request is the main one I'm interested in. I'd like to see more UV tools, but the inability to know what UV points were selected means that many tools simply cannot be built. For example, if I wanted to write the move tool as a plugin for UV's, I can't do it. If I'm mistaken, please let me know. So I would like the ability to get the polygon ID's for each selected point. A null polygon ID means it is continuous UV.
 

jwiede

Electron wrangler
First request is the ability to get the polygons associated with a point. Right now, it seems that you must get the edges from the points and from the edges, you get the polygons. This isn't that big a deal, but seems like there should be a better way to do this. It would be nice to be able to get the edges from a polygon as well.

Right now, it's points -> edges -> polygons -> points. Going the other way is really painful (except for edges to points).

Agreed! For efficient processing, helpers to extract all "associated geometry" for points/edges/polys would be quite welcome. LWSDK can directly reference the geometry data lists, while plugins would have to build and maintain external copies for fast cross-referencing (horribly wasteful). It just makes more sense to offer such helpers as LWSDK APIs.

(I'm answering the second part of your post in a separate reply, because of its length)
 

jwiede

Electron wrangler
(continued from prior reply)

The second request is the main one I'm interested in. I'd like to see more UV tools, but the inability to know what UV points were selected means that many tools simply cannot be built. For example, if I wanted to write the move tool as a plugin for UV's, I can't do it. If I'm mistaken, please let me know. So I would like the ability to get the polygon ID's for each selected point. A null polygon ID means it is continuous UV.

I think this all stems from a common LWSDK API problem w.r.t. UV vmaps: There can be multiple UV vmaps, so such queries are ambiguous unless a specific UV vmap context is provided. At the same time, from the querent's perspective, there's no easy/efficient way of knowing all UV dataset contexts associated with a point short of iterating through all of them, and checking the return result of pntVIDGet/pntVPIDGet for each candidate vmap.

Right now, for manipulating UV's, the only acceleration approach is to build your own parallel set of point/poly-based relationship accelerator arrays in memory, and regenerate them from scratch any time the object geometry changes -- unfortunately, that's extremely INefficient in practice. What's really needed, IMO, is a restructuring of the whole mess of how UV's are handled, to avoid the horribly-slow point-poly-vmap iteration/enumeration dance.

IMO, a better answer would be something like a set of "uvinfo" interfaces, parallel to "meshinfo" but focused around iterating and manipulating "UVPoint" entities in a given vmap. That would necessitate building and maintaining (at least temporarily) a bunch of "reverse-indexed" acceleration data structures (mapping "UVPoints" to LWPntIDs & LWPolIDs for a vmap) which incurs setup costs, but I believe taking UV-related tool contexts/workflows into account can mitigate some of that overhead.

Unlike meshinfo, uvinfo wouldn't necessarily need to be available at all times for all possible vmaps and so forth. It all depends on how much memory LW3DG is willing to set aside for such acceleration structures. What uvinfo's APIs (and meshinfo's!) DO require, is better API design around multithreaded access and manipulation -- again, that probably equates to a thread-friendly tool "work context" lifecycle of some sort.

Right now, Meshinfo is horribly designed w.r.t. multithreading, and while pntVIDGet/pntVPIDGet help, they aren't nearly enough by themselves. The whole notion of meshinfo access and iteration needs to be redesigned in a multithreading-viable manner. We'll see if the new geometry engine yields any meshinfo multithreaded-access improvements in LW.Next -- I hope so, but am also prepared to be disappointed.
 
Top Bottom