UV-map weirdness

[Tore]

Having experienced some strange behavior when handling UV-maps in A:M, I am wondering if I am doing something wrong, or this is a bug.

 

It goes like this:

 

1. I make a (in this case very simple) model in A:M.

 

 

 

2. Exporting the model (without UV's) as an .OBJ

 

 

 

3. Importing the model into 3DCoat.

 

 

 

4. ...and gets this automatic UV unwrapping.

 

 

 

5. Still in 3DCoat I then paint something on the model.

 

 

 

6. And export the model as an .OBJ with enclosed Targa color map.

 

 

 

7. Back into A:M I import...

 

 

 

8. ...and gets this distorted result - even if I render the model. The projection bulges and weave, and the seams are misfitted.

 

 

 

 

10. Looking at the model in A:M's UV-editor reveal the problem:

the UV-splines are not coherent with the model splines, and they weave in and out of the grid.

 

 

 

First I beleived this to be an error in the way 3DCoat generated the UV map but having tried same procedure in numerous other ways, including making the UV by hand as a single island, making the UVs in A:M (as tiled one-patch sized islands) and export them out of A:M together with the model, and trying all of these methods in ZBrush instead - every time with approximately the same ugly result.

 

Well, that was my sad little tale - anybody have some input on this?

[thefreshestever]

i don´t really know anything about this, because i don´t work that way... but what seems logical to me that if you paint on peaked points the result has to be somewhat distorted after importing it back into a:m as a curved mesh.

[Tore]

Oh, and by the way my software versions are:

 

A:M 17.0g 64bit

3DCoat 4.00 beta 14 a1 (GL 64bit)

ZBrush 4R5

 

PC/Windows 7

[thefreshestever]

just made a test... applied a decal to a peaked surface, then set the curves to smooth again. this is what i thought would happen...

[Tore]

applied a decal to a peaked surface, then set the curves to smooth again. this is what i thought would happen

 

Hmmm...interesting. But even so, I don't understand why this bulging and inconsistency in the widht of the stroke occur. In my oppinion it shouldn't. If applying paint to a UVed subdivision model (say in ZBrush), and you step down to the lowest subdiv level, no distortion happens in the colormap.

A:Ms splines are not that different from a subdiv model - A:M even splits the models up in polygons when rendering.

 

The problem here lies somehow in the way the UV-vectors are pinned to the spline-mesh/cage, I guess...

[robcat2075]

I would ascribe the difference to the fact that 3DCoat is a polygon tool that doesn't understand the smooth spline interpolation between CPs in A:M models. It presumes the edges of the patches were straight lines but they really weren't.

[thefreshestever]

if you take a close look at the bulging and width inconsistency, you will see how it fits the way the mesh is distorted via the bias handles. a:m does work differently than subdiv models because of the bias tweaking that takes place. it isn´t just a subdivided mesh, you can control the curves exactly with the bias-handles. if a:m wouldnt work that way, you couldn´t control the shape of a curve that exists between 4 cps.... but you can, and that is the reason why a decal painted on a peaked mesh won´t work correctly on a curved model in a:m...

 

just run a simple test as i did above, and then additionally tweak the bias handles, you will see how everything makes perfect sense.

[robcat2075]

4. ...and gets this automatic UV unwrapping.

 

 

Here's what I don't understand... why is this fragmented layout preferable to having one continuous map that covers the whole surface?

 

With a cylindrical wrap you can have coverage in one unbroken map and not have to convert to a non-A:M format either.

[Tore]

Here's what I don't understand... why is this fragmented layout preferable to having one continuous map that covers the whole surface?

 

With a cylindrical wrap you can have coverage in one unbroken map and not have to convert to a non-A:M format either.

 

Well, it isn't really about the shape of the UV-map. Wether it is split in islands or it is one continuus map or it is cut by hand or it is done as AUV map, the result is the same. As i stated above, and as you can se on these tests:

 

Here I have split the UV-map by hand in 3DCoat:

 

 

 

Here the UV are created by A:M as a cylindrical map (have tried spherical too)

 

 

 

And the result always ends up distorted:

 

 

 

Furthermore, if the model is even a tiny bit more complex then a vase, the cylindrical map method simply doesn't work, as the map splines of say extruding parts wil get overlayed UVs, PLUS the distortion.

[thefreshestever]

i´d say it always ends up distorted if you paint on a peaked model that will later be curved, no matter how you do the unwrapping. my guess would be that it simply doesn´t work because of the reasons i´ve explained above. splines aren´t polys, "subdivision" works differently in a:m. or did you have success with this in the past and it´s just not working anymore somehow?

[robcat2075]

Furthermore, if the model is even a tiny bit more complex then a vase, the cylindrical map method simply doesn't work, as the map splines of say extruding parts wil get overlayed UVs, PLUS the distortion.

 

It's not hard to make a pose that corrects overlapping splines, then do the cylinder map. That's how I did my Al Capone head which has many overlapping parts.

 

Because I didn't want to devote a lot of map to the top and back of the head, I made one pose for the face and sides of the head and another for top and back of the head. I hid the top/back and stamped most of the cyl wrap on the face pose, then I hid the face/sides and stamped a little part of the map on the top/back pose.

 

That got me this UV layout on the model which i can paint in 3Dpaint or in Photoshop and never have to convert to an OBJ.

 

(the map shown is the hair density map)

 

 

 

It's not "automatic" or instant, but in the time you spend trying to make 3Dcoat work you could do this and be done already.

[Fuchur]

What happens, if you just use the resulting texture-map from 3DC and use it for the decal in A:M and do not reimport the whole model?

 

The usual way is this:

1.) Use A:M to unwrap (for instance with BakeSurface)

