You mean I could possibly load up Mike, Vicki and the Mil Dragon, re-export without the normals and cut the file size/render time/memory load? That would be so cool. Please, nobody come up with a good reason for not doing this.

Because a lot of us don't know what that accomplishes and if the default works, messing with it seems dumb? ;-) I'll have to give it a try on stuff I've downloaded. For my freebies, I'd keep the normals in because people might be using the .obj files in programs other than Poser, and I have no clue which programs need the normals, and which ones do not. Do people want to experiment on this and see what effect this has on different programs, like Vue, Bryce, etc.?

I do. :) In answer to post 3, I've not seen any difference in the way my files behave in Bryce 4/5 Vue 3/4, Poser, Softimage XSI, Cinema 4d or Messiah. Dunno what normals do, but I remove them as a matter of course because it makes the file size much smaller.

Having said that, I don't think the normals on export is an option in Poser 4, but it is in UV mapper

If you export an obj file from Poser. Poser automatically put the normals info back in. And the file size jumps up. I don't have many DAZ items. Some props I have from a long time ago were not optimized. But I just checked the Gorilla.obj and that one does seem to be optimized. I know Dan Wilmes CR2 program was adopted by DAZ and it will do the same thing. So maybe they run it through that program these days to optimize the file sizes. ScottA

Perhaps. I'm sure one of the submission criteria at Daz is for "no normals" in the file. Maybe I read that wrong or somewhere else though. I am surprised to see they leave them in. Even without UVmapper or Cr2Edit the normals can be removed in a text editor by deleting everything beginning vn (vertice normal) and resaving the file. It is a valid point though that many people might not even be aware that they can remove the normals without it seriously affecting integration with other applications.

I didnt know about this, but will be doing it from now on...thanks

The normals are not used in poser at all, even if they exist. Other apps may use this info it it is available. Poser decides the normal by the order in which the vertices are defined. Take the points and define them starting at one point and working around it. Now look at the polygon so that the points were defined in a clockwise order. The normal will be facing in this direction. So in order to change normals in poser you have to be sure you define the polygons in a clockwise manner when looking at them from the outside. Many apps do this but some fail and use the VN lines to actually define it.

I ALWAYS remove the normals from my files before uploading them. Just to sum up the whole thing. 1. Poser doesn't use normals. 2. You can remove them by exporting an obj to uv mapper and resaving without normals. This cannot be done in poser. 3. I've heard some people complain about models with no normals because (apparently), in Bryce and some other apps, that information is needed. 4. DAZ specifically ask their vendors to remove all normals before submitting models, to cut down file size. 5. I haven't done extensive checking, but removing the normals generally cuts down the file size by at least 10 - 20%, if not more. It depends a lot on the type of model. I suppose the reason the average poser hobbyist doesn't do this is that a lot of them don't use uv mapper, and those who do maybe don't know about it. Having said all that, I don't know if I'd reccommend it to the average user as a fix-all for big files. Messing about with the Geometries is fine if you know what you're doing, but writing over original files can be tricky, so beware! I do it with things I make myself. I've never done it with the poser .obj files, (mainly because I can't be bothered). mac

Thanks for the info - I did not know that till now - great news, will try it. SWAM

You can uncheck Export UVMapper Regions, as well, to maybe save a bit more file size. I haven't played with that option, so I don't know how it works, or if it makes a difference if you don't have anything assigned to regions.

wyrwulf, Unchecking regions doesn't make any difference. It only takes effect if you've assigned regions in uv mapper. mac

Pardon my moment of stupidy, but this won't mess up the obj whatsover (at least as poser is concerned :) ) and morph target will still load fine. Just want to know coz I am modelling and smaller mesh sizes are ALWAYS a big plus to me. Regards, Josef

• Normals describe which way the surface of the polygon faces to the rendering engine (used in lighting/shading computations). - Poser ignores any normals in the file and generates it's own (which is unfortunate, because it means that you can't supply corrective normals to fix seams, etc). - Many other apps need the normals. - Just deleting all the 'vn' lines is NOT a valid thing to do... those lines are also referenced by the 'f' (facet) lines... if you are going to delete the normals (correctly), you need to remove those references as well. While Poser may read files edited in this fashion, it's a good bet that a majority of the rest of 3D software in the world will barf trying to read these illeagally formatted files. If you insist on removing the normals, please use an export option in UVMapper or some other sftware. - Removing normals only appreciably reduces the uncompressed .obj file size... since .obj files are text, they compress very well, with or without normals, so it doesn't make that much difference in download (compressed) file size. - Removing normals makes zero difference in rendering speed... since Poser will have already re-computed it's own normals, whether or not they were included in the file. Just some food for thought ;).

I wasn't sure, but I thought it might make a difference.

"removing normals does not speed up rendering". Don't tell that to my PC. It doesn't know that and I'd prefer that it stayed that way. ;-) ScottA

ARRGGGHHHH!!! Sigh. I just typed a 4 page essay on this topic and (like an idiot) forgot to 'copy' it before hitting the "Post Reply and Hope you haven't taken too long" button. Grrrrr.

