Re: [Flightgear-devel] Problems with AC3D 4.0
Jim Wilson wrote: Andy Ross [EMAIL PROTECTED] said: Some "before after" FlightGear screenshots are available at: http://www.plausible.org/vertsplit [Be patient if things seem slow; there is 400k of images on that page and my DSL line has a 128kbps upload rate. If you don't want to wait, download the code instead and try it for yourself. :)] This looks great. Actually on my local copy of the 747 I've split the objects so that the flap surfaces look like that now. In addition to this change, it'd still be good IMHO to eliminate the merging of vertices (so that the modeler can decide where the splits are in AC3D and have it then rendered correctly in plib). How does the performance look (I'll take a look at your code tomorrow)? When I got into this a couple weeks ago, flightgear seemed to really drag for a while (longer) loading the KSFO area after I added the angle tests. BTW, I was also using the j3cub as a test case. The change really makes it look good! One maybe nit...is there an unintended split occuring down the center of the 747 fuselage? It seems like a sharp shade transition there (after pic). Can anyone please tell me where to put those cxxs, hxx and makefile files to compile successfully? - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Plib-devel] Re: [Flightgear-devel] Problems with AC3D 4.0
Erik Hofman wrote: Andy Ross wrote: Anyway, try doing a remove duplicate vertices pass on the weird-looking models and see if that fixes the problem. I'll take a look to see if I can find and reenable the old merging code. I am pretty sure I don't have them in the Fokker 50. I do optimizations very regularly during design time and it also isn't the sharping angle because it also happens in the slightly curved wings. I found the problem. The modeller (are you using Blender or AC3D?) is generating meaningless texture coordinates. A vertex will appear once with a UV of, say, [1 0] and then again with [0 1], etc... Plib can combine duplicated vertices, but it won't do so when they *appear* to be different due to differing texture coordinates. So it passes them on to me. The original normal calculator understands this, apparently, but I wasn't expecting to be fed geometrically identical vertices. My original splitter code was written to be used with with my own blender exporter which required/enforced projected textures (the bump mapping doesn't work well with hand-tweaked UV coordinates), so I never noticed this issue. Or maybe Blender doesn't exhibit this behavior; dunno. Really, this is a problem with the modeller and/or export code; the texture coordinates I'm seeing are nonsensical (the bo105 doesn't even *have* any textures defined, yet something has generated multiple UV coordinates for each vertex -- bizarre). But nonetheless, painting weird textures on a model shouldn't cause the normals (which are a geometric property -- they have nothing to do with texturing) to look funny. Basically, I need to preprocess the data to distinguish geometric identity from logical identity. It shouldn't be too hard, gimme a day or so. Regardless, take a very close look at your texture coordinates and make that unless you have a really good reason, you have only one, unique UV tuple per physical vertex. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Plib-devel] Re: [Flightgear-devel] Problems with AC3D 4.0
Andy Ross [EMAIL PROTECTED] said: Erik Hofman wrote: Andy Ross wrote: Anyway, try doing a remove duplicate vertices pass on the weird-looking models and see if that fixes the problem. I'll take a look to see if I can find and reenable the old merging code. I am pretty sure I don't have them in the Fokker 50. I do optimizations very regularly during design time and it also isn't the sharping angle because it also happens in the slightly curved wings. I found the problem. The modeller (are you using Blender or AC3D?) is generating meaningless texture coordinates. A vertex will appear once with a UV of, say, [1 0] and then again with [0 1], etc... Plib can combine duplicated vertices, but it won't do so when they *appear* to be different due to differing texture coordinates. So it passes them on to me. The original normal calculator understands this, apparently, but I wasn't expecting to be fed geometrically identical vertices. Ah yes. That is exactly right. Hmmm...I wonder why this is so? If the vertices are from identical index positions why would it be looking at texture coordinates? I'm wondering if this is really an old hack that was designed to fix someone's problem with the optimiser snapping together vertices. Until a couple weeks ago it was snapping anything a centemeter or less apart. But of course it wouldn't if the uv coords were different. My original splitter code was written to be used with with my own blender exporter which required/enforced projected textures (the bump mapping doesn't work well with hand-tweaked UV coordinates), so I never noticed this issue. Or maybe Blender doesn't exhibit this behavior; dunno. If you map adjacent surfaces to different (non-adjacent) parts of the texture then this will happen. I'm not sure about the helicopter, but the 747 has each side of the fuselage mapped to different parts of the same texture file (to get differing left and right sides). Really, this is a problem with the modeller and/or export code; the Speaking as a modeler... I'll blame it on the plib code :-D Actually I don't quite understand as I mentioned above, why this is being done this way. texture coordinates I'm seeing are nonsensical (the bo105 doesn't even *have* any textures defined, yet something has generated multiple UV coordinates for each vertex -- bizarre). Maybe...but not strange in the case of the 747 fuselage example, in the context of the ac format. But nonetheless, painting weird textures on a model shouldn't cause the normals (which are a geometric property -- they have nothing to do with texturing) to look funny. Basically, I need to preprocess the data to distinguish geometric identity from logical identity. It shouldn't be too hard, gimme a day or so. That would be great. It'd be nice to understand the original reason (if it was a good one). Regardless, take a very close look at your texture coordinates and make that unless you have a really good reason, you have only one, unique UV tuple per physical vertex. Please may I? ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
I wrote: Jim Wilson wrote: Wolfram Kuss wrote: I can even guess what the new info does: It says edges less than 45 degrees are smooth and more than 45 degrees are sharp. That might be difficult to implement in plib anyway. I did a little looking into this recently (as a parameter setting by the app,not a ac3d 4.0 attribute). Basically my investigation revealed that plib would have to split vertices (create duplicates on adjacent polygons) if their normal values weregreater than x degrees from each other. I have working code that does this, from my game project a few months back. Indeed, the idea is to start at each vertex in the mesh and walk around it, checking the angle of each edge you cross. Angles sharper than your threshold are flagged. You end up with a list of zones of smooth edges, which each get a new vertex with an appropriately averaged normal. OK, I got this code working in Plib. It took a little hunting around, but I finally discovered the OptVertexList stuff in ssgOptimizer which works in pretty much the same data model that my code was expecting. As implemented, this replaces the makeNormals() routine in the optimizer with a further-optimizing variant which intelligently splits vertices across sharp edges, to prevent the non-physical lighting artifacts that are seen when a vertex normal points in a radically different direction from that of the face to which it is attached. Some before after FlightGear screenshots are available at: http://www.plausible.org/vertsplit [Be patient if things seem slow; there is 400k of images on that page and my DSL line has a 128kbps upload rate. If you don't want to wait, download the code instead and try it for yourself. :)] IMHO, the geometry of the models looks much more solid and realistic with correct lighting. The effect that this patch has depends on the model that is being lit, of course. Models that are already highly tesselated (Lee's, for example) won't see much effect, but low poly models (like David's DC-3, 172 or Cub) look much better. Amusingly, one thing this patch doesn't do is fix the AC3D parser issue that started the discussion. Right now, the definition of sharp is fixed in code at an (interior) edge angle of 52°. It shouldn't be hard to get this parsed and turned into a property of the resulting ssg branch, but since I don't know much about either area of the code I thought I'd leave it for someone with more ssg experience. The new code isn't AC3D-specific, of course. It will work automatically for any Plib objects that call the optimizer to calculate their normals. Anyway, grab the new code (two new files, associated additions to Makefile.am and a modified ssgOptimizer.cxx) from http://www.plausible.org/vertsplit/vertsplit.tar.gz and try it out. Let me know what breaks; I've tested it only with FlightGear. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
On Thursday 30 October 2003 00:06, Andy Ross wrote: I wrote: Jim Wilson wrote: Wolfram Kuss wrote: I can even guess what the new info does: It says edges less than 45 degrees are smooth and more than 45 degrees are sharp. That might be difficult to implement in plib anyway. I did a little looking into this recently (as a parameter setting by the app,not a ac3d 4.0 attribute). Basically my investigation revealed that plib would have to split vertices (create duplicates on adjacent polygons) if their normal values weregreater than x degrees from each other. I have working code that does this, from my game project a few months back. Indeed, the idea is to start at each vertex in the mesh and walk around it, checking the angle of each edge you cross. Angles sharper than your threshold are flagged. You end up with a list of zones of smooth edges, which each get a new vertex with an appropriately averaged normal. OK, I got this code working in Plib. It took a little hunting around, but I finally discovered the OptVertexList stuff in ssgOptimizer which works in pretty much the same data model that my code was expecting. As implemented, this replaces the makeNormals() routine in the optimizer with a further-optimizing variant which intelligently splits vertices across sharp edges, to prevent the non-physical lighting artifacts that are seen when a vertex normal points in a radically different direction from that of the face to which it is attached. Some before after FlightGear screenshots are available at: http://www.plausible.org/vertsplit [Be patient if things seem slow; there is 400k of images on that page and my DSL line has a 128kbps upload rate. If you don't want to wait, download the code instead and try it for yourself. :)] IMHO, the geometry of the models looks much more solid and realistic with correct lighting. The effect that this patch has depends on the model that is being lit, of course. Models that are already highly tesselated (Lee's, for example) won't see much effect, but low poly models (like David's DC-3, 172 or Cub) look much better. Amusingly, one thing this patch doesn't do is fix the AC3D parser issue that started the discussion. Right now, the definition of sharp is fixed in code at an (interior) edge angle of 52°. It shouldn't be hard to get this parsed and turned into a property of the resulting ssg branch, but since I don't know much about either area of the code I thought I'd leave it for someone with more ssg experience. The new code isn't AC3D-specific, of course. It will work automatically for any Plib objects that call the optimizer to calculate their normals. Anyway, grab the new code (two new files, associated additions to Makefile.am and a modified ssgOptimizer.cxx) from http://www.plausible.org/vertsplit/vertsplit.tar.gz and try it out. Let me know what breaks; I've tested it only with FlightGear. Andy That looks good. This should certainly allow me to reduce the vertex count quite a lot because I won't need to split so many objects ( which results in duplicate vertices edges). I'm not sure how much I'll be able to reduce the face count though. For example, if you look at an engine nacelle from the side you don't need many points to make the surface look smooth but when you look at it from the front or back the poly outline is pretty clear - that's when I tend to use more polys. I can't really see any way around that. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Andy Ross [EMAIL PROTECTED] said: Some before after FlightGear screenshots are available at: http://www.plausible.org/vertsplit [Be patient if things seem slow; there is 400k of images on that page and my DSL line has a 128kbps upload rate. If you don't want to wait, download the code instead and try it for yourself. :)] This looks great. Actually on my local copy of the 747 I've split the objects so that the flap surfaces look like that now. In addition to this change, it'd still be good IMHO to eliminate the merging of vertices (so that the modeler can decide where the splits are in AC3D and have it then rendered correctly in plib). How does the performance look (I'll take a look at your code tomorrow)? When I got into this a couple weeks ago, flightgear seemed to really drag for a while (longer) loading the KSFO area after I added the angle tests. BTW, I was also using the j3cub as a test case. The change really makes it look good! One maybe nit...is there an unintended split occuring down the center of the 747 fuselage? It seems like a sharp shade transition there (after pic). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
* [EMAIL PROTECTED] (Andy Ross) [2003.10.29 18:09]: snip/ Some before after FlightGear screenshots are available at: http://www.plausible.org/vertsplit [Be patient if things seem slow; there is 400k of images on that page and my DSL line has a 128kbps upload rate. If you don't want to wait, download the code instead and try it for yourself. :)] snip/ http://www.plausible.org/vertsplit/vertsplit.tar.gz snip/ I almost gave up on loading the page. Here's a mirror: http://unbeatenpath.net/software/fgfs/www.plausible.org/vertsplit/ Thanks, Andy -- Cameron Moore [ I tried to draw my shadow once, but my arm kept moving. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Hi Lee Lee Elliott writes I think Andy and Wolfram are right on the trail of the cause. Have you tried running a diff between the two files? How much of it is the same and how much is different? As I said I dont have to make any changes to the file in 4.0 just load it into AC3D 4.0 and save it again and the crease 45.00 statement occurs throughout the .ac file. Still on 3.6 here. Then my advice is to stay on it.Unless someone comes up with a quick fix on the AC3D forum then I will be going back to 3.6 myself. LeeE Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Andy Ross [EMAIL PROTECTED] said: The basic idea is pretty simple, but the edge cases (non-closed meshes, for instance) turned out to be enormously hard to get right. But the final result looks really good -- none of the diagonal shading stripes that you see on many of the aircraft wings due to being mis-lit at a corner. And it's really not slow at all -- it happens only at load time, and in my experience was noise compared to the I/O and parsing overhead. It does, obviously, increase the vertex count; but no more than a properly lit/normaled model would have in the first place. And it has the notable advantage of allowing the modeller to preserve the mesh structure without worrying about vertex duplication and normal direction. I think with flightgear, the concern could be more with the loading of scenery elements (that depends on vertex counts). That isn't to say that the process couldn't be improved from where I got with it. Without going further, my conclusion was that there were some basic problems with the way the optimiser was messing with the vertices and that if these behaviors were eliminated the modeler could control crease shading the same way they can in the ac3d 3.6 and earlier editor views (by having non-shared vertices on adjacent surfaces). Problem areas in the plib loader are the merging/snapping of vertices, and possibly some information lost during triangulation (so that normals that ought not get averaged, might still). Generally, I'm more in favor with leaving control in the hands of the modeler and not doing things like adding vertices to fix up the shading. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Innis Cunningham wrote: FATAL: ac to gl: unrecognised token ' crease 45.'. So, in the new AC3D version, they added a so called token. This means that the new version saves some additional info that the old version does not. Since PLIB does not (yet ;-)) know about this, PLIB throws the above error message. I can even guess what the new info does: It says edges less than 45 degrees are smooth and more than 45 degrees are sharp. Since AC3D V4 always saves in the new format, it does not mater whether you changed something. Anyway, send me a small file with the problem and I will have a look. As ulta-short-term workaround, you could do this: Open the file in an ascii editor like notepad. Search for the line. I would guess the crease 45. stands alone on one line. Delete it. Make sure there are no other lines like it. Try again. Cheers Innis The Mad Aussi Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
[EMAIL PROTECTED] said: Innis Cunningham wrote: FATAL: ac to gl: unrecognised token ' crease 45.'. So, in the new AC3D version, they added a so called token. This means that the new version saves some additional info that the old version does not. Since PLIB does not (yet ;-)) know about this, PLIB throws the above error message. I can even guess what the new info does: It says edges less than 45 degrees are smooth and more than 45 degrees are sharp. Since AC3D V4 always saves in the new format, it does not mater whether you changed something. Anyway, send me a small file with the problem and I will have a look. As ulta-short-term workaround, you could do this: Open the file in an ascii editor like notepad. Search for the line. I would guess the crease 45. stands alone on one line. Delete it. Make sure there are no other lines like it. Try again. That might be difficult to implement in plib anyway. I did a little looking into this recently (as a parameter setting by the app, not a ac3d 4.0 attribute). Basically my investigation revealed that plib would have to split vertices (create duplicates on adjacent polygons) if their normal values were greater than x degrees from each other. The biggest problem is it would slow down the loader so much to make it useless for flightgear scenery objects. A better solution to the crease situation would be do optionally eliminate the automatic snapping of vertices in the plib optimiser and allow the modeller to do what they want in ac3d...good or bad. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Sorry that my email was not clear. The only thing I would implement (at least in the short term) is that PLIB ignores this token. So, it would hopefully be quite trivial to do; I do not have time for more right now anyway. However, like you also say, I do think this would also be a good thing. It seems that AC3D always writes this token, even if the user did not change it. Else Innis would probably have remembered setting it. So, if we would look at it always, it would be a bad thing IMHO. So, one would have to decide when to use it. And even then I guess there are more tedious, but flexible ways to get the same effect (some edges sharp, others smooth). bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Jim Wilson wrote: That might be difficult to implement in plib anyway. I did a little looking into this recently (as a parameter setting by the app, not a ac3d 4.0 attribute). Basically my investigation revealed that plib would have to split vertices (create duplicates on adjacent polygons) if their normal values were greater than x degrees from each other. The biggest problem is it would slow down the loader so much to make it useless for flightgear scenery objects. I have working code that does this, from my game project a few months back. Indeed, the idea is to start at each vertex in the mesh and walk around it, checking the angle of each edge you cross. Angles sharper than your threshold are flagged. You end up with a list of zones of smooth edges, which each get a new vertex with an appropriately averaged normal. The basic idea is pretty simple, but the edge cases (non-closed meshes, for instance) turned out to be enormously hard to get right. But the final result looks really good -- none of the diagonal shading stripes that you see on many of the aircraft wings due to being mis-lit at a corner. And it's really not slow at all -- it happens only at load time, and in my experience was noise compared to the I/O and parsing overhead. It does, obviously, increase the vertex count; but no more than a properly lit/normaled model would have in the first place. And it has the notable advantage of allowing the modeller to preserve the mesh structure without worrying about vertex duplication and normal direction. The only problem is that the code as it stands is not even remotely Plib-like. The model format is based on the syntax of the Nasal language that I wrote as part of the project, it contains (or is polluted by, depending on your viewpoint) support for dot3 bump mapping and prototype-quality stencil self shadows*. * Self only, with no particular integration into the rest of the scene, thus the prototype quality. And it's slow currently; doing too much CPU work to get the list of front-facing normals. But if anyone wants to play with it, the relevent code is up at: http://www.plausible.org/andy/model.tar.gz Specifically, take a look at Model::calcNormals(), which is the code responsible for the edge-sharpness-based vertex splitting. Ignore the TexBlock stuff, which is a texture state bucketing implementation largely useless in a Plib context (it's tied to rendering assumptions in the rest of my code). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
On Monday 27 October 2003 15:40, Innis Cunningham wrote: [EMAIL PROTECTED] writes Innis Cunningham wrote: FATAL: ac to gl: unrecognised token ' crease 45.'. So, in the new AC3D version, they added a so called token. This means that the new version saves some additional info that the old version does not. Since PLIB does not (yet ;-)) know about this, PLIB throws the above error message. I can even guess what the new info does: It says edges less than 45 degrees are smooth and more than 45 degrees are sharp. Since AC3D V4 always saves in the new format, it does not mater whether you changed something. Anyway, send me a small file with the problem and I will have a look. As ulta-short-term workaround, you could do this: Open the file in an ascii editor like notepad. Search for the line. I would guess the crease 45. stands alone on one line. Delete it. Make sure there are no other lines like it. Try again. Bye bye, Wolfram. Thanks Wolfram you are bang on.It appears this is a new feature in 4.0 which Plib has not caught up with.The easiest solution I can think of is to reinstall the previous version of AC3D and use it till a fix can be found. I just would be interested if someone in here who is using v4.0 has got it to work. I will follow your advice and see if the crease statement on occurs once or more often. Thaks for the replies Cheers Innis The Mad Aussi I think Andy and Wolfram are right on the trail of the cause. Have you tried running a diff between the two files? How much of it is the same and how much is different? Still on 3.6 here. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
