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.

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

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 :

An another way to do this. It is possible to create a cube subdivided into a polygonal program and convert it with "Troer." (More the object is dense more the conversion is long.) Download the MDLl

I got the V.17. So I pushed my analysis of polygons that are behind the patches using the new export plugins. By chance, I using Jpatch by curiosity, and found that Jpatch exported and converted patches triangular polygons differently to AM ... so I could compare and see some of the problems of the two methods. Here the analysis: AM exports in subdivision X1, X4, x16, x32, x64. with UVs Jpatch exports in subdivision X4, x16, x64 and x128. Without UVs Therefore not possible to compare the subdivision X1, x32 and X128 and Uvs. For AM : 1. All export models of AM have the same problems related to triangular patches: -An abnormal number of normals to the number of vertices. - Degenerated faces (see the alert window meshlab on the pictures). -Polygons with vertices whose normals seems reversed? - Asymmetric topology of the polygons of the model. 2. Export 32 and 64 has torn joints, not exploitable. For Jpatch. I have found two problems: 1. polygons triangular patches are not welded, making rendering the polygons visible. Some polygonal program can weld to import (eg, Poser, Metasequoia ...), and corrects this problem. 2.Triangular patches form corners where it should be smooth. Here's a little experiment to illustrate this problem: I create a sphere with three perfect circles and 8 triangular patches. Impossible to create a perfect sphere in AM with this method. as we see from this little image. the patches is unstable, just making a rotation of some millimeter, the patch changes shape. Export this sphere by the export of AM is identical to AM. Export this sphere by Jpatch is more spherical, but has a big problem, it gives the feeling of a square inside as the center point of the polygon patches. Red sphere is just to compare : not find the good solution

Hi rodney, No, if I use the v13, it's just that I have the CD version 13. I have not tried version 17. I expected a little more time to take out a subscription and be able to work seriously on a project and a way of working ... For now, I trying to use my knowledge of AM when I have a little time. To return to the topic, no there is no difference between the 13 and 17 models mdl that I could download (other new features) but their treatment in AM could be different. The rendering looks better in version 17, saw the pictures I've seen.

Ludo thank you for the test. This confirms what I thought. It is clear that 3Dcoat product very good map for AM. The problem is in AM. Once this problem set, AM will be very powerful.

Hi Ludo ... Can I ask you to do a test with this model, if it is not abused (thank you in advance). I have not 3Dcoat and would like to see if the result is better than the triangles that I have when I go through Sculptris and xNormal:

Hi Ludo! I do not know if it is the act of creating textures from perpixel option, but your model does not appear to have any trace meshes and triangular patches problem rendering. the bump's problem is solved through this way? Did you encounter any problems about triangles (diplacement)? Nice model.

Robcat thank you for the explanation.

Just for information, these problem is not specific to baking. My tests were only used as projection map in AM. I have not managed to reproduce the bug in version 8.5 When importing a model(v8.5) in V.13, the "bump" map is converted to "bump legacy". What is the differences between this two "bump"? the problem is also in the hooks.

Robcat, I modified the rapidity ... do not hesitate to say if it is too fast. Ludo, je ne sais pas à quoi c'est du. C'est une piste à creuser.

Hi everyone. By doing some testing I realized that the phenomenon seems to be found on other patches :

You're right Robcat is probably the better solution staying in AM.

Thank you for the answers. It seems that this function does not exist in AM. From what I understood from the video "Resurface" it does not work. Resurface plans CPs on a surface without putting them at equal distances. The only solution I've found is to export the model to Wings3D, which has this feature, and import it into the AM. Then change the bias. But it is not very practical solution :

Hello, There is there a plugin or a function that transforms a closed spline in a circle?

Hi Mouseman, Version 8.5 AM, had different rendering options, which allows you to see the triangulation of the patches :

Fuchur you understood what I wanted to show. Robcat, sorry, The Npatches are another problem that was far from my mind. I just add a CP to the triangle to keep the shape of thetriangle, and change the topology of the top of the triangle. Here is another example that avoids misunderstanding: and this is what I suppose might have happened if the topology of the triangular patches will be changed. Jake, I think it is possible to use the same principle to create Npatches ... but I don't know if these patches will be stable in animation and rendering.

To complete the problem of topology triangles, here is a simple experiment:

although I suspect this hasn't gone unnoticed. I think so. I guess also when creating the patch to 5 CPs the problem is posed. It was possible to integrate the quad in the 5-sided patches like this: But this is not what has been done, there are probably good reasons. Patient: Doctor, my arm hurts when i do this. Doctor: Don't do that!

Here are the files: model1 model2 model3 . The first one was done by hand, the other two are the first model modified by the code. Is that the final render is based on polygons? I don't know, it seems to be the case. Is this another topology for the triangle would be better, I think.

"The subdivision you see in real time is a convenient approximation only. That final renders do not use subdivision process... " I am surprised by this ... I can not find the differences in the following images (made in version 8.5): The shape of the splines and patches are identical in all three cases. The only difference is the topology of the polygonal subdivision to form the patch. The problems in the realtime rendering of polygonal topology that are the same in the final rendering. We guess even little polygons in the final rendering in critical areas.

Jake, you're not a troll! ... You express your opinion and that of many people. Each opinion is constructive even if it seems negative. It was during a review such as this one on the inability to properly import a polygonal model textured as a splines model in AM, "TROER" that is born, or the PHP script to convert into Ngones patches. I wanted to show there, it was possible to move on polygonal programmer to create programs that handles Ngones as patches. Of course I would prefer that this be included in AM directly ... But it is a lot of work for Steffen in a short time. Personally, if I had to choose priority in the AM programming, it would simplify the process of the creation of patches. And for the bridge betwenn the polygons, change the subdivision of the patches with 3 sides. But that's another debate Another idea that I come to mind when reading the article by Pixar: This can be positive for the props. And import a new function , in props, to give the possibility to import low-poly, that AM subdivide at various levels, depending on its size to screens, as it does for patches.

It is true that the user does not handle polygons. It is the interest of AM for the artist (say no to polygons). But they are there (in patches) to display on the screen in realtime. these are what we see when we interact with AM in directx or opengl. If this technology is best for calculating the display of these polygons, then it is beneficial for AM. This is to check, maybe opensub algorithms are slower than AM or even unusable. The programmers who will study the problem, will know.

Hi Ludo! Nice work!