(let's see if I can do this again...) Jim, Poser does indeed use normals... ones that IT computes. It computes them (as Kattman describes above) based on the ordering of the vertices. So if you reverse the normals (or 'reverse winding order'), you'll end up with that inside-out image you posted - whether or not you include normal vertices in the file. (that's the short version of my essay ;). - Keith

Attached Link: http://spanki.home.mindspring.com/bs_uguide.htm

it's a good bet that a majority of the rest of 3D software in the world will barf trying to read these illeagally formatted files. Maybe, maybe not. I have no way of judging "the rest of the 3d world." I can only look at the software I've tried out using my files to play with the tools in that software. Normally I don't hand edit vn lines out of a file though I have done, uvmapper does that perfectly well. But, with Softimage, Cinema4D, Bryce 4 and 5, Poser 3 and 4, Messiah, Maya, and a couple others I can't recall off-hand they did not barf at all. Loaded the object file and it looked just like it did in any other app that I tried. Whether there are apps that hate missing normals exists, I haven't found it yet. No doubt there's at least one, maybe more out there somewhere. shrug

Questor, Most apps that deal with .obj files can handle missing normal vertices - as long as the indices are not present as well. I also don't doubt you when you say that the apps you've tried also handle corrupted .obj files (illeagally formatted, not-to-spec, whatever you're comfortable with ;)). As a programmer, I have done extensive work with the file format and have run across a LOT of different ways that programs (and users) tend to create corrupted or mal-formed files. My point is - if you know that what you're doing is not correct, then why not do it the correct way? Why add one more source of poorly formed .obj files to the mix? It's easier to use something like UVMapper to remove the normals anyway shrug. [sorry, it's just a sore spot for me, after fighting through countless special-case coding to handle corrupted .obj files]

Thanks Questor. That's exactly what I was asking about. This is something that should be done AFTER you are done creating a figure. If the normals are reversed and you remove the normals info fromn the file. They will stay reversed. That might be where some people are confused. ScottA

It's easier to use something like UVMapper to remove the normals anyway shrug. Yes it is, much easier, much cleaner. As for render times. I would claim that I have noticed a differnce in speed. That is most likely not a result of the object being cleaner but rather a lessened memory usage as a result of having a smaller object loaded. Rendering is cpu and ram intensive so more ram means logically, more speed. On complex scenes with volumetrics, radiosity, reflections, transparencies etc or any combination of those, the difference in render time is negligible if there is any at all. Spanki, I'm not arguing your point that hand editing vn out of an object file creates a corrupted file, just that software today appears to be much more forgiving than it used to be. There was a time when normals were essential in order to load an object into a render application IIRC but that day has passed. Software houses are more familiar with the fact that users will do some pretty weird things and have, in my opinion, made the software more robust as a result. Anyway, I don't disagree with you, and using UVMapper or similar application to remove normals is the better way because it takes the related info out as well. But it's not, how can I put it without you screaming at your monitor? LOL It's not absolutely essential anymore. It's just better practice and cleaner, resulting in more logical object files. :)

Scott. If you are using UVMapper, and have saved an object file without normals. Then, on importing that into poser noticed that the "normals are reversed" you can import that object back into uvmapper, select the reversed areas and flip the vertices. Then save the object as usual, with export normals unchecked and it will recreate the object with the relevant parts showing correctly. Removing the normals from an object does not preclude you being able to edit the object again to reverse parts that are showing as "hollow".

"Software houses are more familiar with the fact that users will do some pretty weird things and have, in my opinion, made the software more robust as a result..." True, but not all .obj loading programs are the multi-hundred/thousand dollar applications you mentioned ;). I have several commercial, shareware and freeware modellers/converters on my system that may not be quite so robust. I'm not pointing any fingers (and some of these may handle this particular glitch fine), but am speaking about apps like 3D Canvas, Milkshape 3D, Wings3D, Anim8or, etc. I still stand by my (admitedly anal) position that if you're going to hack data files, you should attempt not to corrupt them in the process ;). It's one thing if you don't plan to distribute your files, but future users of your products may not be using those high-dollar apps. Then again, that's just my opinion - I could be right ;).

"As for render times. I would claim that I have noticed a differnce in speed. That is most likely not a result of the object being cleaner but rather a lessened memory usage as a result of having a smaller object loaded. Rendering is cpu and ram intensive so more ram means logically, more speed" I'm not convinced ;)... I could be wrong on this, but that just doesn't make any sense to me. Poser creates it's own normals - at some point in the rendering process. It apparently does this prior to renders in the Preview window (which makes sense). Since it completely ignores any normals that may exist in the file, there would be no reason for it to load them, and if it did, then there would also be no reason to store them 'seperately' from the ones it creates anyway (ie. it would likely overwrite the ones loaded with the ones it generated). It might actually load the entire text file into memory the first time that it loads a model, but it creates a binary .rsr representation of the model which it uses for every time after that (and I assume that it frees the text file data). The .rsr file either contains normal vertices or not, but I doubt that that depends on whether the original file had them (I guess I could do a test to find out), and even if it does, as I mentioned, there's no reason for the program to create a 'seperate' memory storage area for the file-based normals, since it never writes those back out or uses them in rendering. When you load an .obj file and make a prop (.pp2) out of it, the normal data is stripped anyway. So it's just not there anymore. Either way, having normals in the .obj file would have zero bearing on memory footprint of the loaded object.

