[Bobboau]

don't smooth shade blocky geometry, use auto-facet with a very narow facet angle.

[aldo_14]

Originally posted by Bobboau
don't smooth shade blocky geometry, use auto-facet with a very narow facet angle.

Um....what has that got to do with this?  I'm trying to get it to shade correctly, i don't care about the shading angle.

[Bobboau]

from what I saw in that thread you posted in the SCP forum you were smooth shadeing a mesh that should not have been smooth shaded, resulting in very uggly (incorect) shadeing

[aldo_14]

Originally posted by Bobboau
from what I saw in that thread you posted in the SCP forum you were smooth shadeing a mesh that should not have been smooth shaded, resulting in very uggly (incorect) shadeing

It was the shading boundaries that concerned me.  i.e. it was non-uniform, like the faces were being split. I wanted a standard goaruad / 90 degree shading across it (i.e. palestercine effect).  What I got was effectively differently shaded regions that looked, well, odd ingame.

I'll try and get an example of it....

EDIT; i'm not sure if this is what you mean,t but I noticed the msoothing angle in TS for some of the maps differed..... I'm checking that now.  (EDIT2 - doesn;t look like it... I did manage to get one correctly smoothed lod working, but i don;t know why....)

Here;
cob
Pof

[aldo_14]

If I copy the same model (i.e. and rename - but same geometry, UV, and mapping details) for the lods, then the smoothing works.  Otherwise, it FUBARs.

[KARMA]

Originally posted by aldo_14


You get the odd shading effect on subobjects though, don't you?  That comes from the splitting of vertices, I think (although i'm struggling to figure out why - PCS should weld all the identical vertexes together and, more relevantly, it only occurs if the model is a subobject or LOD level).

I get the shading effect you are talking about even with models built directly in TS, and I can grant you that their verts aren't splitted.
Also, there's no reason for this should happen when the verts are splitted, actually it should be the opposite: if all the polys with the same uvmap are separated like a submodel, then you'll have, in average, a cleaner surface, without hard edges, which result in better shadings. It is like if you use smoothgroups.
Moreover, I got that shading effect, as seen in modelview, even on models without multiple uvmaps.
Have you tryed in truespace to select one of the verts at the edge of an uvmap and move it around? If it is splitted you should see a second vert in the same position.
BTW it is interesting instead the fact that you don't get this effect when you use a copy of lod0 as lod1

[StratComm]

Could PCS possibly be trying to apply the smoothing data from the primary model to all subsequent objects?  I.e. reusing the calculations from the first subobject to fix the smoothing normals for all of the objects?  That would explain why a perfect duplicate works, but nothing else does.

[aldo_14]

Originally posted by KARMA

I get the shading effect you are talking about even with models built directly in TS, and I can grant you that their verts aren't splitted.
Also, there's no reason for this should happen when the verts are splitted, actually it should be the opposite: if all the polys with the same uvmap are separated like a submodel, then you'll have, in average, a cleaner surface, without hard edges, which result in better shadings. It is like if you use smoothgroups.
Moreover, I got that shading effect, as seen in modelview, even on models without multiple uvmaps.
Have you tryed in truespace to select one of the verts at the edge of an uvmap and move it around? If it is splitted you should see a second vert in the same position.
BTW it is interesting instead the fact that you don't get this effect when you use a copy of lod0 as lod1

Well, goaraud shading is based around, IIRC,  gradient of the 'normals' of each vertice...so my current theory is that somehow those normals are getting screwed up, i.e. by split vertices.  But I'm, in all honesty, completely lost as to the cause.

Originally posted by StratComm
Could PCS possibly be trying to apply the smoothing data from the primary model to all subsequent objects?  I.e. reusing the calculations from the first subobject to fix the smoothing normals for all of the objects?  That would explain why a perfect duplicate works, but nothing else does.

