Yours, TheOwl, is broken at both ends. I loaded it into Poser and immediately saw the artifacts (two of them).

I imported it into Blender and re-exported and then loaded into Poser, and the artifacts are gone. Blender fixed something. I know that Blender pays zero attention to normals on import (it says so in the export dialog, to tell you not to bother exporting them). But I exported them anyway, just to be sure. So unless the coordinates were modified, it has something to do with normals.

It will take a while to sort out what changed during the pass through Blender import/export.

But even if I find it, what will you do about it? You're not doing anything strange, right? It's just a cylinder.

Maybe this is a bug in Maya.  LOL

Render shows your original and also my transformed version of it, via Blender.

I'm going to bed now.

Using displacement maps is another kettle of fish altogether. There are times when you need to unweld points, such as on a length of pipe that has flanges and bevels all along it, otherwise you don't get the sharp creases where you need them.

Quote - Sue88 in the Maya forum also advised me to bevel the end loop and It somehow solved it. My brain couldn't process all of the data you guys have presented but I do I agree that this should somehow be reported to SM.

Its just a simple cylinder. Poser should have imported this with no problem at all.

That cylinder is not broken. This image shows the unmodified cylinder on the left and my modified version on the right. All I did was cut the top and bottom polygons and paste them back into place. Because the vertices are now unwelded, it renders fine.

Attached Link: Spanki's STOMP

Then again..........exporting a cylinder from LightWave straight into Poser showed no problems at all, so perhaps something in Maya's object export routine is somewhat askew.

I cut the bottom and up faces and combined them again as you commanded Lord Rubicon.

It did render fine. I think I can settle with this workaround for now.

So I have to learn to live knowing my life is dominated by a.... (see above image).

Sigh. It seems nobody is going to look into the normals. I guess I'll have to do it myself.

My hypothesis is that Maya is exporting something with bad normals. The bug is in Maya, if there is a bug.

When you do that end-cap cut and paste, it isn't just that you're unwelding, you're also changing the normals.

The MayaCylinder that TheOwl posted has "vn" vertex normals in it. I don't have time to study them right now, but my guess is that one of them has a magnitude that isn't 1.0 or has a direction that is wrong.

The arrangement of polygon faces and welds doesn't seem to have anything to do with it. When I load and save from Blender (removing normals) the SAME topology is there. It renders fine.

Also, please do not load the OBJ into a 3D app and have the app display the normals. That proves nothing.

Blender IGNORES the normals in the OBJ file. Poser does not. That is a feature that cannot be turned on or off in either application. (I think)

Poser's support for vertex normals is not a bug. But other apps do not support vertex normals and will not show them to you. If you load into another modeling tool and visualize the normals, you may be/probably are looking at normals generated by your modeling tool, not what is in the actual OBJ file.

We need to look at the actual data in the OBJ file, as it is. We need to calculate the magnitude of all VN lines. Should be 1.0. We need to calculate the direction of all VN lines. Should be consistent.

Quote - Sigh. It seems nobody is going to look into the normals. I guess I'll have to do it myself.

My hypothesis is that Maya is exporting something with bad normals. The bug is in Maya, if there is a bug.

When you do that end-cap cut and paste, it isn't just that you're unwelding, you're also changing the normals.

The MayaCylinder that TheOwl posted has "vn" vertex normals in it. I don't have time to study them right now, but my guess is that one of them has a magnitude that isn't 1.0 or has a direction that is wrong.

The arrangement of polygon faces and welds doesn't seem to have anything to do with it. When I load and save from Blender (removing normals) the SAME topology is there. It renders fine.

er, Spanki's STOMP???
ok I just used the reorder faces to strip the normals information from the obj which fixes it. I did actually Confirm it for you.

you do know what Stomp does right? how it will sort the faces in the OBJ file, and put them in to order within the file (not the mesh) right? basically rewriting the OBJ from the ground up?

Also Magnus believes he exported without normals and still saw the artifact. But if there is a bug in the application regarding the exporting of normals, then how do you know the option to leave them out of the export even works? 

Magnus didn't post his OBJ, so I can't check it. So far, all evidence is consistent with bad normals. Nobody has done a single demonstration that disproves that hypothesis.

The only way to debug something is to be scientific, not emotional. Develop several hypotheses. Develop tests that can discriminate among the hypotheses. If you have a test that is actually does not eliminate a hypothesis, then it is a useless test. That would be the cut and paste one. It proves nothing, since you changed two things - topology and normals.

but spanki's stomp fixed the problem....try it!
it's afree download... oh ye gods I can see why magnus got annoyed.