2.) Export to OBJ. I think you can use any kind of subdivision here, which should be the key to your problem. (with a high subdivision count, the distortion should get smaller and smaller).

Try it with 16 subdivisions for instance. (in v18 there will be much higher subdivision-levels here, but I think this is all you have in v17 for now)

3.) Import it to 3DC.

4.) Paint on it.

5.) Export / Save ONLY the texture-files.

 

6.) If you saved the textures using the same path and filename, you need to get A:M to update that. I often do it by opening the UV-editor once) / Otherwise (which works better in my experience) you have to reimport the image and assign it to the decal on your model (drag and drop it to decal > Image-Folder). Delete the first image assigned there.

 

Does this result in distorted maps too? (it can be, but I am not sure about it.

 

See you

*Fuchur*

[Mechadelphia]

I would ascribe the difference to the fact that 3DCoat is a polygon tool that doesn't understand the smooth spline interpolation between CPs in A:M models. It presumes the edges of the patches were straight lines but they really weren't.

 

Hi ToreB,

 

I think that what robcat2075 said there is pretty much the basis of the problem that you are running into.

 

The workflow that you are describing (exporting models out of A:M, adding uv coordinates in a polygon application, and then importing them back into A:M ) does not seem like an optimal workflow when working with A:M. I don't think that A:M was designed with the level of interoperabilty that you are expecting in mind.

 

Yes, I know this is a very common or even standard practice when working with strictly polygon based applications but A:M is not one of those programs. Also, UV mapping in A:M is usually not as cut and dry in a way that you might be used to with other polygon based applications.

 

If you have not already, you should look into some of the UV mapping tutorials that were done in A:M. That might serve you better than trying to incorprate A:M into this particular pipeline that is better suited for other programs.

 

I don't want to seem dismissive to you since I really do understand what you trying to do but I think you should try to map your UVs within A:M or try A:M Paint if your final output will be coming from A:M.

[robcat2075]

One could lobby the 3DCoat people to modify their product to properly import and export meshes made in A:M MDL format.

[Malo]

The problem come from the import Obj plugin in AM. It's Uv is bad.

The Uv for the Props is good.

If I use Troer to convert Obj with his UV, I get good results too :

[Tore]

I have several times tried to come to grip with the method you're describing, Fuchur, unfortunately unsuccesfully. When baking in A:M I can't choose the size of the maps, and ends op with some irregular and very small sizes. 200x100 pixels or something like that. And when exporting to .OBJ A:M asks me to rename the bitmaps to accomodate DOS naming conventions. Whatever my respond A:M crashes before it saves anything...

 

Mack, you're propably right - I'm beginning to come to the conclusion that A:M is not suited to work with other software. A pitty though!

Of course except for 3Dpainter. I own that program, but it has some major quirks that make it very difficult to work with, in my oppinion: It cannot paint across seams, except when in projection mode which on the other hand is painstackingly slow - on complex models I have experienced waiting times of 5-7 minutes. Completely unfit for a fluent workflow. And further development on that software seems to have come to a halt.

 

So it seems the only possibility left is what you say, Rob: to hope that 3DC (or ZBrush) include .MDL importing/exporting...

[Tore]

Malo, that seems to explain a lot - there apparently IS a bug in the A:M importer! That means it can be fixed!! :-)