It would almost seem that way, but Bob says he has perfectly smoothed stuff, so it shouldn't be that.  Also, I'm sure this occurs with cob2fs as well.

[KARMA]

well, then trust me, it is a discussion I had with the xwaup guys, since xwa doesn't support smoothgroups (while FS does, and  I suggest you to use them), and they were trying to simulate smoothgroups by splitting the mesh in order to have all the coherent group of polys (which often correspond to different  uvmaps obviously) as a splitted submodel.
The point is that if you apply the same smooth angle (either autofacet or smooth) to all the model you can have ugly results, autofacet helps a lot since it is applyed dinamically, but when you have hard edges connected to rounded elemnts the shadings get 99% of the times screwed. You can solve this by using smoothgroups, we can use them and we should use them.
The problem is that what you are pointing out is a different thing and it seem related not to the model.
Again, I suggest you to test the verts into truespace, as I never noticed splitting edges, or at least verify that the pof has more verts than what it should.
Also, you'll never have support on this from the SCP guys if you don't post in game shots. I can't, but I guess you could find someone to take shots for you

[aldo_14]

Originally posted by KARMA
well, then trust me, it is a discussion I had with the xwaup guys, since xwa doesn't support smoothgroups (while FS does, and  I suggest you to use them), and they were trying to simulate smoothgroups by splitting the mesh in order to have all the coherent group of polys (which often correspond to different  uvmaps obviously) as a splitted submodel.
The point is that if you apply the same smooth angle (either autofacet or smooth) to all the model you can have ugly results, autofacet helps a lot since it is applyed dinamically, but when you have hard edges connected to smoothed elemnts the shadings get 99% of the times screwed. You can solve this by using smoothgroups, we can use them and we should use them.
The problem is that what you are pointing out is a different thing and it seem related not to the model.
Again, I suggest you to test the verts into truespace, as I never noticed splitting edges, or at least verify that the pof has more verts than what it should.
Also, you'll never have support on this from the SCP guys if you don't post in game shots. I can't, but I guess you could find someone to take shots for you

Can;t check the pof, as PCS automatically merges identical vertices

Did check the cob;
Vertices: 932
Triangles: 1863

Which seems ok...but I don;t know how to check it in TS.  Likewise, i don;t know a jot about assignment of smoothgroups in TS, and - to be honest - I have no intention of learning it.

[KARMA]

easyer that what you can imagine:)

to check verts:
open the model in TS

click the button "select vertices": you'll automatically enter into point editing mode, which mean you can edit the vert/faces/edges of a specific mesh; to return to object editing just click the button of object selection, the one with the arrow

click on one of the incriminated verts, hold on the left mouse button, then move around the vert. If the vert is splitted you'll see a second vert on the same position, elseway all the edges connected to the moved vert will move out.

also, you can right click the object selection tool, the one with the arrow, the object properties table will appear, and you'll be able to check the number of polys/verts

for the smoothgroups I'll post later since I've no time atm.
btw afaik PCS doesn't weld verts on the same position, but I may be wrong

[aldo_14]

Originally posted by KARMA
easyer that what you can imagine:)

to check verts:
open the model in TS

click the button "select vertices": you'll automatically enter into point editing mode, which mean you can edit the vert/faces/edges of a specific mesh; to return to object editing just click the button of object selection, the one with the arrow

click on one of the incriminated verts, hold on the left mouse button, then move around the vert. If the vert is splitted you'll see a second vert on the same position, elseway all the edges connected to the moved vert will move out.

also, you can right click the object selection tool, the one with the arrow, the object properties table will appear, and you'll be able to check the number of polys/verts

for the smoothgroups I'll post later since I've no time atm.
btw afaik PCS doesn't weld verts on the same position, but I may be wrong

Ts is getting on my tits.  Vertices don't seem split, can;t tell for sure.

Screens of another model (didn;t have a better version to take), which show the irregular lighting




This model looks apallling in certain lighting conditions, when the front (the non shaded bit) is being let.

