Mapping2 to Position?

Beta 3, 2012 sp2

If I have the iterator set to Vertex, I can output Position but not input Mapping2. If I set the iterator to Custom Face Vertex, I can input Mapping2 but not output Position.

What’s the correct workflow for this?

In Vertex iteration mode, you cannot DIRECTLY access mapping channels via InputChannels because the mapping vertices usually don’t match one-to-one the mesh vertices, but you can use VertexQuery with CurrentMesh as input and any of the related mesh channels as outputs. So set Mapping2 as a channel in VertexQuery and drag a wire from the VertIndex input socket onto an empty editor area to create a VertexIndex input automagically. Connect to Position output and you have a representation of the UVWs in object space! (I just tried with TextureCoord on a teapot and it worked nicely).

Thanks. Makes sense now, but I wouldn’t have tried that without your explanation.

So I tried making this into a BLOP, complete with VertexIndex and CurrentMesh. But you can’t expose the VertexQuery channel exposure, so it won’t really work.

Also, the sorting of the channels for VertexQuery is different for InputChannel. It just does it alphabetically, so it lists Mapping10 before Mapping2.

True. The cause for this is: If you add and then remove a channel in the VertexQuery list of channels, it goes back to the list out of order. If you ENTER a custom channel name for some reason (e.g. in the future when we support custom channels) and remove it, it also goes to the list. After a few of these operations, the list would be quite out of order, so I just added a sort() call to keep it always alphabetical. This way you can at least expect Color to be before Mapping, every time.

The lists in Input and Output nodes are queried from Genome itself (to check what is supported) and sorted through custom filters the user can select. The list in VertexQuery is currently hard-coded and does not go through the same acquisition process.

I will see if I can unify the two approaches and make the VertexQuery and FaceQuery lists match the InputChannel Factory Defaults sorting.

I fixed it by adding a leading 0 to the MappingN before sorting, and stripping the 0 after sorting the channels list.
So now you get “Color”, “Mapping2”, “Mapping3”… “Mapping99”, “Normal”, “Selection”,“TextureCoord”

You could have left the padding. We wouldn’t have been disappointed. :slight_smile:

I could not have, because Magma does not support “Mapping02”. I am just writing the UI portion and have to supply what the underlying system expects. The name you see on the list is what goes into the node’s property, and leaving the padding would have broken it…