Mapping Pixels for singing faces

[MSDowney]

I am having a problem with pixel mapping in xLights.  This post might get a little long and I apologize for that up front but I really need some help

I have a Halloween Face from Boscoyo.

I filled it with pixels and some are not showing because I had to span a distance between holes.

In my Spread sheet I created the face.  While numbering the pixels I always skipped the ones not showing so there are jumos in the number (If I had to miss one pixel between the eyes the number of the pixels would skip like 60 62... 61 being the pixel not showing)

So then I have it all mapped out.

I bring in the nodel into xLights and all is good.  All the numbers are exactly like I had in the spread sheet.

When I create the mouth shapes I notice something.   The nodes are now compressed.  Like it is only numbering the pixels that show.

I create the mouth positions and and everything looks good.

I have a test sequence that I only try one mouth shape at a time so it doesn't take long to render.

The eyes light up correctly everytime.  But the mouth is hit or miss.

Example.  Mouth shape AI... it has most of the pixels correct but it doesn't light the last 4... it DOES light up four pixels that are not even close in node number to the unlit ones.

I then go into the test area and look in the model and test them one at a time.  In the test area it includes the node numbers of the nodes not showing but each node lights up exactly the way it should.

I am really confused as I have uninstalled xLights (Including wiping everything in the registry)  and re imported the models and rebuilt the mouth shapes several times.  I can't get it to work correctly.

I added a couple pictures to help out.

Any thoughts you have on this are completely welcome!

[jnealand]

I would double up a pixel number where you are missing one.  There is no rule that you can only use each number once.

Edit:  I take that suggestion back.  I don't think that is going to help.

[MSDowney]

Thank you Jim... I will do that on the pixels where there is not light but I do not understand why the four in the "O" are lit up.   There number is no where close to the nodes selected

Update:  I tried it and no change.  it is like the program is thinking that the nodes at the top of the mouth are actually in the "O" instead

[keithsw1111]

Sounds like a mismatch between models and controllers. Can you export your models and attach your networks file and rgb effects files.

[MSDowney]

I have attached them... Thank you for looking at them

[Gilrock]

I find it quite curious that the lights not lit are 201, 202, 203, and 204 and the ones that are lighting up are 301, 302, 303, 304.  You sure you didn't type in "3" instead of "2" for some of the shapes?

[Gilrock]

I can't run xLights at the moment so I can only inspect text files.  Your AI definition for Face 3 only goes up to node 192 so I don't even see how it's lighting up what you show in that screenshot.

[MSDowney]

That is part of what confuses me...  The AI doesn't go to 204 in the faces screen it only goes to 192. 

The Map that shows the nodes when making the mouth positions has a completely different numbering than the model Data screen.

I also do not have nodes selected after 192.

The first node of the AI is 89 rather than 101.  It seems to ignore any nodes numbers that are skipped in the model data and number the next node to the next consecutive number.

Example:

Last showing node of eyes in the AI  88 (in the model data it is 94)
The first node of the AI is 89 (In the Model data it is 101)

When I am in the test window the numbers match with the Model Data numbers (My original numbers)  but it never lists all of the channels.  When I light up the model in the test page it lights up everything correctly but it will not light a few at the end.  If I create the same model data with all of the missing nodes numbered as well then it does light it all up.  (That includes the nodes on the last string that are left over.  So I have to have every sting go to 100 in the model or it will not list all of the channels)

[Gilrock]

I'll have to wait till I can look at this in the program.  I haven't messed with the Face definitions since the other guys added that code to light up the nodes you are specifying.  From your description it doesn't sound right to me.  It should have been coded such that node numbers are always consistent.

[MSDowney]

Thank you so much for your help.

 The kids in the neighborhood have been waiting to see these faces for 10 days and I am stressing about it.  I know it is not all that important in the scheme of things but I always hate disappointing the neighborhood kids.

[MSDowney]

The mapping problem of the niodes 201 - 204 mapping to 301-304  was a Controller problem.  So I deleted that part of this thread.

[MSDowney]

THis is a reply

[kentd]

I have been working on these same type of faces myself and I downloaded your layout.
Here is what I have found from my own experience.
Just looking at your custom model of face 3 say the eyes numbering
You start with node 1 thru node 17 down the bottom and then jump to node 21 thru node 37 going up the other eye.
xlights is not going to give you that skip in the middle, it is going to calculate that as 34 nodes total and assign say nodes 18 thru Nodes 34 to the bottom of the eyes for eyes closed position.
I found this when I accidentally got one of my nodes duplicated and then went to put the node numbers into the face outline definition. I should have had a larger node number available to me than what the definition allowed me to have.
You may want to really look at your custom numbering for these kind of skips as it will cause you consternation.
Just my 2 cents worth and I may be wrong
Kent

[Gilrock]

I believe it was an oversight when the face definition preview was created.  I've talked with Keith and I believe he is going to try to fix it.  It would make more sense for the node numbers to remain consistent even if you skip a few.

[MSDowney]

I found that out the hard way Kent.

I was taught that you do not number the nodes that are not visible but that really screws things up in the program. The developers already know about it and will look into it.