I created a cube obj in UV mapper (see attached file). The cube has one group "cube". Each face of the cube is one polygon. Each face of the cube has been assigned to a different material zone in UV Mapper.

right (red)
top (blue)
bottom (yellow)
left (green)
front (orange)
back (purple)

I imported the cube into Poser, and assigned a different colour to each material. Red was assigned to the 'right' material and blue to the 'top' material.

In the Poser document window, the right face of the cube, which should be red, is actually the same blue colour as the top face.

It gets even stranger. If I assign a one pixel white image map to the Difuse_Color of the'right' material, it assumes the correct (red) colour, but now the top is the wrong colour, it has changed to yellow, the colour assigned to the 'bottom' material. If I assign the same image map to the 'top' material, it assumes the correct colour, but now the colour of the bottom face is wrong, and requires me to assign another instance of the map, which makes the bottom correct, but now the left face is the wrong colour, and so on. I had hoped that if I added an image map to every material it would fix the problem, but no such luck. With an image map on every material there are still two faces that share the same colour, top and right, same as when i started! :(

I created a new cube, in Hexagon this time, and used UV Mapper to assign the same materials as before. I experienced the same sort of problems, only this time it was the left face that manifested the problem.

The problem only manifests in preview, and is irrespective of ScreeD or OpenGL. Both cubes display the correct colours when viewed in Hexagon.

Questions:

1. Why is this happening?

2. Is this a bug in Poser? In UV Mapper? In the OBJ format? Or is it something that I am doing wrong?

3. Is there a fix for this problem?

Attached is an mtl file for the cube-TEST-002.obj.

I just made my own cube, assigned materials to the sides in Modo and imported into Poser Pro 2012. The preview shows the colors incorrectly although it renders properly. I think this is just something we'll have to put up with.

Quote - I think this is just something we'll have to put up with.

I feared as much.  :sad: Thanks for confirming the bug.

There is a problem in preview on Poser 7 that shows two sides the same color.

Lightwave hates the obj file. It only recognises one default material group. Perhaps the big block of comments in the middle of the file is messing things up ?

Les, what version of UVMapper did you use? In my experience, both Pro and Classic start the output file with the comment:

file generated by UVMapper

• then follows some statistics on the mesh. The comments are never in the middle.

My highest installed Poser version is currently 7, and it's running a render at present, so I can't test - but I do know Poser can be picky about OBJ file formatting.  

Quote - Les, what version of UVMapper did you use?

I used UV Mapper Classic to make the original obj and create the material zones, but since then the obj was exported from PP2012, which accounts for the comments in the middle. Any way I doubt it has to do with UV Mapper, unless Paloth and markschum also used UV Mapper. Paloth made a cube in Modo, and markschum in LW, both those cubes manifest the same type of bug, but neither mention using UV Mapper.

I mapped my cube in lightwave to avoid uvmapper as a source of the problem.

Lightwave would not recognise the material groups in your cube for some reason. It is picky about the obh file format.

I get the problem in poser 7 with your cube , but not with mine.

Quote - I get the problem in poser 7 with your cube , but not with mine.

That's really strange. I don't have P7, but I tested your cube in PP2012, P8, and P6. I get exactly the same incorrect result in all those versions as I described in a previous post. It seems incredible to me that your cube should not work in all those versions, and yet should work OK in P7!
:blink:

My cube also suffers from exactly the same bug in all those versions. The only difference in the bug between my cube and yours, that I see, is that in my cube the right face (my left hand side) adopts the colour assigned to the top face, and in your cube the right face adopts the colour assigned to the bottom face. P.S.

Any takers to test markschum's cube in any Poser versions you have available?

Quote -
Any takers to test markschum's cube in any Poser versions you have available?

I can confirm that the bug manifests for me too, using mark's cube.

Poser 7.0.2.132 is my version.

OK, my apologies, I now get the same problem with my cube except its the bottom and one side thats bad in preview. 

I was sure it was working ok, so I will go back and try to recreate it to the same size and uv layout.

Any clues as to what the bug is ?

Quote - Any clues as to what the bug is ?

No, but...

We have three cubes, mine, Paloth's (only pictures), and markschum's.

Each cube inherits the wrong colour from a different face, the top for mine, the front for Paloth's, and the bottom for markschum's, but the face that inherits the wrong colour is the same in all three cubes. Can this just be coincidence? All three cubes were created in different modelling applications.

There is some room for verbal confusion here, because I call the "right" face the face that would be nearest to the cubes right hand if the cube were to be given hands, where as markschum calls the "right" face the one that is seen to be on your right hand side when looked at from the front. I'm not saying one is correct and the other wrong, just pointing out that we need to be careful that we understand what each of us mean by "right".
P.S.
Here in the U.K. a car driving on the right side of the road is driving on the wrong side of the road!

:blink:

This bug goes back to Poser 6 at least. I don't have Poser 5 installed any more, but I can say it isn't present in P4. I suspect the blame lies with the new preview code that was introduced along with the Firefly renderer in P5. For me, it's present whether I use OpenGL or SreeD preview modes.

What's surprising is that I haven't seen it before - although I have seen other strange preview effects.

Now this is interesting! Here is a facet list from a cube:

        usemtl right
        f 1/1 2/2 4/3 3/4
        usemtl top
        f 3/5 4/6 8/7 7/8
        usemtl bottom
        f 5/9 6/10 2/11 1/12
        usemtl left
        f 5/13 7/14 8/15 6/16
        usemtl front
        f 2/17 6/18 8/19 4/20
        usemtl back
        f 1/21 3/22 7/23 5/24

The right face is at the top of the list, and that is the face that gets the wrong colour. Below the order of the order of the usemtl blocks has been edited so that the top face is now at the top of the list:

        usemtl top
        f 3/5 4/6 8/7 7/8
        usemtl right
        f 1/1 2/2 4/3 3/4
        usemtl bottom
        f 5/9 6/10 2/11 1/12
        usemtl left
        f 5/13 7/14 8/15 6/16
        usemtl front
        f 2/17 6/18 8/19 4/20
        usemtl back
        f 1/21 3/22 7/23 5/24

Can you guess which face now displays the wrong colour? That correct, it's the top face that is now wrong. What about this one?

        usemtl bottom
        f 5/9 6/10 2/11 1/12
        usemtl top
        f 3/5 4/6 8/7 7/8
        usemtl right
        f 1/1 2/2 4/3 3/4
        usemtl left
        f 5/13 7/14 8/15 6/16
        usemtl front
        f 2/17 6/18 8/19 4/20
        usemtl back
        f 1/21 3/22 7/23 5/24

You guessed it! It is the bottom face that now displays the wrong colour. It seems that whatever face is at the top of the list, will be the one with the wrong colour. No other parts of the geometry were changed, only the order of the usemtl blocks.

Its amazing that this hasn't been noticed by everyone if it happens all the time.

My sense of right and left is marginal, I navigate by LEFT and OTHER LEFT preferably with pointing :)