What by the way is Troer??

[Malo]

Hi ToreB,

 

"Troer" is a free standalone converter OBJ2MDL. (It can't convert all Obj)

There are more explications in this topic :

http://www.hash.com/forums/index.php?showtopic=40743

[robcat2075]

When baking in A:M I can't choose the size of the maps, and ends op with some irregular and very small sizes.

 

Hold down the shift-key and you get the option for other resolutions

[Tore]

Malo, I found out, and I am just now trying out this nifty little converter. Have to experiment with flip u/flip v combinations, and when I open the converted .mdl sthraight into A:M 17 it crashes. Need to create a new empty model and then import the Troer-made .mdl into that, to make it work. If I can get it to work properly, it will solve a lot of problems. Thanks a lot!!

 

And thanks Rob for the shift-key trick - I'll try it out shortly.

 

And anyways the A:M .OBJ importer seems to be broken, so I guess that needs to be reported in Mantis.

[Malo]

Yes since version 17, there is a problem with the UV of the mdl converted by Troer.

At the end of the topic http://www.hash.com/forums/index.php?showtopic=40743 , we talk about it. The solution is to download the version 16 of AM, and open your mdl via import mdl in a empty modeling window, and save it, to open it again in version 17.

This is hugely steps and constraints. But it works.

[robcat2075]

Yes since version 17, there is a problem with the UV of the mdl converted by Troer.... The solution is to download the version 16 of AM, and open your mdl via import mdl in a empty modeling window, and save it, to open it again in version 17.

 

Have you made a bug report for this?

[Malo]

Hi Robcat!

No, because it's not a bug from AM.

I did not understand all the way to encode the Mdl format. Troer written an incorrect file. Luckily before version 17, AM rectified the code, now it no longer does as expected. But it is not a bug.

Nothing to do, I read quickly in a topic, the closure of 5-sided patches will be automatically ... Is this true? If this is the case, it will be great.

[robcat2075]

Hi Robcat!

No, because it's not a bug from AM.

I did not understand all the way to encode the Mdl format. Troer written an incorrect file. Luckily before version 17, AM rectified the code, now it no longer does as expected. But it is not a bug.

 

I'm not sure I understand you... is the importer in v17 working properly or not? If it is working properly, then the importer is not Tore's problem.

 

 

Nothing to do, I read quickly in a topic, the closure of 5-sided patches will be automatically ... Is this true?

 

I don't know if that is going to happen or not.

[Fuchur]

Hi Robcat!

No, because it's not a bug from AM.

I did not understand all the way to encode the Mdl format. Troer written an incorrect file. Luckily before version 17, AM rectified the code, now it no longer does as expected. But it is not a bug.

 

I'm not sure I understand you... is the importer in v17 working properly or not? If it is working properly, then the importer is not Tore's problem.

 

 

Nothing to do, I read quickly in a topic, the closure of 5-sided patches will be automatically ... Is this true?

 

I don't know if that is going to happen or not.

 

Till now there is no feature like that. I think it is just a rumor because jason (not hash) wanted that feature. I am not sure if steffen is working on it but when i asked last time he said he is not working on it. (This was years ago).

 

Malo just said that Troer writes a wrong mdl-file. In v16 A:M did correct errors in the code 9f the file since A:M v17 this recoveryalgorithmus / rebuilt algorithmus is no longer used. I am not sure if this is a bug or just optimisation by steffen. It could be thst this is necassary in some way but asking steffen will not harm.

 

See you

*Fuchur*

[robcat2075]

OK, who makes Troer? Could we just get them the right MDL code?

[Malo]

Benoit is the programmer of Troer. This is a friend who knew very little in 3D, and nothing in AM. It was kind of program Troer in his free time.

Troer is not the solution to long therm. It would be better to improve the import AM plugin (and also export with more options).

 

To return to the issue of the wizard import.

I think it would not be difficult to fix it.

It seems to me that the calculation error come from there is a confusion between the tier of the side and the tier of the magnitude.

I'm sorry if I'm not very clear in my English.

A picture to help to understand:

[pixelplucker]

I could never get Troer to work.

 

Anyways to use 3d coat for painting the workflow should be like this...

 

Make the model in AM

Either bake a set of uv's or unwrap the model within AM with decals (I use a grid pattern as a base texture)

You need to generate UV's in AM for the AM model for the cp's to be able to read them correctly.

 

Export a dummy model as an obj along with maps.

 

Bring the obj into 3d coat and paint it then save out the textures.

 

The new textures are what you will be using in AM on the AM model. The obj isn't needed anymore.

 

I tried to get Andrew at Pilgway to make a reader for AM but they said it would be too difficult. They would do it for a fee though, funny how green stamps can lubricate the production cycle isn't it?

[Rodney]

Benoit is the programmer of Troer. This is a friend who knew very little in 3D, and nothing in AM. It was kind of program Troer in his free time.

Troer is not the solution to long therm. It would be better to improve the import AM plugin (and also export with more options).

 

To return to the issue of the wizard import.

I think it would not be difficult to fix it.

It seems to me that the calculation error come from there is a confusion between the tier of the side and the tier of the magnitude.

I'm sorry if I'm not very clear in my English.

A picture to help to understand:

 

Interesting. It seems to me that the primary user variable would be one of scale.

The user would know and opt for the desired increase in the fidelity/scale which would take longer to compute out to greater decimals.

In other words, the (fast) default might be .3 but the user could crank that up to .333333... (or whatever percentage desired) to obtain greater subdivision/resolution of detail.

[robcat2075]

I'm afraid i don't understand that diagram.

[thefreshestever]

I'm afraid i don't understand that diagram.

 

thank god, i´m not alone!

[Malo]

Sorry, It is not easy for me to explain this in english.

 

In the UV window, a patch have bias, but you can't see them.

A polygon have not bias.

To write an UV for a polygon, you need to write the X Y and Z coordinate for each vertices.

For a patche you need to write the coordinate for each CPs and for each bias (8) (in blue on the graphic)

 

 

The problem when you import the UV of a polygon, you have no coordinates for this bias.

So you must create them. (The CPs have the same coordinate as the vertices)

For Troer, I use the 1/3 of the side for each bias.

What I understand about the wizard plugin, is : it use the 1/3 of the magnitude of the CP, so the the map in the patch is deformed.

[pixelplucker]

When an obj is exported (reference mesh) it picks up the cp uv mapping if it exists and subdivides the patch into polygons. The subdivided patch includes the polygons inside in the uv groups.

 

This makes the uv mapping unidirectional where by you need to create the uv's within AM because there is probably no real way to merge the uv data back to a cp since you can't decimate the model back into splines and patches and I am guessing it is most likely due to the 5 point patches and 3 point patches that are non quad.

 

So the bias interpretation works by area of influence base uv to cp locations in 3d space? I still haven't been able to get the importer to work.

 

Still not sure why 3rd party companies can't download an SDK and just make a direct importer/exporter for uv mapping of AM geometry. Wouldn't that be better than trying to convert this stuff?

[robcat2075]

As far as I know there is no provision to include in an OBJ the spline biases and magnitudes and directions that are in an A:M mesh. All exporting to OBJ can do is preserve the spatial location of the CPs and connect them with straight edges; it can't preserve the shape of the splines that connect them, it can only presume they were straight edges.

 

If you paint on the OBJ in another program and then import that back to A:M I don't see any way you can get back exactly what you started with, nor can taking the new paint maps and putting them on the original model work exactly right because the OBJ that was painted on and the original A:M model are not really the same shape.

 

They might be close enough to work sometimes but it can't work 100% of the time.

 

Am I missing something?

[Malo]

From what I understand, and so I thought Troer.

 

The uV a patch is subdivided into nine areas defined by the bias.

 

 

The picture of the UV polygon is divided into 9 part to be distributed to each area of ​​the patches.

 

If the bias is not located in tier length, there will be deformation.

 

And I think, the bias coordinate of the wizard plugin is calculate on the 1/3 of the % magnitude and not on the length of the side. But I ma not sure.

What I am sure, the bias coordinate of the wiazrd is not on the 1/3 on the lenght, and it is why there is bad result.

[pixelplucker]

All exporting to OBJ can do is preserve the spatial location of the CPs and connect them with straight edges; it can't preserve the shape of the splines that connect them, it can only presume they were straight edges.

 

This is why it would be best if the paint programs had an 1/0 to read the mdl files directly. Hop scotching from one format to another then back is never a good idea.

 

Using am obj as a reference shape to paint on is a descent approach.

[robcat2075]

Is this workflow possible?... I see hints of it above but I'm not sure...

 

-export an OBJ that is highly subdivided so that the curves of the shapes between the original CPs are preserved.

 

-paint on OBJ that in the poly paint program

 

-fit the map that results back onto the original, lo-density spine model.

 

 

Is that already possible?

[zandoriastudios]

pixelplucker described exactly that workflow a few posts back, so yes I think it is already possible

[Fuchur]

Is this workflow possible?... I see hints of it above but I'm not sure...

 

-export an OBJ that is highly subdivided so that the curves of the shapes between the original CPs are preserved.

 

-paint on OBJ that in the poly paint program

 

-fit the map that results back onto the original, lo-density spine model.

 

 

Is that already possible?

 

If you use A:M to decal, that should work yes. (I described above how it should be done)

At least it worked with 3d Coat for me.

 

See you

*Fuchur*

[robcat2075]

Is this workflow possible?... I see hints of it above but I'm not sure...

 

-export an OBJ that is highly subdivided so that the curves of the shapes between the original CPs are preserved.

 

-paint on OBJ that in the poly paint program

 

-fit the map that results back onto the original, lo-density spine model.

 

 

Is that already possible?

 

If you use A:M to decal, that should work yes. (I described above how it should be done)

At least it worked with 3d Coat for me.

 

See you

*Fuchur*

 

So... ToreB can have a good result with painting on A:M models, but he will need to decal first in A:M. That one change to the workflow is all that's needed, right?

[Fuchur]

Yes it should work... at least it worked with 3dCoat for me.

Dont use any micro-modelling-tools (like in ZBrush) / Voxels (or you need to use the retropology-tools of A:M) but only paint on the decal / texture whatever you like to do there and it should work.

A slight distortion can occure with v17 since the subdivision-level of 16 can be not enough, but with v18 (up to 2048) this problem is gone too.

 

And since he is using an 3d Painter-programm decaling can be done by using BakeSurface so this should not be a bigger problem neighter.

 

See you

*Fuchur*

[thefreshestever]

but what happens if i have tweaked biases in my model? even if i can export up to 2048 subs, the export plugin always presumes i´m using a untweaked magnitude of 100, right?

[Malo]

A hight subdivision in V18 will help to have a good result.

Do you know, when V18 will be finish?

 

 

Here's a little experiment I do today:

 

I create a model. I just peak the model in modeling window before to apply UV. To try to have à peak UV (try, because it seem that it don't peak it completely)

I export the model x1 with its uv.

I repair the 5 sides polygons in wings3d. The UV is the same, except that we have lost the coordinates of bias.

I use Troer to convert this new obj, Troer recreates the coordinates of the bias.

I import the models in AM16, and render :

A : the original model,

B : the model converted by Troer.

 

 

If you want to compare Uvs, here are the two mdl files and the map in this zip file

[zandoriastudios]

This whole issue came up once before--especially I remember Martin warning about peaking the control points and explaining why it would warp the decal:

 

http://www.hash.com/forums/index.php?s=&am...st&p=152725

[pixelplucker]

I would recommend not fiddling with cp's after decaling and creating new maps since you may distort the texture. If your decaling doesn't have extremely distorted patches, peaking a cp shouldn't have a huge effect. Obviously it depends on the texture whether or not it is noticeable.

 

In some ways using actions to flatten out faces have an advantage over LSCM where you can set a key frame and go back to it to tweak it. LSCM has to be done from scratch, pins re-assigned, seems re-picked then run the process again.

 

I had a couple of wishes, one being a patch selection brush or way of painting selections by dragging rather than clicking. Other wish was to show selected patches by highlighting them or changing their color. I think simple features like that would be more useful when decaling. I can't tell you how many times I had to go back and redo a section because I missed a patch.

[robcat2075]

On the question of whether the OBJ exporter understands the bias settings of the A:M splines when it subdivides them... It seems to be pretty darn close in its interpretation.

 

Here is an A:M spline model of a half torus with splines peaked, with bias at 167% and with bias at 300%. Below it is that model exported to OBJ at 64 subdivisions and then imported as a Prop:

 

 

Here they are dropped on top of each other. The spline model is red and the Prop is Green. The surfaces seem to be very close to each other but not identical...

 

[Fuchur]

On the question of whether the OBJ exporter understands the bias settings of the A:M splines when it subdivides them... It seems to be pretty darn close in its interpretation.

 

Here is an A:M spline model of a half torus with splines peaked, with bias at 167% and with bias at 300%. Below it is that model exported to OBJ at 64 subdivisions and then imported as a Prop:

 

 

Here they are dropped on top of each other. The spline model is red and the Prop is Green. The surfaces seem to be very close to each other but not identical...

 

 

Please do you try again with 256 subdivision level. Of course it will always be a approximation and will differ a bit from the original but it should get closer and closer and be unnoticeable at a high level and the distortion should get smaller and smoller. And since software like zbrush should handle millions of polys (at least the advertisings tell that) it should not be a problem.

 

See u

*Fuchur*

 

PS: Anyway if there is a bug with the obj exporter please tell steffen in mantis/a:m reports about it.

[thefreshestever]

On the question of whether the OBJ exporter understands the bias settings of the A:M splines when it subdivides them... It seems to be pretty darn close in its interpretation.

 

Here is an A:M spline model of a half torus with splines peaked, with bias at 167% and with bias at 300%. Below it is that model exported to OBJ at 64 subdivisions and then imported as a Prop:

 

 

Here they are dropped on top of each other. The spline model is red and the Prop is Green. The surfaces seem to be very close to each other but not identical...

 

 

nice... thanks for clarification!!!

[robcat2075]

Here's 4096 subdivs. It's probably very, very close. The overlaps only tell you if one surface is farther out than another, not how far. One micron would be all it takes.

 

 

[Fuchur]

Here's 4096 subdivs. It's probably very, very close. The overlaps only tell you if one surface is farther out than another, not how far. One micron would be all it takes.

 

 

 

Thanks for testing Robert.

For all who are wondering:

The first image is realtime the other is rendered. It is much closer and you can see that the exporter does handle bias-changes well. (Otherwise realtimeview would have the same problem and at least I have never noticed that. I would say, that it is really likely the same algorithm working for the exporter and the realtimeview, since in v18 you are able to set the realtimeview subdivision to 2048 too (which will kill your graphiccard for semi-complex models ))

 

The rendered one looks more offset, but I would say, that the renderer just has to decide which color he should show the closer together the surfaces are.

It is very likely that the differences are really small there, right Robert?