look. I took the posted bad OBJ. ran it through STOMP with remove normals and sort faces by material checked and then loaded that cylinder into poser.

the markings were gone.

so :  it fixed it.

Khai, I understand Stomp. It has removed the normals.

The problem we have is there are people who think the bug is in how Poser READS the normals. What if the bug is in how Maya WRITES the normals?

How would you determine where to send the bug report, using Stomp?

I'm trying to answer the question, Poser bug or Maya bug?

from what I'm seeing we send ones to Smith Micro, Autodesk, Daz and Caligari.. maya's shown the bug as has hexagon and caligari.... strange thing is, poser shows it when other apps don't. I'd say get 'em all to take a look personally.

tho the thing that has me confused is...

trueSpace didn't used to do this.
I could export a mesh out of tS using the standard LUUV.tsx and bring it into poser and not see this error.
but, in the last coupla months..bam it's there. (it's why I'm trying to help with the thread and to understand whats going on)

the only things that have changed on the PC is drivers and installing poser pro base. so I'm a little puzzled why trueSpace 4.3 (10 year old stable unchanged code) and LUUV (not been changed for a coupla years now) would suddenly start doing this.

It may have something to do with smoothing groups - I ran into a similar problem, although my problem only showed up after turning the object into a figure.
Exporting without smoothing groups fixed it.
I'm not sure whether the problem is related to the 3DS Max OBJ exporter or to the Poser .OBJ importer. I inspected the .OBJ that came out of Max, and it looked fine.

Since Wavefront OBJ is kind of an orphaned file specification, it doesn't matter much if the "bug" is in Maya or in Poser, neither company is very likely to "fix" it.  I'm using quotes here because it's likely a difference in implementation, more than an actual bug.

This is a very funny argument over a primative

The cut and paste solution is not useless. It fixes the problem and allows one to move on to other things. Khai's solution worked for him too. Fixes like these have been applied to models destined for Poser for years. Part of finishing a modelling project is knowing the software you use and working accordingly. I'd rather get things done than dissect objects down to the atomic level.

You're right, unwelded geometry is a common practice, e.g. all of Stonemason's excellent architectural models are done this way.  It's not ideal for everything but it's a good compromise when you don't need to use Smooth Polygons or other features typically not required for inorganic stuff.

Can we get the original object so we can see what was going on?  Please?

I've seen this problem several times in Poser when you have an object with a lot of tris lined up.  Booleans often end up putting such things in the mesh and Poser hates them.  So, in some freebies I worked on I had to work around this exact same problem of strange artifact shadows caused by boolean-generated mesh.  I ended up ripping out the booleans and using another technique that resulted in a perfectly clean mesh.  BUT, I sure would have liked to have seen what was causing the problem and how to fix it without having to split verts, if at all possible.

Somewhat O.T. Note: I played around with bagginsbill's cylinder and found some interesting stuff.  I had a scaling problem exporting from an application once and decided to mess around with it while I had a cylinder guarranteed not to be generated in the suspect application.  It's slightly offtopic but, someone may get a kick out of it.

Load up the cylinder (P7 here) and use the default lighting.  Now, shrink the cylinder down to 1% scale and render.  To me, it's completely black and the shadows are all wonky.  However, the shadows work appropriately if you switch from depth-mapped to raytraced.  But, the cylinder is still black.

So,  I fiddled with the standard lights, just mucking around with the general settings and had no results - the cylinder was still black.   But, if I changed the default infinite lights from infinite to spotlight, walla! there's the cylinder's surface.

Here's the first series showing the scales and rendering options:

But, with my own default lights I prefer to work with for quick, preview renders:

So, infinite lights and depthmapped shadows don't like bagginsbill's cylinder shrunked down to 1%.  But, spotlights do. :) Turning off the IBL has no effect btw, the shadows/lighting weirdness will still be there for the infinite light.  I cranked up the shadows on the infinite to see what would happen but, there is a definite artifact still there if you don't.  Here, the shadow starts "inside" the cylinder at the above infinite light settings.

Weird.  Maybe some Node-Wizard, intimate with the ways of lighting and rendering can explain this one?

Quote - The cut and paste solution is not useless. It fixes the problem and allows one to move on to other things. Khai's solution worked for him too. Fixes like these have been applied to models destined for Poser for years. Part of finishing a modelling project is knowing the software you use and working accordingly. I'd rather get things done than dissect objects down to the atomic level.

I did not say it was useless to cut and paste as a way to make the artifact go away. I said it is useless to claim the cut and paste is a differentiator, or proof or evidence, between two hypotheses being examined - topology versus normals (it changes both), or Maya bug versus Poser bug

