Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: aldo_14 on June 10, 2004, 04:32:07 pm
-
..without splitting vertices to support them ala 3ds?
-
you mean multiple uvs on the same polys?
-
Nope. Just multiple UVs on the same model where faces with different UVs share vertices.
i.e. 3ds splits vertices to support multiple UV maps - but this screws up the smoothing when I convert.
-
You need to reweld the vertices after you have created the seperate surfaces if it's anything like Lightwave, else smoothing won't take effect, don't know if that helps :)
-
Originally posted by Flipside
You need to reweld the vertices after you have created the seperate surfaces if it's anything like Lightwave, else smoothing won't take effect, don't know if that helps :)
Well, there's no way in hell I'm going to reweld anything in TS.........so I'm trying to find an alternate format to export from max.
-
.OBJ Format is a good one, I find, it's pretty portable and I'm pretty sure even Lithium can auto-merge points, 3D Exploration certainly can :)
-
mmm I converted many unwrapped 3ds models without problems, and I often used it as intermediate "safe" format with lithunwrap or 3dexp, so that's strange. You sure there isn't some specific option about this? well, anyway, let's wait for nico's reply
-
Originally posted by Flipside
.OBJ Format is a good one, I find, it's pretty portable and I'm pretty sure even Lithium can auto-merge points, 3D Exploration certainly can :)
I lose the UV when I convert to obj for some reason :(.
-
Ugh! :( Sounds like the ritual I have to go through to get a model into Deep Paint :( I work in Lightwave, but for some reason I have to export as an obj, then, before I load the .obj in 3D Exploration, I first have to load it into UVMapper, and then save it again straight away, again as a .obj. Only now will Deep Paint or 3D Exploration see the UV Mapping properly. It's amazing the things we do :nervous:
-
It's getting right on my tits, that's for sure.
-
Well, there must be, in Max or Truespace a generic 'merge any two points occupying the same space' command, anyone here able to help?
-
Originally posted by Flipside
Well, there must be, in Max or Truespace a generic 'merge any two points occupying the same space' command, anyone here able to help?
Has to be in TS, natch. Unless someone knows of a max->cob exporter
-
3d Exploration?
-
Originally posted by Liberator
3d Exploration?
Flips every normal converting to cob, loses UV converting to cob.
-
mmm as I already said, I already converted both 3ds and obj without problems using 3dexp.
Example: the xwaup ships can be converted from opt to uvmapped 3ds, and they use dozens and dozens of different small textures (some ships have 40+ textures...), and I never had any problem opening them with truespace directly and saving the uvcoords, and I never noticed this splitting verts thing.
also, I used 3dexp in the past to convert both 3ds and obj to cob, IIRC saving the uvs for obj too.
And flipping faces in TS is pretty easy, but unfourtunately there isn't a merge verts tool
BTW, if someone can solve your problem, it is probably nico
-
Originally posted by KARMA
mmm as I already said, I already converted both 3ds and obj without problems using 3dexp.
Example: the xwaup ships can be converted from opt to uvmapped 3ds, and they use dozens and dozens of different small textures (some ships have 40+ textures...), and I never had any problem opening them with truespace directly and saving the uvcoords, and I never noticed this splitting verts thing.
also, I used 3dexp in the past to convert both 3ds and obj to cob, IIRC saving the uvs for obj too.
And flipping faces in TS is pretty easy, but unfourtunately there isn't a merge verts tool
BTW, if someone can solve your problem, it is probably nico
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).
-
It's nothing geometry-related that causes that smoothing error, as it occurs on a sphere created in Truespace.
-
Originally posted by StratComm
It's nothing geometry-related that causes that smoothing error, as it occurs on a sphere created in Truespace.
Not to me. I checked with the same sphere as lod0 and lod1 - same smoothing on both.
-
Well, in blender, removing double vertices is a breeze, it even allows you to specify how far apart they may be to get welded. However, I have no idea what it does in combination with multiple UV's....
-
Originally posted by JarC
Well, in blender, removing double vertices is a breeze, it even allows you to specify how far apart they may be to get welded. However, I have no idea what it does in combination with multiple UV's....
Last time I used blender it didn't even have UV mapping - at least as far as anyone could figure it out. :)
-
don't smooth shade blocky geometry, use auto-facet with a very narow facet angle.
-
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.
-
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
-
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 (www.aldo14.f2s.com/smoothTest.cob)
Pof (www.aldo14.f2s.com/test.pof)
-
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.
-
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
-
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.
-
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.
-
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
-
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.
-
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
-
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
(http://www.aldo14.f2s.com/screen00.jpg)
(http://www.aldo14.f2s.com/screen01.jpg)
This model looks apallling in certain lighting conditions, when the front (the non shaded bit) is being let.
In modelview;
(http://www.aldo14.f2s.com/mv.jpg)
-
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).
(http://www.geocities.com/cek_83/original.txt)
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.
(http://www.geocities.com/cek_83/copy1.txt)
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.
(http://www.geocities.com/cek_83/copy2.txt)
And I'll go ahead and upload the sample case too: test.zip (http://www.geocities.com/cek_83/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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (http://www.descent-freespace.com/ddn/specs/pof/), 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.
-
I think smoothing normals are stored in the OBJ2 chunk, in the TMAPPOLY portion of the bsp_data structure. Could be wrong, but that's the most likely place I can find for it. Smoothing is controlled by the normals on the vertices around the edges of a polygon, and that's the only place I can find that data at all.
-
Originally posted by StratComm
I think smoothing normals are stored in the OBJ2 chunk, in the TMAPPOLY portion of the bsp_data structure. Could be wrong, but that's the most likely place I can find for it. Smoothing is controlled by the normals on the vertices around the edges of a polygon, and that's the only place I can find that data at all.
Think you could be right there - specifically the radius value could indicate a radians value for the smoothing angle.