A is the prop, it has a small sphere hidden inside it. B is the morph, the sphere has been expanded and looks smooth. C is the prop A, with the obj B applied to it as a morph target.

So why is the morphed prop displaying facets, and is there any way to fix it. I'm a bit limited for tools, just Poser and UV Mapper.

As a bit of extra background, the torus and sphere were made in UV Mapper, then imported into Poser, where the sphere was scaled down, and the two props exported as a single obj, but containing two separate groups. The same process was repeated, but with the sphere unscaled to produce the morph obj. I have since tried merging the groups in both the prop and the morph, but that does not seem to help. Any ideas?

Above is the prop obj...

... and the morph obj.

I should add that I'm using P6.

Here's what it all looks like to Blender, Les:

I moved the ring south of the morph, so the selected one is the ring. They look identical. What's the morph?

Set the crease angle to 30.

If that doesn't help then it's a morph weirdness/problem that is causing the hard edges. I would either have 2 prop files or have switching geometry for the morph.

ring-morph object imported is smooth for both ring and ball

ring obj with morph loaded as morph gives smooth ring, faceted ball at smoothing angles below 90. Changing smoothing angles to 140 made it smooth. At a smoothing angle of 100-110 the ball smoothed with some small defects visible.

The defects appear at morph values greater than 1 .

heres a pic , left is morph obj imported , and right is morphed ring.  smoothing angle 140.

done in Poser 7 sr2

@RobynsVeil,

Quote - They look identical. What's the morph?

They should look different. In poser the unmorphed "RingProp-R.obj" is a plain ring, as in "A" above. Are you sure you did not load two instances of the same obj file?

@DarkEdge,

Changing the crease angle did not fix it. Yes, I guess geom switching is an option, but I would really like to understand what is happening here. Interestingly, if I export and reimport the morphed obj, it is fixed and the sphere looks smooth again, but if I use that same "fixed" obj as a morph target the problem returns.

a ball the same number of polys as the morph appears smooth even with smoothing off.

There must be something in the smoothing algorithm that is getting confused by the morph. 

markschum takes the prize. Setting the crease angle to 140 solved the problem! I don't think I have ever used the crease angle before, and did not think to experiment with it. Thanks markschum.

You get a cookie if you can explain why that works . :)

I think the crease angle setting responds to the base shape of a geometry.  A morph which creates or removes harder edges will still show the same crease angle smoothing as the base shape.  Or that seems to be the case, based on what I've seen.

If I import your base prop and set the crease angle to 180, the morph is smooth, even at high settings.  If I load the morph as the base and then load the prop .obj as the morph, the result is smooth, even at higher settings.

I think Poser's just being weird about handling the normals for the ball portion of the original prop, with that part reduced to such a small size.  :unsure:

Thats what I saw, as the morph ball got bigger the smoothing angle had to increase to keep it smooth.

Ah! I think I see the light. markschum's explination sounds very credible.

Quote - Thats what I saw, as the morph ball got bigger the smoothing angle had to increase to keep it smooth.

Yeah, one of these days I'm going to read a whole thread before I post a response.  :lol:

Quote - @RobynsVeil,

Quote - They look identical. What's the morph?

They should look different. In poser the unmorphed "RingProp-R.obj" is a plain ring, as in "A" above. Are you sure you did not load two instances of the same obj file?

No, I didn't. In Blender they look identical. Different-sized files, but visually indistinguishable.

Quote - No, I didn't. In Blender they look identical. Different-sized files, but visually indistinguishable.

That's very strange! I wonder why Blender would display the ball at the wrong size? it's especially strange as the "wrong size" seems to be about the same size as the ball in the morphed obj. Morphic fields?

Quote - Morphic fields?

I'm picturing 100 monkeys rewriting Blender.... 

Quote - You get a cookie if you can explain why that works . :)

When I first read it, it  sounded good, but thinking about it, all the angles in the ball have to remain the same no matter what the scal is. :blink: So no, I can't explain it. Is it something to do with voodoo?

I tried it again, Les. Different results this time. in the "morph" file, the ball appears to not be there. No idea what I did wrong the first time. But I'm sure I didn't just load it twice - I remember thinking: this one's 141kb, that one's 131kb. Wonder why the difference? the morph files are usually identical in size, right?