You guys have really massacred this thread. ;-) My favorite part was when Questor gave me UVmapper tips. :-) ScottA

You said that you were curious - I assumed that you wanted information... I thought we were providing that shrug. Anyway, to answer your original question, I guess the answer is a few reasons... 1. as Maclean eluded to - most people don't know what normals are, or that Poser doesn't need them or how to (correctly/safely) get rid of them. 2. other apps use them. 3. aside from the un-compressed disk file size, it doesn't always buy you that much (and even then a large flat plane with hundreds of vertices may only have ONE (shared) normal, so it's not always a 1-to-1 ratio). ...#2 can be solved by simply exporting the model from Poser to get the normals, although there are some cases where you might have supplied non-standard normals (normals tuned to affect the appearance of the model in some way). Cheers, - Keith

Just for the record, in most cases (assuming I haven't forgotten or had some reason to leave them), I remove normals from the .obj files in my products. surprised? ;)

OK, the thread isn't the only thing which has been massacred. We have Jim's lime green horse of a different color. :shudder: In my files is a blue Cinderella dress and a wig with braids, all inside out and all silly-looking when added to Posette. (There are other such files, but those sprang immediately to mind.) I knew that there was something about normals, and put them to the side in the "deal with later" memory stack. Let's deal with them now. To fix the dress, I should export it from Poser with no normals, import it in UVMapper and fix normals? Export it again? Can one of you lay this out step-by-step for me? Thanks! Carolly

Steve, I'm not sure that I follow you completely, but here's the deal... Poser does not use the Normal vertex lines from the .obj file (the lines that start with 'vn '). Instead, it calculates the normals. The way that it calculates them is based on the ordering of the vertices that make up the polygon... This ordering information is stored in the .obj file in the facet lines (the ones that start with 'f '). There are multiple formats for the facet lines, so you might see any of the following: f v v v ... f v/t v/t v/t ... f v//n v//n v//n ... f v/t/n v/t/n v/t/n v/t/n ... ...where 'v' is an index into the Vertex array, 't' is an index into the Texure (UV) coordinate array and 'n' is an index into the Normal vertex array. Note that if there are no texture coordinates, the center value is left out, but the extra slash remains. So... using the simplest example above where there are no normals and no texture coordinates, here's an example of what a triangle might look like: f 1 2 3 ...so when the software computes the normal for that triangle, it uses the first then second then third vertices in it's calculations. When you 'flip' a polygon (or 'Reverse Winding Order' in UVMapper export options), you are re-arranging the vertex order so it then looks like this: f 3 2 1 ...now the normal computation comes out opposite, so the polygon is 'facing' the opposite direction. Note that this is true whether or not there are Normals present in the .obj file, since Poser ignores those and computes it's own normals, based on the vertex ordering. So, if your entire mesh looks inside out, you can either export it with UVMapper with the 'Reverse Winding Order' box selected, or you can import it into Poser with the 'Reverse Normals' option checked and then re-save it. If you just have some polygons facing the wrong way, then you'll need to select and flip them using some feature of your modeling program... OR, you can try importing it into Poser with the 'Make Normals Consistent' option checked - but that doesn't always work. Does that make sense? - Keith

CR2Edit has been removing normals for some four years now, with nary a report of an app complaining -- which doesn't mean that none do, only that nobody has bothered to tell me if one does. "- Just deleting all the 'vn' lines is NOT a valid thing to do... those lines are also referenced by the 'f' (facet) lines... if you are going to delete the normals (correctly), you need to remove those references as well." (Spanki) CR2Edit does remove those references, and version6 will also fix files that people have hacked in a text editor (obviously they don't also remove those refs, even if they know enough to do so) It will also correctly compress morph target OBJ's, which is of course much simpler. "[sorry, it's just a sore spot for me, after fighting through countless special-case coding to handle corrupted .obj files]" (Spanki) I'm with you all the way here, LOL! People who open data files in a text editor are the bane of my existence. I shudder every time I see another 5 page tutorial on how to hack a Poser file to do something-or-another than can be safely done in seconds in CR2Edit, because I know that someone somewhere -- usually MANY "someones" -- is going to slip up and I will get an irate message that CR2Edit can't handle a certain file. And then there are the tutorials that are incomplete or just plain wrong. There are a number of tools in CR2Edit6 that are dedicated to fixing text-edited files, and improper files created by some other utilities. (And even by some elderly versions of CR2Edit, we learn something new every day) regards, Dan http://www.zenwareonline.com for CR2Edit, ZenPaint, ZenTile, VueMaster and the complete line of Zenware graphics apps

Hey Keith, that does make sense, thanks! It also explains how Max (which does use normals, I assume) can get out of synch with Pose, one thinks it is O.K., the other thinks it is inside-out.