I know the number of people who might care about this are few but.. When Firefly renders you get a "adding objects" status bar. I was curious why some figures render faster than others regardless of their polygon count. Well I took the slowest ones and reduced their obj to one material and they rendered super quick. So "adding objects" is a material zone calculation. But the question still existed as to why some rendered slower. Then I opened the obj file and found the difference. Some obj files have hundreds of fragmented g/usemtl strewn throught the obj file instead of groupped neatly together. g lHand usemtl SkinHands f 17250/35129 20780/18660 32811/35130 32810/35131 g lForeArm usemtl SkinBody f 32811/35130 32812/35132 32654/25808 32650/25807 g lHand usemtl SkinHands f 20780/18660 17249/35133 32812/35132 32811/35130 g lForeArm usemtl SkinBody f 32812/35132 32813/35134 32655/25805 32654/25808 g lHand usemtl SkinHands f 17249/35133 20777/18658 32813/35134 32812/35132 g lForeArm usemtl SkinBody f 32813/35134 32814/35135 32656/18657 32655/25805 g lHand usemtl SkinHands f 20777/18658 17248/25803 32814/35135 32813/35134 ----------------------------------------------------------- It should more simply say: g lHand usemtl SkinHands f 17250/35129 20780/18660 32811/35130 32810/35131 f 20780/18660 17249/35133 32812/35132 32811/35130 f 17249/35133 20777/18658 32813/35134 32812/35132 f 20777/18658 17248/25803 32814/35135 32813/35134 g lForeArm usemtl SkinBody f 32811/35130 32812/35132 32654/25808 32650/25807 f 32812/35132 32813/35134 32655/25805 32654/25808 f 32813/35134 32814/35135 32656/18657 32655/25805 This can be easily caused my remapping/regrouping, etc etc. A python utility or something for this would be awesome.

Something like this should be 1) standard procedure and 2) simple to fix. Unlike vertices/uvs/normals, the order of polygons is inconsequential - as long as they are grouped properly and follow their 'usemtl' material assignments shouldn't matter how you jumble them. I'll have to check, but maybe UVMapper fixes this automatically. That would be slow for all geometries, but at least an immediate solution if it does.

I think the number of people who should care about this should be more :) Anything to speed up render times! Thanks Anton!

A utility to do this would be great. By hand would take forever. I wonder how many figures are like that in my runtime. LOL.

I actually think UV mapper is one of the programs that throws references all around by the nature of selection and assignment.

PS: Anyone know how a .obZ is created. I don't beleive you can just click compression. I wanted to see if that cleanups up the obj.

Well, correct Anton, UVMapper doesn't fix this. Deep Exploration does, but in the process it reorders the vertices. It puts each related vertex set together with its facets under the group, but this is no good. The process would be simple enough: Collect all unique groups (g blah) and then move duplicate groups under the first, minding material assignments (usemtl) - which can extend beyond groups. Then do the same for material assignments for each group.

Right. It would have to first move everything reducing redundant goup tags and then, within each group, consolidate the mataerials.

Message edited on: 04/24/2005 15:36

Good sleuthing, anton! Yes, you're right. UV Mapper doesn't fix this. I've noticed this a lot because when I have a figure with more than say, 10 or 15 materials, I prefer to have them in a set order, so the user can access them more easily in Surface Materials. (I do this by adding a blank body part which contains the materials in the order I want them). Anyway, as I said, I've noticed this when I'm rooting around in obj files and it annoys me, but I don't know the solution. If someone could write an app to correct this, I'd use it a lot. mac PS I'll drop a mention of this at steve cox's forum. He's stil upgrading UVM Pro, and this might be something he could include. mac

Attached Link: "STOMP"" target="_blank">"STOMP"

btw, S.T.O.M.P stands for "Spanki's Three-d .Obj Manipulation Program" (or something like that.. I just liked the name ;).

Also. I wrote this before I wrote my "Riptide" C4D import/export plugin (wich has the same export features)... the plugin is a bit more robust than STOMP, if you have C4D (7.3 or later) you can also do this conversion using my plugin.

I posted this a feature request to steve cox, but of course, that would only be good for content creators with a later version of UVM Pro. If someone wrote an app, it could be used by anyone. mac

Good work, Anton! Will start working on a Python utility for this now. After all, in essence all that is needed is some string manipulation - so it shouldn't be too hard! EK

Oh, one more thing... I usually sort 'By Group' and that will clean things up even more (if I recall correctly, I save out the facets by group, but by material within the groups). It might leave a few extra #usemtl lines than doing it by material, but it's a trade-off of more #g lines or more #usemtl lines. Using 'By Group' puts all the group polygons (that belong to the chest, neck, head, etc groups) in the same chunk in the file.

Spanki what program is that for?

So save out by Material first, then reload and save by group?

Thanks for that, spanki! I just d/ld it and tried it out. It works fine, although I'm wondering if anything else in the obj is changed. I'm sure you'll understand what I mean. I have a horror of putting an obj through all sorts of different apps just to correct minor details. Is there anything I should be worried about? (Off to scour the readme now). mac

Is that the latest UV mapper?

Anton, Try it both ways (by group and by material) - see which works best. Mac, I initially wrote the program to generate 'smoothed' normals between disconnected body parts (to keep seams from showing up in other apps). That function is still there, but the features expanded to allow me to fix other problems with .obj files produced by other apps ;). The only caveat is... I wrote this thing back in 2002 and I hadn't looked much at the code since then, so it may be slow in some areas, or may just crash on some files (?). There is a spec for the .obj file format available, but it is apparently open to a lot of interpretation (based on some of the .obj file output I've seen), so my program may choke on some files, from some programs. My Riptide plugin for C4D re-uses a lot of that code, but I did clean it up and bullet-proof it more - which is why I mentioned that it was more robust. As far as whether anything else gets changed... no, nothing of concequence (the comments change, uv-mapper regions are lost (but retained in the plugin version) but the vertex orders are not changed or anything like that). You CAN change some other things using the program, like consolodating UV vertices, flipping (mirroring) the model, etc.