In modelview;

[StratComm]

I think I'm right, and I think I can prove it.  I just made a simple test case in Truespace: one sphere, textured in an arbitrary freespace texture and smoothed as a group, copied twice over and glued up as a three-subgroup object.  I converted it to pof, and I get the following:

The original (base) sphere, viewed straight on in Modview, textures off.  Normal enough (though you can tell the sphere is a little low-poly).


Secondly there is an identical copy of said sphere, glued as subobject 1.  Identical in every way to the base sphere, and no visable difference here.


Third, and most importantly, a copy of the base sphere spun around 180 degrees in truespace.  The viewing angle hasn't changed, but as you can see the normals are now FUBARed.  As you can see, each face is lit as though it was on the other side of the sphere from where it actually is.  On the first subobject, the same face is on the opposite side of the sphere, and would be recieving that particular lighting if it were rendered.  Thus, the subobject is inheriting the normals from the original model, rather than getting the correct ones assigned.


And I'll go ahead and upload the sample case too: test.zip

The reason submodels look completely wrong (much worse than my sphere sample) when smoothed, as in aldo's example, is that adjacent faces in a subobject have a different set of corresponding vertices that more often than not do not correspond with vertices of adjacent polygons on the primary submodel.  So when Modview or Freespace tries to average the normals, it doesn't work correctly and instead looks like you are connecting polygons that meet at a very sharp angle.  Don't quite know how much that description makes sense, but hopefully Kazan can spot what's going wrong.  First thing I would do is check the array that the normals are stored in; it looks like it either isn't getting reinitialized properly after a pass through a subobject, or the index isn't updating properly if the array is simply being appended to.

[KARMA]

well that's very interesting strat
I think you may be right, although I think that the fact that the screwed shadings appear onto the subobjects of lod0 too doesn't support your theory

[StratComm]

No that's just the low-polyness of the sphere showing itself off, not a conversion error.  There technically aren't any "screwed" shadings on any of those spheres, but the fact that the third sphere looks inverted is the evidence I'm relying on.

[aldo_14]

Originally posted by KARMA
well that's very interesting strat
I think you may be right, although I think that the fact that the screwed shadings appear onto the subobjects of lod0 too doesn't support your theory

Not if it's only the root model that has the shading applied.  IIRC, the cob file is broken into a tree structure, so only the LOD0 hull model would be shaded - and then that shading reused for all branches (submodels in the cob file) on that tree.

What i don't understand, is why that would be done.  Unless the pof format stores smoothing info in an odd, non-model specific way.

[StratComm]

I think it's a glitch in conversion, rather than in the reading of the POF format.  If memory serves, the basic conversion function is common to both PCS and cob2fs2, so a flaw in one could exist in the other.

Oh, and I never said I LOD'ed that sphere.  It actually all falls under LOD0.

[aldo_14]

Originally posted by StratComm
I think it's a glitch in conversion, rather than in the reading of the POF format.  If memory serves, the basic conversion function is common to both PCS and cob2fs2, so a flaw in one could exist in the other.

Oh, and I never said I LOD'ed that sphere.  It actually all falls under LOD0.

I meant as in how the data is stored within the pof.

[StratComm]

I realize that, but no matter how it is stored (unless smoothing simply isn't stored for subobjects) it has to be parsed back out when loading into the graphics engine.  And since the error is common to both Modelview and FS2, my opinion is that it is being set incorrectly rather than read or stored incorrectly.  As PCS is full-bright (and I think aurora is too) those don't help us evaluate the problem much.

[aldo_14]

Originally posted by StratComm
(unless smoothing simply isn't stored for subobjects)

that's the bit i was wondering about

Of course, I did try and check the pof specs, but I couldn;t really identify where smoothing data is stored - unless it's in the 'properties' string of the OBJ chunk.  Or maygbe bsp-data, but to be honest i'm starting from stratch trying to figure out this format.