they should have identical number of vertices but the actual file size will depend on the number representation for the vertices. 

I am thinking more the angle between the ring , and the ball polygons is changing. If Poser is trying to smooth across the entire mesh , and not doing them seperately you might get that result, at least for some of it.  ???

Quote - I remember thinking: this one's 141kb, that one's 131kb. Wonder why the difference? the morph files are usually identical in size, right?

I had a look in the obj files. I think one reason for the diffrence in file size is that many of the "vn" (vertex normal) lines in the prop obj are at a zero value, but in the morph obj the vn values are mostly 6 or 7 digets for each number. I'm assuming that the zero values are for the ball part of the geometry, and that perhaps Poser drops the vn values when a facet is below a certain size. That raises the interesting question "if I replace the vn values, will that smooth the ball?".

I thought poser used the vertex winding order to do normals ?

Worth a look though.

And the answer to that question about replacing the normals is NO, it did not make any diffrence.

Quote - I thought poser used the vertex winding order to do normals ?

Worth a look though.

Yes I have always been told that Poser ignores normals in an obj file. It's just that I have heard so much BS in my life, that I never quite believe anything untill I see it with my own eyes.

Open your OBJ file in a text editor and take a look at the normals data. Search for "vn". You'll see that what I assume to be the torus has its normals correctly calculated whereas the sphere has :-

vn 0 0 0

for everything.

Suggest that you delete all of the VN lines and allow Poser to rebuild them again from scratch. Or take the OBJ into UVMapper and use its smooth tool. (not the subdivide tool).

Another way to get this effect is by using smoothing groups. Earlier versions of Poser ignored them but later editions do recognize the option. In this instance smoothing groups are not the issue.

Hope that helps.

Wouldn't the answer be to make the normal form of the prop, the one with the ball expanded, and then use the morph to hide it ?

:blink: Now I'm even more confused than normal (no pun intended). markschum is suggesting that the normals in the prop don't do anything in Poser, which is what I have heard many people say, and yet PhilC, a very  knowledgeable person, is suggesting I do things with the normals!

So which is it? Does Poser ignore the vn lines, or not?

Phil, "Or take the OBJ into UVMapper and use its smooth tool." by "smooth tool", do you mean the "Fix Seams" option? If so I tried that, it did not help. What does "Fix Seams" actually do anyway? Markschum's suggestion of setting the crease angle above 90° worked, I'm happy enough with that solution.

Nruddock's suggestion sounds like it must work, but as there are quite a few other morphs for the prop, it would involve redoing those other morphs.

Some progress maybe.

I imported the morph object and applied the base obj to it as a morph. Apply the morph and the ball goes away. The ball appears smooth without changing the crease angle.

This suggests that something in the scale of the base object is having an impact.

I exported the obj with a morph setting of 0.6 (ball just gone)  for the original that would be 0.4. 

Using that obj as the base and applying the morph it all worked with normal smoothing.

Since the only difference is the scale of the ball in the base object that is where to look. 

You should probably do this yourself to verify it.

I have found that "what everyone believes" is not correct, or not correct in other versions of Poser. I havent seen a case where normals were a problem , except for some modelling errors.  It should be easy to test with say a 3 x 3 poly plane with one normal reversed at its vn line. 

Thanks markschum. I was suspecting the very small scale of the ball in the base prop might have caused the problem.

Now this is really strange. If I spawn props from the base obj in the Grouping tool, the sphere does not come out as a sphere. It seems to loose a lot of its facets, see image above, in Smooth Lined Style.

Even stranger. If I export the obj from my last post, the header info in the obj is exactly the same as the original sphere it was made from (before the base prop was constructed). So all the parts seem to be there, they are just not displaying correctly in Poser!

#  InternalName: Sphere
#  ExternalName: Sphere
#  Num verts:  482
#  Num sets:   1984
#  Num elems:  512
#  Num tverts: 559
#  Num tsets:  1984
#  Num tElems: 512

[edit]

I have nemed the spawned sphere "Strange.obj". If I apply the original sphere to Strange.obj as a morph, it turnes back into a sphere, so all the parts are definatly there, even though it does not look like it.