Anton, sorry, I missed your other question... it's a stand-alone PC program I wrote about 3 years ago (see post and link at message #10, above).

Thanks. I missed that myself.

Very cool utility Spanki! Thanks much!

Who's that Man!. Spanki's the Man! That's who the man! It fixed the problem. The test fragmented Obj's Render supper fast now. Previous test render time:1 Minute New test Render Time: 5 Seconds Ah such a good day. I love it when the community works together. Sending thread link to CL.

Woot! Cool beans. I'll have to crunch some of those files myself.

Previous test render time:1 Minute New test Render Time: 5 Seconds Out of curiosity, what was the size of the OBJ file?

'uv-mapper regions are lost' Ah, that's a pity. I tend to leave regions in for those few people who like to mess with mapping. On the other hand, there are far more people who'd prefer faster renders, so I may just forget the minority on this one. LOL. Thanks again, spanki. mac

Could this be one reason P6 is reputedly slower than P5 to render? They both add objects, but maybe there's a difference in how an obj file is read by them. mac

Not everyone encounters this problem. But if I did, someone else might too. I tested several obj's. File size didn't matter. The one I tested that I mentioned was 4.5 megs. Render was without textured and unshadowed. Point being, see how long the hang up was?

Spanki. I saved by group first, then reloaded and saved my material. It trimmed 350K off the obj I was testing. lol Thants alot of g/usemtl lines. :)

Thank you both for the information and the utility!

Yup ;) You don't have to save by group first though... only if you want to try the file that way. You can save by group OR by material.. whichever works best.

I saved by material on an obj at 1.05Mb with 5 materials. It came out at 1.02Mb. mac PS Unfortunately, I use 3d max, not Cinema 4D

What about the g line span.. Will saving as material reduce that alone?

It kin of depends on the layout and makeup of the model.. here's an extract from the readme file for my plugin... "...just as background, it doesn't adversely affect anything to change the 'order' facets are listed in the .obj file (unlike vertex ordering, which can redefine things to the extent that may break things like morph files). There are a couple of reasons that you might want to sort them differently, and most of them have to do with aesthetics (.obj files are human-readable ASCII text files) or file-size, but may also be relevant for application implementers who prefer a particular ordering. When you start adding group and material information to a .obj file, anytime a facet (polygon) belongs to a different group, material or region, you have to write out a new record before the facet record. So you can imagine that if you have a humanoid model with 50+ groups and a dozen or so materials, if you just start writing out facets based on the order they may have been created in C4D, you might constantly be writing out a new group or material record every few lines as the list meanders around through the mesh. Generally, you can produce a smaller (and more human-readable) file by sorting them by Group (if there's more groups than materials) or by Material (if there's more materials than groups). Just as an aside, you can still sort by Group, Material or Region, even if you're not exporting that particular record type (though it may or may not ultimately be non-meaningful to do so ;)."

So... in general, in something with more groups than materials, sort by group. In something with more materials than groups, sort by material. ....having said that, Poser might 'awlways' load it faster if sorted by material (for example), even though the file may be smaller if sorted by group. I hadn't tested any of this, just trying to shed light on the differences.

Hmmm... resaving the obj from uv mapper retains the new grouped usemtl lines, but puts the file size back up to 1.05Mb. I think what I might end up doing is to save the obj from STOMP first, then do the mapping afterwards. That way, I get grouped material lines AND uv mapper regions. mac

Mac, I was going to suggest that, but forgot ;). A few things can affect th filesize... adding Normals will definately increase it, but also there may be some difference in the number of digits used to specify vertex values.

The only difference is in the TVerts number. The 2nd one shown was put through STOMP. (9461 instead of 9472) # NumVerts/NumTVerts/NumVNormals/NumFacets 10946/9472/0/12852 # NumVerts/NumTVerts/NumVNormals/NumFacets 10946/9461/0/12852 Er... would Tverts be Triangular? mac

I'm currently comparing the 2 files side by side and I can't see any difference in # of digits. And I never save normals. Now, this model (a nikon camera) has no groups and was saved from 3ds format converted to obj, which is why it's triangulated. mac

OK. I've discovered that practically every obj has TVerts, so triangulation has nothing to do with it. mac

Anyone know how to generate a obz?

'Anyone know how to generate a obz?' Can you just zip it and change the file extension? Maybe it won't work in reverse, but I know you can open them with Winzip. mac

I just figured it out. T = textures. mac

NumTVerts is the number of texture vertices (UV coordinates). Note that the file can have duplicate TVerts (particularly after a uv-mapping session). There's a function in STOMP to 'Compact Texture Indices' which will get rid of any duplicates, but I'm not sure why that changed if you didn't use that feature... EXCEPT that, if there were 'unused' TVerts, my program might throw them out on exporting (it builds tables of everything it needs and then refers to those tables when exporting, so if something in the file was not actually referenced, it would likely be thrown out).

It is actually in GZip format. There are several free utilities out there that can compress to GZip (WinZip can only open it, not save to it).

hmm. I dunno if it is that easy. I would rather know how they did it for the Poser6 content. There might be conflicts otherwise.

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=2226454#2

Actually - it IS that easy :) The OBZ & contained OBJ file must have the same filename (not regarding the extension). Poser 6 does it internally by saving directly into the compressed GZip format. I have done a few experiments myself to confirm this shrug