Nobody said you had to dissect things. But what you're doing is called "hackery" in computer software. "I changed the 2 to a 5, and it doesn't crash anymore. I don't know why that works."

Software developers get fired for that kind of shit. If you want to hack your way past the problem and move on, that' fine.

I'm responding to the statements that Poser has a bug and a bug report should be filed.

If you don't want to find out what the problem is, and where it lies, you are free to remain unclear on what works and what doesn't and whose fault that is.  :) But you should stop reading this thread, because eventually I will reveal the underlying problem.

Quote -
Somewhat O.T. Note: I played around with bagginsbill's cylinder and found some interesting stuff.  I had a scaling problem exporting from an application once and decided to mess around with it while I had a cylinder guarranteed not to be generated in the suspect application.  It's slightly offtopic but, someone may get a kick out of it.

Load up the cylinder (P7 here) and use the default lighting.  Now, shrink the cylinder down to 1% scale and render.  To me, it's completely black and the shadows are all wonky.  However, the shadows work appropriately if you switch from depth-mapped to raytraced.  But, the cylinder is still black.
...
Weird.  Maybe some Node-Wizard, intimate with the ways of lighting and rendering can explain this one?

It's a bug pure and simple and has nothing to do with geometry or normals. We could start another thread about it. It is unrelated to this issue.

The bug is triggered when the total volume of space occupied by all shadow casters is below a certain amount. In other words, if you put another tiny object in, but it's at least a couple feet from the first one, all is fine again.

Unless you're doing a "macro" shot of a single tiny pebble, or jewelry, this simply doesn't come up, so nobody has bothered investigating it further. If you're trying to render something tiny by itself, just scale it up.

Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2761662

How did you determine that?

I didn't change the UVs and it rendered correctly. All I changed was to remove the normals.

Quote - Software developers get fired for that kind of shit. If you want to hack your way past the problem and move on, that' fine.

Not neccessarily ... it depends on the company and/or the expenses ... last one's in terms of money only are making the difference between been fired (rarely) or been honored (often).

Been fired for that shit would mean that more than 50 % (even more) of IT people would be unemployed. Finding quick and workable (even if dirty) solutions is the job for complete departments in the big software companies.

That, maybe, is not the best and/or ideal way but is the way this world is working ... sadly sometimes ... but it is.

Quote - How did you determine that?

I didn't change the UVs and it rendered correctly. All I changed was to remove the normals.

Created a cylinder in UVM (the mapping is the same as the one from Maya) exported with no normals, loaded into Poser, and the anomoly shows up.

Of course there may be several different anomolies that look similar but with different causes.

Quote - > Quote - Software developers get fired for that kind of shit. If you want to hack your way past the problem and move on, that' fine.

Not neccessarily ... it depends on the company and/or the expenses ... last one's in terms of money only are making the difference between been fired (rarely) or been honored (often).

Been fired for that shit would mean that more than 50 % (even more) of IT people would be unemployed. Finding quick and workable (even if dirty) solutions is the job for complete departments in the big software companies.

That, maybe, is not the best and/or ideal way but is the way this world is working ... sadly sometimes ... but it is.

Oh my God, is this forum full of nitpickers.

OK, let me restate my position, as it was not clear:

When something doesn't work, and there is an expectation that failure to understand why will lead to the problem appearing again in the future, the workaround is laziness, not enlightenment.

I, as a manager of software developers who don't write crap, fire people for that.

Laziness. Failure to grasp the significance of small problems in a larger context. Sure a primitive cylinder can be fixed by doing a simple cut and paste, or a micro bevel.

But when you're making some giant 50,000 poly model, and a team of people has developed it for months, and it doesn't render correctly in Poser, and it turns out that all the modelers made the same mistake as was hidden in the simple cylinder problem, and it turned out that something could have been done before the outset if only somebody had figured out what the underlying cause was instead of sweeping it under the rug, and now the whole team has to redo months of work, yes I fire people under these conditions.

Not everybody gets fired for finding a workaround. The ones who figure out the underlying cause, can identify for me when and why this will not impact the project as a whole, and then proceeds with a shortcut or workaround, they do not get fired.

As for what 50% of the IT people in this country do, they create work for me. I get paid a lot to clean up their messes, as a specialist.

Quote - > Quote - How did you determine that?

I didn't change the UVs and it rendered correctly. All I changed was to remove the normals.

Created a cylinder in UVM (the mapping is the same as the one from Maya) exported with no normals, loaded into Poser, and the anomoly shows up.

Of course there may be several different anomolies that look similar but with different causes.

Can you share this cylinder OBJ?

So far I only have one datapoint for this artifact.

