Morkonan opened this issue on Feb 12, 2009 · 77 posts
Morkonan posted Fri, 13 February 2009 at 8:50 PM
Quote - Morkonan, just a idea.
Did you check the sort order of the uv values in the obj files with different projection modes on one side and with rearranging the uv in the planar mode on other side.What do I mean.
I remember one of the purposes of STOMP. There was (is) a flaw in poser up to version 6. If in 7 I don't know at the moment.
If you have several material zones in a object, this may be saved as single divided parts as they are coming handy to the model app while saving.
If poser is reading such clustered materials it need's much much more time as if that material zones are saved together.
So STOMP as also the riptide object exporter for C4D (same author I guess) are saving that data sorted by material.
So this will change the sort order in obj file and that load's than quick as the wind.May it be that such a ordering problem is touched here again.
- If you start with a planar map and later rearrange that map does this change the order while saving in object files.
- And is the sort order influenced depending which map mode you choose first ?
- If so what will happen if you arrange the sort order of a cylinder map like the order of the planar map. Ok, this have to be done by hand editing the obj file.
But than it could be clearer why map projection mode is of influence.Just as an idea. Poser isn't doing things a logical manner all the time, is it ?
Hmm, interesting idea. I'll do some file comparisons. As a matter of fact, I was planning on trying exactly what you just described but, not with as detailed a reason. I wanted to find a way to "remap" the object by hand using only the contents of the file in just such a way as you suggest. That way, I could try to change how the object's UVMap was projected without using a mapper to do it and see if there could be any interesting results. I'm also going to go overe the wavefront.obj file specification and check to see if there are any interesting file commands I can find. Another thought is to export in other formats besides .obj and see if these anamolies continue to appear in different projection mode. If not, it could be a clue as to why projection mode seems to matter so very much in this experiment.
I downloaded STOMP the other day and am also going to do some .obj tweaking with it to see if it might isolate the variables that are effecting these renders. I'll do the file contents comparison later this evening.