Les wins his very own INTERWEBS !!!

perhaps a usemtl line with no allocated faces ?

OK, I think I found a fix.

Here it is. Place a usemtl block named 'Preview' at the top of the facet list. Then add the facets from the block below to that new block (it may not matter what facets you used, but that's what I did). Here is the facet list (I'm not really sure if that is the correct name for this part of the file) from my original cube:

usemtl right
f 1/1/1 2/2/2 4/3/4 3/4/3
usemtl top
f 3/5/3 4/6/4 8/7/8 7/8/7
usemtl bottom
f 5/9/5 6/10/6 2/11/2 1/12/1
usemtl left
f 5/13/5 7/14/7 8/15/8 6/16/6
usemtl front
f 2/17/2 6/18/6 8/19/8 4/20/4
usemtl back
f 1/21/1 3/22/3 7/23/7 5/24/5

Below is the amended facit list:

usemtl Preview
f 1/1/1 2/2/2 4/3/4 3/4/3
usemtl right
f 1/1/1 2/2/2 4/3/4 3/4/3
usemtl top
f 3/5/3 4/6/4 8/7/8 7/8/7
usemtl bottom
f 5/9/5 6/10/6 2/11/2 1/12/1
usemtl left
f 5/13/5 7/14/7 8/15/8 6/16/6
usemtl front
f 2/17/2 6/18/6 8/19/8 4/20/4
usemtl back
f 1/21/1 3/22/3 7/23/7 5/24/5