Quote - I did not say it was useless to cut and paste as a way to make the artifact go away. I said it is useless to claim the cut and paste is a differentiator, or proof or evidence, between two hypotheses being examined - topology versus normals (it changes both), or Maya bug versus Poser bug

Nobody said you had to dissect things. But what you're doing is called "hackery" in computer software. "I changed the 2 to a 5, and it doesn't crash anymore. I don't know why that works."

Software developers get fired for that kind of shit. If you want to hack your way past the problem and move on, that' fine.

I'm responding to the statements that Poser has a bug and a bug report should be filed.

If you don't want to find out what the problem is, and where it lies, you are free to remain unclear on what works and what doesn't and whose fault that is.  :) But you should stop reading this thread, because eventually I will reveal the underlying problem.

I never claimed that the cut and paste method was a way to test a hypothesis, only that
it was a solution to a problem, so don't put words in my mouth. This so called "hackery" is something that is required to obtain properly rendered objects, under certain specific conditions, due to the nature of  Poser's render engine. You seem intent on tearing down anything I say in this forum, simply because I disagree with you. You just can't stand anyone having an opposing view to yours, can you? You know, you're not the absolute font of knowledge on 3D, you're just not. I wonder how much 3D modelling you've actually done. Bugger all, I suspect.

I don't need a lecture from you on computing or anything else, thanks very much.
I've been creating models that render perfectly in Poser for years, without a single complaint. I already know what works and what doesn't, but if you want to dick around for a week with a cylinder, then go right ahead. I'm way beyond the point of caring. The atmosphere in here has become toxic. It's no wonder people get the shits and leave. I have better things to do than to waste any more time here. It's just not worth it.

Quote - It is unrelated to this issue.

As I indicated in my post.

Quote - Unless you're doing a "macro" shot of a single tiny pebble, or jewelry, this simply doesn't come up, so nobody has bothered investigating it further. If you're trying to render something tiny by itself, just scale it up.

It was just an anomaly I happened to have not seen before.  Thank you for answering the question.

You're gaslighting me now, right?

First, just calm down. I was only interested in helping somebody figure out how to avoid this problem in the future. If you think it's a waste of time to understand something, you should just move on. Nobody is making you stay in this thread. Your ego is doing it. If you think I was needling you, you're wrong. If I wanted to piss you off, you'd be seriously pissed off. Like, you'd be pounding your keyboard and writing many PM's to Rendo admins demanding that I be banned. Actually, that may happen anyway by the time you finish reading this, but that's your keyboard there, Sparky, so take it easy.

(I threw that little made-up name, Sparky, in there to demean you, kind of like when you referred to us in the White Balance thread as "kids". I know you're not big on "semantics", so I thought I'd clear that up.)

You just can't stand anyone having an opposing view to yours, can you?

Actually, there've been hundreds of threads demonstrating otherwise. I certainly tolerate opposing viewpoints. But just to clarify, it is not enough for you to disagree with me to get me to give you a rebuke. You have to actually be an ass about it. You don't seem to be aware of that - how you come off in your posts. I noticed in the other thread, as soon as just one other person besides me hit you back a little, you didn't answer.

You know, you're not the absolute font of knowledge on 3D, you're just not.

OK, although I have to observe that you couldn't possibly have believed that's what I thought, right? I mean, you're not saying that to actually convey information to me. Which means that you're saying it for some other reason. A goad perhaps. I'm not sure. In any case, don't say stupid stuff like that again, or other people will start attacking you.

Oh, perhaps you're making a veiled reference to this thread?

http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2716053

Just so you know, demi-god is not the same as absolute font of knowledge. Quite different, really. Nobody, including me, ever thought I was the latter.

*You seem intent on tearing down anything I say in this forum, simply because I disagree with you.

Let me state for the record I am not intent on tearing down just anything you say. Only particular things you say. I am intent on tearing down any illogical statements that confuse people or impair one's ability to solve a problem or use the tools they have effectively. I do that ruthlessly,  and I do it to everybody, not just you. How many times has somebody said in these forums "neutral gray causes no bump or displacement" and I have to say no, that's incorrect. That's true of other applications but not of Poser. In Poser you must subtract .5 from the map if you want it to behave that way. Let me point you to all the other threads that show you that.

When I do that, I am helping them, not abusing them. Most people get over the mild sting of the rebuke and think twice about answering questions with statements for which they have no proof, evidence, or experience. Most people notice that I give my time and an uncommonly high amount of free, hard-to-find information and high-quality content. Most people actually enjoy learning, including tearing down pre-conceived notions that were incorrect and holding them back.