When I opened the original in Blender and focused in on the sphere I got the same odd cube.  Grabbing and moving some of the vertices showed that the faces are still there they are just folded over onto each other.  Whatever progam you use to scale the sphere instead seemed to collapse it.  I believe Cage is right about Poser using the original shape to determine the smooth angles, as the faces are 90 degrees or sharper they appear faceted when it is morped back to a sphere.

@Les: How did you reduce the sphere?  It seems like parts of the geometry have collapsed or something.  But all of the vertices are still there, and the polygon linkages are correct.  (Edit: jestmart just said that.  D'Oh. )

That compressed form of the sphere portion of the base prop would explain the pattern of hard edges I was seeing when I tried your objects.  So at least there are indications that Poser's behavior is sane and consistent.  :laugh:

Hi jestmart,

The scaling was done in Poser 6. Yes, the cubic shape of the shrunken sphere seems to explain why the crease angle needs needs to be greater than 90 for smoothing to happen. Markschum has provided a solution, but it is still interesting to investigate the mechanics of this problem.

I suppose there must be a lower limit to the size of the increment Poser can use to shift a vertex, and perhaps bumping up against that limit is causing the sphere to fold into a cube.

cage,

As far as I remember, I think I had the sphere starting at the size as in the morph, then set the scale dial to the minimum (0.1 I think), I suspect that I also set the individual x y z scales to the minimum as well, but can't really remember.

Quote - cage,

As far as I remember, I think I had the sphere starting at the size as in the morph, then set the scale dial to the minimum (0.1 I think), I suspect that I also set the individual x y z scales to the minimum as well, but can't really remember.

How many digits are the vertex position entries in your .obj file?  You may have placed the vertices so close together that they became sensitive to float sensitivity errors when they were exported to .obj.  I don't recall whether the .obj format will use scientific notation beyond a certain point.  :unsure:  You may have discovered what actually is too small for Poser. 

Also: about Poser handling the vn lines.  In Poser 6, it didn't.  As Phil points out, this was changed (in Poser 7?).  More recent versions of Poser will handle the smoothing groups in a .obj file, allowing one, for instance, to assign hard edges in Wings and now have them come into Poser looking as you'd intended.  Which is kind of nice, IMO.  :laugh:

cage,

There seem to be eight digits in most v lines (7 after the decimal point), though some have less. I think trailing zeros are dropped, which could account for the shorter lines.

Hmm.  It really looks like rounding errors, to me.  The vertices have all collapsed into the nearest grid locations, creating a cube.  If that is correct, the differences in the vertex positions were smaller than the eight digit limit in the .obj.  One could probably test this by exporting a sphere at smaller and smaller scales until defects begin to show up.

If that's correct, it isn't really a problem with Poser itself.  Possibly you'd get better results if you shrank the sphere portion in a modeler or other application which might handle .obj exports with greater sensitivity.

If I were making the prop, I think I'd use the full-sized sphere version as the base and the reduced version as the morph, although that would reverse the morph settings to switch states.

I did another experiment. I took a poser ball prop snd saled it down to 0.1%, exported and reimported. Then repeated the procedure so it was scaled down to a further 0.1%. Then I scaled the resulting prop up by 100,000,000.0%. I was expecting to see another cube, but I got a cylinder!!! :scared:

In the above image the cylinder is shown next to the unscaled ball prop.

Cough, cough, splutter.... "sane and consistent"... Poser...splitter...! :laugh::lol::lol::lol:

Quote - Cough, cough, splutter.... "sane and consistent"... Poser...splitter...!

Did you use the same scaling process which produced the cube?  Here, it looks like it basically clamped the Y coordinates, with any rounding error.  That makes me wonder how Poser is internally representing the scaling changes to the vertex positions.    Favoring Y like this is... unexpected.

Dangit, computers are s'posed to behave consistently.  :scared:

Edit:  What happens if you reduce the size using a magnet, rather than the scale dials?  (I'll just hide back here, in the bunker....)

Poser normally ignores existing normals but in this instance it appears that there is an abnormality them. Normal procedure would be to do nothing but in this abnormal situation I made my suggestions as above.

I hope that I was correct, if not then normal service will be resumed as soon as possible.

:)

Cage,

The cube was out of the RingProp. I can't remember the details of the scaling, except that it used poser scale dials, and should have been symmetrical.

The sphere topology that produced the cube was similar to the Poser ball but more dense and orientated on the Y rather than X axis.

Phil,

Normally I would agree with you, but as my normals are acting abnormally, normal procedures do not apply as they normally would to normals that are normally abnormal as these normals are abnormally not normal normals!

@Les
You'll get the same affect in any modelling program when scaling down.
Once vertices end up in the same place, you'll never be able to move them apart by scaling up if you've frozen the transform between the two operations.

from the original obj file

v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459
v -0.0373557 0.516893 0.0371459

the sphere has been squished to a point or very close to a point. I doubt the calculations for normals or crease angles would get a useable result. It might be interesting to see what the smallest smooth sphere is .

Quote - > Quote - So at least there are indications that Poser's behavior is sane and consistent.

I did another experiment. I took a poser ball prop snd saled it down to 0.1%, exported and reimported. Then repeated the procedure so it was scaled down to a further 0.1%. Then I scaled the resulting prop up by 100,000,000.0%. I was expecting to see another cube, but I got a cylinder!!! :scared:

In the above image the cylinder is shown next to the unscaled ball prop.

Cough, cough, splutter.... "sane and consistent"... Poser...splitter...! :laugh::lol::lol::lol:

This looks to me like a typical effect of floating point cancellation. Without going into details, poser probably uses floating point numbers to represent vertex positions which essentially means, you measure your precision of coordinates in relations to the size of those coordinates. I.e. you may be able to build an molecule model using a prop, but then, this prop has to stay at the coordinate origin its whole life, or it will get destroyed. In the case of your ring for example, the embedded mini-ball is in relation to it's size very far away from the origin, so the absolute error is very large.

An easy way to try this out in poser is this:

1 - load a ball prop

2 - use your dolly camera to point at the ball prop

3 - move the  ball 1000000 (1 mio) units to the right (x-position)

4 - move the dolly camera 1 mio units to the right. You can see your ball, but likely it does not look like the ball anymore. Practically the same effect happens when you use very small values (like a thing scaled by 1/1000000) at absolute position 1.

This is the inherent error when using floating point values. Another error comes additionally into play when exporting and importing  via obj-files. Poser seems to only write a fixed number of significant digits when exporting the numbers in obj files, for example it seems to only write 5 digits when writing very small values (like 1.12345e-08), so when exporting/importing you lose additional precision. It usually does not get better when you combine these two sources of errors though.

Thanks for the explanation millighost.

Quote - 4 - move the dolly camera 1 mio units to the right. You can see your ball, but likely it does not look like the ball anymore. Practically the same effect happens when you use very small values (like a thing scaled by 1/1000000) at absolute position 1.

Wow!  The result does look an awful lot like what is shown above, but flattened on X, not Y.

And Poser really, really doesn't like trying to render anything at 1,000,000.0 units to the right of 0.0.  :scared:  It just eats all the RAM and crashes.

Ah, millighost saved me from typing all that. I saw this last night and was going to answer the same. Thanks MG.

I would only add, in case it isn't obvious yet, that the original ball was odd in the Y direction because it was above the ground. Had it been centered on the world origin, there would have been no oddity in any dimension.

I like experiment!

Les, which version of Blender are you using?  Recently, I submitted a bug regarding the obj import.  They fixed it very quickly, the fixes are in 2.57b.  I'm still exploring features of the 2.5x.  I still kept 2.49b around.

About the size, I think it is better to scale up the OBJ before you import it into Blender.  Blender is not that accurate in small scale;  0.001 and 0.000975 look the same. 

Good point, Amy. And scaling up before-hand sounds like a good idea.

You do have access to Blender-Cookie, don't you, Amy? Brilliant stuff - the new Blender's capabilities are so well explained, and sheesh!!, there are a lot of them! I'm so impressed, i sent a donation to the foundation.

Actually Blender 2.57 is capable of using scientific notation for a verts coordinates.  Create a standard UV Sphere, scale it by 0.00001 and you see it changes that to 1.0000e-005.  It can then be scaled back up.

Edited to add:

Although it will still only show the first three decimal places in the coordinates window, this probably can be changed I just have really looked yet.