This worked to fix my cube, and I suspect that it will generalize to fix this bug in any prop. I'm not quite sure how to implement the fix in markschum's LightWave obj, as the data is arranged differently in a LW obj.

Poser adds a 'material Preview' to any library file it creates, and when you import an obj that gets a 'material Preview' as well (but not a 'usemtl Preview'). I guess Poser somehow gets confused when there is not a 'usemtl Preview' in the geometry.

Quote - My sense of right and left is marginal, I navigate by LEFT and OTHER LEFT preferably with pointing :)

ROTFL :lol::lol::lol:

Quote - perhaps a usemtl line with no allocated faces ?

I tried a 'usemtl Preview' with no facets, but it did not work. I suspect that what facets you actually use may not be important, though I have not tested that

Quote - Its amazing that this hasn't been noticed by everyone if it happens all the time.

I was also wondering why this hasn't been noticed before, so I did some more tests.

It seems to be related to the fact that the test cube has only one facet in each usemtl assignment. If I triangulate the test cube, the problem is no longer apparent in Poser 7 at least - I'd be interested to have it confirmed if this is the case in later versions too.

Incidentally, you can have more than one single-facet-per-material cube in the scene, and each one displays the same bug. We don't see it all the time because there are very few meshes which have only one facet assigned to a material, and even fewer where it's the first assignment in the file.

Possible further study - does only the first facet have to be triangulated, or the whole object?  

Good work Bob! That advances our understanding of the issue.

Quote - does only the first facet have to be triangulated, or the whole object?

I did a test of that. Triangulating the first face did not solve the problem, though it did change which face the wrong colour was inherited from. In my cube, the 'right' (first) face, which used to inherit from 'top' (second) face, now inherited from the 'bottom' (third) face. Neither did triangulating a lateral ring of four faces kill the bug. Triangulating the whole cube did work.

I was blethering on about how unlikely this was to occur in "real life" when I realised that one of my most-used props was made this way. I use my Basic Box prop in nearly every scene, at least as a set-up aid which is deleted later, and sometimes it forms the background with suitable materials applied. The three walls and the floor are all single polygons.

On trying it out, I found that, as might be predicted, preview wouldn't display colour changes to the back wall material (which is the first usemtl in the geometry file), and that changes to the right wall (the second assignment) are repeated on the back wall. Everything renders properly, as previously noted. I'd never seen it before since I never apply plain colour to the box walls; it's always an image map of some sort if it stays in the scene at all.

With that in mind, it's odd that the preview would handle (relatively) complex stuff like image mapping, but not simple-seeming stuff like colour. What's more, once maps have been applied, the faces can be coloured and preview properly! That's an anti-aliased preview posted above.

Poser, you are awful, but we like you. :-)

(Edited for clarity)

ok now im confused even more

i just did it with a cube from 3 different versions of blender all mapped and it was the same result

im using 7 pro and have no working understanding of it maybe it shuld be pointed out to smithmicro if it hasnt already been

i remember things by sight and not name so this makes it even more difficult to learn

I wouldn't worry about it, personally. As we've mentioned, this bug rarely causes trouble, and it doesn't affect the final render. We're all well used to the preview not looking like the finished article anyway.

It probably should be reported as a bug, but I doubt SM would care about a report from a Poser 7 user. ;)

It sounds more complicated than a simple coding error, like starting at 1 instead of 0 in an array. I concur, since a lot of node based materials dont show in preview and even some image map stuff you really need toput a render in the workflow. It should be reported if it is still in Pro 2012 but I wont wait for a service release on P7. I too have a similar basic room prop that gave me problems with the ceiling. I gave up on it and made a more complex geometry but it will be interesting to see if its this bug.