I respond with a rebuke, because I'm trying to help somebody work through a problem and somebody coming into it with illogical statements is actually worse than a troll. Now if you happen to be the person who consistently makes illogical statements, then you will be a person who consistently gets an argument from me. That isn't personal. How could it be? You're nothing more than a name on a screen to me as well as the sum total of what you say here. I'm not singling you out. You're singling yourself out by being a bit of an ass about things, rather consistently. LIke right now. Your last post is really quite provocative. So were several of the posts you made in the White Balance thread. Over there I let you go when you dropped this bomb:

*You can keep having the argument, semantic or otherwise, as long as you want, but I've spent too much time with this already, so will bid this place good-bye and go and enjoy my long weekend in the perfectly rendered real world.

Now we get this:

*I have better things to do than to waste any more time here. It's just not worth it.

I let you have the last word there in the other thread. Not this time. Let me make this perfectly clear. You've brought this issue up twice, so let's get it over and done with. If you spend time in a forum, actually writing that it wastes your time, you've demonstrated that your time is worthless. Somebody who actually has something significantly more important to do, actually does that other more important thing. He does not stay here and write that he has something really important to do and should be off doing it. For you to say, in this forum, that speaking in this forum is a waste of your time, is so incredibly, deliciously illogical and revealing, it makes me smile. It is probably the most absurd thing you've ever said. Reading you say it is like watching The Office. I enjoy it a lot. Do it again. (Oops, I just needled you a little bit. Sorry)

Moving right along...

So my issue with you actually is about wasting time. You waste my time. I'd venture to say my time is worth more than yours (even if you hadn't proven that your time is worthless) so when you waste mine I get a little bit annoyed.

If you came in and typed "Baggins is a douchebag and doesn't know anything", well nobody would think that should influence the problem solving process and we'd not waste a lot of time. But if you come in and say "I made two changes and the problem is gone, so the first change fixed it" (not in so many words, but that's basically what you said) well now you've created a real problem. If you come in and repeat it, or argue about it, well then you are really interfering with the problem solving process and I get annoyed and I let you know. I'd rather have you spew nonsense than do something like that. There are plenty of people who have trouble following a cleanly presented argument, let alone without having the issues further hidden from them.

Want to know what my issue is? I think you should, since you've come back at me demanding that I not put words in your mouth.

*I never claimed that the cut and paste method was a way to test a hypothesis, only that
it was a solution to a problem, so don't put words in my mouth

Actually you did claim that, precisely. I didn't put any words in your mouth. Here's what you said:

 *All I did was cut the top and bottom polygons and paste them back into place. Because the vertices are now unwelded, it renders fine.

*That's where you made a mistake in deductive reasoning. You made two changes, but attributed the outcome to a particular one - "because the vertices are now unwelded it renders fine." You are asking the reader to believe that you know WHY the artifact is there.  

It was after you said that, I pointed out that you have no evidence to prove that the unwelding is what fixed the artifact because that isn't the only thing you did. You also changed the normals. That was when I explained that your test neither proved nor disproved any possible underlying causes or hypotheses. You simply made the problem go away, and I agreed that you made the problem go away. But you claimed that having done so, YOU PROVED WHAT THE PROBLEM WAS.

That's where you f'ed up badly and why I tried to explain that you have to investigate the causes and find a differentiated test that answers to or agrees with A or B, but not BOTH.

My contention is that you mistakenly believed you knew the cause of the change, and you did not investigate it. I think you do need a lecture on problem isolation and debugging, only because you came into this thread throwing elbows like you own the court. If you'd never stated anything illogical, then i wouldn't be questioning your logic. If you came back after the first rather mild rebuke with greater understanding and a bit of hesitation to make unprovable assertions, we'd get along fine.

Instead, you've come back with challenges. You throw down statements provocatively, daring me to refute them. When I do, you protest that I'm not the God of CG, that you probably know more than I do, and that you dont' have time to waste here in the forum.

The atmosphere here is not toxic, but you have clearly lost your temper and need to get it under control. If you think you have "better things to do" and this is wasting your time, then really, please, just go.

I'm not going to tolerate any bullshit, or illogic, so if you stay, you'll have to put up with being called on it when you make a mistake. 

None of this is an indictment against your modeling skills. Please don't bother defending those. I concede (for what reason, I'm not sure) that I've done "Bugger all" much 3D modeling. You're the king of the models here.

But you still don't know WHY this artifact is happening. You only know how to hack around it. I understand you don't care why. Great. Shut up then. I acknowledge that you invented several ways to change the normals, which seems to fix the problem. How's that? 

I, on the other hand, want to know why and there might be one or two more people who will find it valuable to know why. I always want to know why and how something fails before I commit to a workaround, particularly one that limits my options or increases my work. This is a key part of my philosophy in building complex systems; "Know your tools, inside and out". Another one is "If your tool offends you, cut it out of the system". It is this (along with a few other key things, #1 being "Anticipate Change") that differentiate me (and my income) from the vast majority of software developers. You have no right to disparage my interest in this phenomenon as dicking around for a week with a cylinder. My interest in knowing why it fails is perhaps a waste of MY time, not yours. You are free to leave immediately and never reply here again.

I bet you won't, though. Your ego won't let you. Twice now when you should have left, you came back to tell us you were wasting your time and now you're going to leave. Actually, now that I think about it, you've totally screwed yourself. If you don't answer me now, then you leave me the last word. If I've got you figured out right, that will just eat you up. And if you do answer now, then you embar-ass yourself again since you twice made the bold claim you can't afford to waste time dicking around this forum. LOL. You are so screwed. No, wait, I change my bet. I bet you come back. You like to do things over and over.

I think it's great you've created models that render perfectly in Poser for years. Keep doing it. And feel free to offer workarounds, as well. Just don't make the simultaneous claim you know why they work, the way you did above. Do not start telling people your unsubstantiated theories about why they work in a thread where I'm trying to explain something, unless you want me to embarass you again. Since you've so vehemently opposed and derided my investigation of this phenomenon and my interest in it, I won't hold back on you as I've done up to now.

By the way, you still didn't answer as to why you don't simply export without normals instead of doing these other hacks, like adding extra microbevels or unwelding things. Do you have an emotional attachment to these extra steps in your workflow? Because so far, without normals we have no artifacts. The simplest, most logical "quick solution" to the problem is this: don't export your normals. Of course, I'm not an expert in modeling, so maybe it's important to do things the harder, more time consuming way, because I don't understand the ramifications of not having normals in my OBJ file.

Oh, and don't come back about "semantics" again. When you are failing to communicate effectively, it is your fault. It is illogical to object to a call for clarification in the meaning of your communications. That's what semantics are - the meaning of communications. I've never understood why labeling a point as "semantics" in any way invalidates the legitimacy of the point. It's like dropping your pants in public - it doesn't look that good - don't do it.

(Note to lurkers: If you think this was my finest performance, don't say anything at all.

Get it? LOL.
)

Don't make me post cat pictures guys.

Post em! We need cats, quick.

Let me show you them.

Attached.

Just a comment regarding the byplay here:

There are a few science boards that I frequent.  Occasionally, there will be a post from an excited user commenting on the possible causes of certain observed phenomenon, the "truth" behind a scientific theory or a very far fetched hypothesis concerning something more mundane.  However, quite frequently, the proffered explanations have no scientific merit and are based on entirely misunderstood principles or simply offered by a mind obsessed with the "fantastic" without much of a concern with "reality."

As would be suspected, such posts invariably draw the attention of more rational or informed thinkers who offer their explanations and/or corrections to the poster's line of reasoning or inquiry.  Occasionally, this is gratefully received.  More often than not, it is regarded as an insult, a personal attack or a condemnation of "free thinking" along with criticisms for the naysayer's lack of an "Open Mind."...

One thing that people must remember is that people search for answers to questions, quite frequently, in forums and other online media.  Almost invariably, what motivates those with knowledge and/or experience in certain matters to offer corrective criticisms or more appropriate answers and translations is based on a desire to serve those who may read the thread in the future seeking answers yet are ignorant of the principles being discussed.  They wish to provide those seeking knowledge with substantiated and meritorious information and knowledge concerning the subject instead of leaving open the possibility for irrational and horribly misunderstood information being presented without challenge to unsuspecting minds.

The point is this: Not every criticism is in bad spirit nor is it a personal attack.  Not everyone is singularly motivated to stand on a soapbox for tiny audiences but, more often than not, only wishes to help provide rational and well understood answers and comments that contain useful, meritorious knowledge for the benefits of the poster in question and future readers.

Something else must also be understood by those who are among the initiated: Even though one may spend hours playing "Whack-A-Mole" with irrational conclusions drawn by unknowledgeable people, each person is different and as deserving of fair treatment as anyone else.  Frustration with certain groups of people in general shouldn't be carried from thread to thread and poster to poster.  Sometimes, people really are only trying to gain knowledge and simply are misinformed or only need some helpful guidance - They're not always an antagonist and are frequently innocent of being involved in the War Against Ignorance.

Quote - ..Let me show you them.

Well said, Morkonan. I've attached a sticky note of your last paragraph to my mole hammer, with the title "read before using".

ok arguing and cats aside, getting back to the core of the discussion.

it seems that the artifacting is linked to normals. ok. but what is causing it? surely you would get the artifacting all the way round on each polygon intersection and not just one or 2 areas?

my interest in this, and why I'm posting from my semi-retirement on rendo, is to find out what causes it so I can avoid doing it and therefore save time in my workflow, and to avoid bumping up models with stupid polygon counts caused by microbeveling if it's not actually needed.

I'd kind of like to know why stuff like this happens - makes it a lot easier to model for poser if I don't have to faff around after the fact.  
As far as microbevelling goes - I wonder if just an edge loop or two would help - would save a lot of polys

I found on 1 test I've done, I took a cylinder that was causing it, microbeveled then deleted that bevel. the artifact was then gone.

ok that will probably come under  changing the normals etc, but it's another datum point.

Thanks for the obj. So I verify that it has an artifact, and that removing the UV info makes it go away.

UVMCyl differs from the other artifacting OBJ I was given. It has just two n-gons for caps, not a bunch of triangles.

Now the interesting thing about this is that all the vertices are shared (welded) but Poser only renders one of them as welded - the one generating the artifact.

Applying a displacement and turning on smoothing and varying the crease angle reveals something interesting.

Left to right is crease angle 80 (the default), 120, 22.51, and 22.49.

The upper row has no displacement. The lower row has displacement.

Apparently, a welded edge is treated as unwelded when the crease angle is exceeded. That's why some of them explode. But some don't completely explode.

What is interesting about 22.5 degrees? This cylinder has 16 sides. 360 / 16 = 22.5. Apparently the welding of the joint between the n-gon and the sides is not being treated the same, even though they are geometrically identical. (Or nearly so, I supposed - don't know if rounding has anything to do with this.)

So the reason we see the artifact is because exactly one of these joints is being treated as if it were only 23.5 degrees, even though the edge between side and cap is actually 90 degrees. That is a bug, but only if we expect n-gons to be supported.

Removing the UV info seems to alter this mis-interpretation. I'll have to go back to TheOwl's cylinder and study that like these renders. Might take me a while, because I have to do some paying work today, too. (sadly)

But before we study this case too much, is it worth it? I mean, everybody seems to accept the idea that n-gons are a "no no" to begin with. So do we care that this particular n-gon is making an artifact?

A quick test of TheOwl's cylinder shows a related dependence on crease angle. That cylinder has 20 sides, so the critical angle is 18 degrees. Sure enough, setting crease angle on that one to 17.99 makes the artifact go away. Of course, you lose all phong shading, but it is an interesting data point. The thing I found odd about TheOwl's Maya cylinder is that the welded points have VN lines that are not in agreement between the adjacent polygons. What I mean is for the top cap, all the VN's point up. For the side quad's, all the VN's point straight out sideways. Thus a welded vertex with contradictory normals between adjacent polygons seems to have something to do with the artifact.

It would seem that the artifact can only appear if:

there are vertex normals in the file
or there are UV coordinates in the file
or both

It seems it may always disappear if we have neither VN nor VT lines.

So I can summarize a partial hypothesis, which needs more testing.

N-gons work fine in all cases if you do not weld them to other polygons.
N-gons produce artifacts if you weld them to other polygons AND you have VT or VN information AND your crease angle is between the smallest and the largest angle produced by the joints.
Triangls produce artifacts if you have welded points with normals that disagree.

Now that's crazy, right?

Officially, does Poser "support" n-gons? If it is supposed to support them, then I think this is a Poser bug in the n-gon scenario.

I know Poser is supposed to support tris and quads, so TheOwl's cylinder should work. But ... I'm not certain that it is legal to claim the same shared vertex simultaneously has two different normals on it.

In the parlance of an OBJ file, is the sharing of a vertex merely a notational convention or is it supposed to semantically reflect an actual sharing of geometry. In case that is not clear, is re-using an existing vertex legal just to save space, or does that have topological implications that must be avoided by duplicating the coordinate in a new vertex?

I wonder. ppl have been saying that poser does not like long thin triangles. (there's a post recently where tri's were showing up on a flat wall)... could that be connected to this I wonder? - we're seeing the artifacting on a tri'd object at the start of this thread....

time to experiment...

Quote - I know Poser is supposed to support tris and quads, so TheOwl's cylinder should work. But ... I'm not certain that it is legal to claim the same shared vertex simultaneously has two different normals on it.

How would that work ? Unless Poser is splitting the difference between the two normals.  I always thought that a vertex could only have one normal on it

Quote - ...Officially, does Poser "support" n-gons? If it is supposed to support them, then I think this is a Poser bug in the n-gon scenario...

IIRC, according to DAZ, Poser doesn't support n-gons.  Tris and quads are only, specifically, supported.  It's in their guide to packing up products for sale, IIRC.

Quote - I know Poser is supposed to support tris and quads, so TheOwl's cylinder should work. But ... I'm not certain that it is legal to claim the same shared vertex simultaneously has two different normals on it.

I am by no means a professional.  That being said: When looking at problem areas with tris in Poser rendering, it's almost always either multiple "thin" tris crowded together (some applications exporting objects as all tris really, really screw it up for Poser) or tris that aren't coplanar to each other or that are bordering material zones with geometry not coplanar to the tris. (I think there is an example remark of that in the thread about the Wall and tris/ngons around here.)  Yet, I've also seen models that have been exported as all tris, have material zones all over them and are cloth objects that seem to perform just fine in rendering/preview....   Go figure.

Quote - In the parlance of an OBJ file, is the sharing of a vertex merely a notational convention or is it supposed to semantically reflect an actual sharing of geometry. In case that is not clear, is re-using an existing vertex legal just to save space, or does that have topological implications that must be avoided by duplicating the coordinate in a new vertex?

Not sure if this helps, but... Basically, as I understand it, the idea of "shared vertices" are used to reduce space and increase computation speeds but, in order to be understood, must also have an accompanying index which describes their role in the "geometry" to the video/renderer.

Quote - ,,,
I know Poser is supposed to support tris and quads, so TheOwl's cylinder should work. But ... I'm not certain that it is legal to claim the same shared vertex simultaneously has two different normals on it...

Perhaps what is being witness has something to do with this? 
http://www.webreference.com/3d/glossary/normal.html

"..Normals can be associated not only with the flat surfaces of the polygons, but also with the individual points that make up the vertices where polygons meet on the surface of a model. This technique is used in rendering to create the appearance of curved surfaces rather that flat, faceted sides. Such vertex normals can be directly assigned in the model file, but are usually computed during rendering by averaging the normals of the adjacent polygons. This rather subtle idea is described and illustrated in the Lesson 3 tutorial...."

And, specifically:

"....In flat shading, all of the points on a polygon surface have the same normal. They all point in the same direction. In smooth shading, the lighting for every point on the surface of a polygon is computed separately, and the normal is adjusted for each point so that there is a slight change of direction against the light at each pixel as it is drawn. To achieve smooth shading, the idea of a normal is expanded from what we already understand. We are no longer concerned with the normals of the individual faces, but rather of the normals at the points (the vertices) where these faces meet. The normal at a vertex is determined by averaging the normals of all the polygons that share it."  (Emphasis Mine)

So, what we're seeing is the render expressing the normals of all adjacent polys (faces)  connected to THAT vertex when the smooth shading operation takes place.  In the cases where there are render artifacts, it would possibly due to translation errors when averaging the normals of all the polys adjacent to the vertex being rendered in smooth shading operations. 

(In a related vein, I assume Vertex "normals" would be regularly be the "average normals" of the adjacent polys.)

Popping in - I have to read all this more carefully.

But just quickly, the Maya cylinder normals were not the average of all the adjacent faces. Only when I imported in Blender did it look that way.

In the Maya cylinder, each vertex had two different normals. The average of two side faces was used for a side face normal (basically pointing straight out along the radius). But the same vertex was specified as [0, 1, 0] (straight up) when using it in the cap.

If you think about it, that's reality, right? If you're going to use a single vertex to represent the corner of a pair of adjacent side quads, that doesn't have any Y component - it is horizontal. Whereas, the same point on the upper cap should be [0, 1, 0] all the way out to the edge.

In this type of model, we're asking the render to just ignore the common point. It's not REALLY the same point. In reality, it is impossible for the same point on a cylinder to simultaneously have a VN pointing up and a VN pointing out. But that's what is recorded in the file.

I don't think there is a legit way to interpret that.

In any case, if you don't have VN data in your OBJ at all, then there can be no VN contradictions., Then Poser will calculate the exact same normals, based on crease angle. That's why deleting the VN data works (I think) for the Maya cylinder.

Quote - In the parlance of an OBJ file, is the sharing of a vertex merely a notational convention or is it supposed to semantically reflect an actual sharing of geometry. In case that is not clear, is re-using an existing vertex legal just to save space, or does that have topological implications that must be avoided by duplicating the coordinate in a new vertex?

OBJ format works by 1) describing the vertices that make up an object (v entries), and 2) describing the faces made of those vertices (f entries).  Points can be "free floating" and not members of any polygon; points can also be members of multiple polygons; multiple points that are members of different polygons can also share coordinates.  Export a 6-poly cube to see this in its simplest form (attached).