.

Re message #1 in this thread :: read and write the .OBJ file with my utility MAKEOBJ. That will consolidate the groups and materials.

bookmark

So, is it better to use MAKEOBJ first then Stomp it? Will there be an updated version of Stomp now that there is some interest? Funny how useful little programs like this can get lost in the shuffle and forgotten due to another dead horse issue of the day.

beryld, Although I hadn't used it, it sounds like Anthony's utility will do the same thing as STOMP, so no need to use both. As for an update - I dunno... been playing around with the code some today though ;).

Awesome thread. Tag.

Spanki if this is helpful CL shared this with me. "the Firefly engine reshuffles its database every time it encountered another batch of polygons that were assigned to an existing material group."

As a note, Wings3D will order items in this manner -- and when an item which has the fragmentation issue in it is loaded into wings (such as, yes, v3 and the mil folk), it will split all those parts up into hundreds (in some cases, thousands) of distinct parts. Forgive me -- I have note read the whole thread, only the first ten or so posts, and would like to note that I've been dealing with this for about three years now, and never realized this connection. Anton -- sharp!

oh, a further note: Utilities such as Autogroup editor will fragment files in this manner.

Autogroup editor Aha ... I use that. Handy piece of software. But now I'll definitely double check things with STOMP (gotta love that name. ROFL)

Autogroup editor, yep, one of my main tools. I wonder if Quick conform and ClothesConverter do the same thing.

Would it be possible to create a batch function for this utility? I'm sure a lot of folks out there would like to clean up their .obj files, but there are just so MANY!

Great idea.

bookmark

Attached Link: http://www.zenwareonline.com/cr2edit/ver6/geomtools.html

sweet

I've seen this problem. I've seen it so bad that the OBJ file get to be 3X the original size, in fact. I never knew what it was, but I strongly suspected it had to do with materials. In Max, at least, materials don't work like Poser materials. When you apply an material to one group (or part) of a multi-part object it actually is one "Max" material for the whole thing, with sub-materials (which are the Poser ones) inside it. Every group gets the same "Max" material, which will then contain Poser materials that (perhaps) aren't actually present in that group. When you attach all the groups into one, and later regroup them, I always suspected Max was adding all these submaterials over and over again, even the unused ones, as when I'm working on a project like Glamorous Jessi the OBJ file gets to huge size, like 30 MB, compared to 9Mb after fixing her (I do try and fix 'em). Other modeling programs might do it too, I suspect, if OBJ isn't their native format. I do know how to fix it though, I'll have to see if MAKEOBJ fixes it also, it might be easier. Incidently, a good test for this would be load it in Poser 4, if the RSR file is much bigger than the OBJ version it is probably fragmented, or has other wastful problems (like too many decimals). Maybe this is why Poser 4 made RSRs? Maybe CL should have kept that in? ;-)

Interesting point about the .rsrs, jim. For my own products, they're usually about 30% smaller, and that seems to be the case for most of the poser stuff and other people's models that I checked. Although, while looking, I did discover a rsr of 19MB for a 960kb obj. LOL. I'm not even sure what the product was, but it must've been corrupt, so I binned it. mac

The ArtemisX suit and other particulars from DAZ caused me the same hang on the "Adding Objects" dialog in both P5 and P6. I could only get the thing to render in the P4 renderer. I ran all the obj files through STOMP...Hallelulah!! It works in Firefly, now. One more save (and a beauty) by the community...

I did discover a rsr of 19MB for a 960kb obj That sort of thing happens when the same faces are in more than one group. In Poser's dialect of .OBJ language, e.g. the line g lForearm Arm Body_ means that the following faces are in group lForearm AND in group Arm AND in group Body_. When the .OBJ file is translated into .RSR mode, the faces involved are duplicated between all the groups that they are in.

"In Poser's dialect of .OBJ language, e.g. the line g lForearm Arm Body_ means that the following faces are in group lForearm AND in group Arm AND in group Body_" Ya know, for years now, I've been interpreting the above type line to mean some form of pseudo sub-group (so most of my programs don't handle this in a Poser-consistent manner, btw). But from some recent work, I see that Poser does seem to allow for polygons to belong to more than one group. I guess I should re-read the .obj file spec again, but I was always under the impression that that wasn't possible. Either way, to handle these files, I'll need to go back and re-work some code paths... . It's interesting that Poser duplicates the polys though... that would seem to me to cause some rendering artifacts (which I can't say that I've noticed).

It is possible - check the "owl3.obj" if you have it. But only in a sense. You are correct that Poser does not allow polygons to belong to more than one group - i.e.: to be in the 'head' group and 'buttox' group simultaneously. ;) That doesn't mean that there can't be a group hierarchy specified in the OBJ file:

g Body Arm Hand Pinky2

Poser does interpret this! I found out the hard way with that damned owl object file while writing my Wavefront OBJ parsing code. And the order doesn't matter. You can have:

g Body Arm Hand Pinky2 (in one place)

and

g Arm Pinky2 Hand Body (in another)

and the grouping is maintained. ETA: I should specify that only one name should be a qualified Pose name. Note that "Body" and "Arm", as mentioned previously, are not valid Poser body parts (internal naming convention).

Message edited on: 05/05/2005 11:44

Ahh, but the way Poser interprets it, is that... g Body f 1 2 3 4 <-- belongs to group 'Body' g Body Arm f 4 5 6 7 <-- belongs to both 'Body' AND 'Arm' groups g Body Arm Hand f 7 8 9 10 <-- belongs to 'Body', 'Arm' AND 'Hand' groups ...in fact, Poser DOES allow a poly to belong to both a 'head' and a 'buttox' group at the same time (logical naming/positions of said groupings aside)... this is a point I was wrong on in the past. You can verify the above using the grouping tool... create a new group, select a poly or two in the head and add them to the group, then select a few in the buttocks and add them to the same group. The polys you put in that group will 'also' still be linked to the head and buttocks groups, as well as being in the new group you created (similar to UV Mapper regions). I might note that this is (going to be) a bear to program for....

...(sorry if this is more than some of you want or need to know ;), but for the techies...), just to clarify the above, Poser seems to be tracking and interpreting which 'total set of groups' a poly belongs to, as opposed to which 'group SUBset' a poly belongs to (as some of the group naming used here might imply).

So... poly X could actually exist within the logical 'head' group (say on the tip of the nose), but might also be part of a 'extremeties' group, which also had polys from the fingers and toes in it (for example).

Where this is used most often, WOULD be more as a subset - ie. a Lip or Jaw group, 'contained within' the Head group, to allow you to attatch magnets to that subset grouping for morphing a smile (for example), but I don't believe it's limited to that.

[Edit...] ...obviously, all of the above is only referring to the actual .obj file and how it's formatted. As mentioned above, for Poser to interpret a 'figure' correctly, so it can bend in the right places, etc., at least some of the grouping information (naming, etc) will need to match information im the .cr2 file.

Message edited on: 05/06/2005 03:29

But doesn't the grouping tool just create a new instance of "custom geometry" and kinda remove the old geometry? Saved cr2s witht he grouping tool always had custom geom where the grouping tool was used.

I'll have to run some tests to answer more completely, but... You CAN us the grouping tool to 'spawn (new) props', so that would create duplicate geometry, or it might (in the case(s) you're reffering to) replace the external .obj file reference with imbedded geometry (ie. custom geom), but what I've seen in the past was an alteration of the base .obj file when I saved my altered figure. Again, I'm speaking from memory on some of this, so I'll look into it further.

I know if you make new materials on a figure cr2 it inbeds new geom in the cr2 replacing the original polygons. I huess that was what I meant.

...Just as an aside, I think we've gotten off-topic a bit from this initial thread/issue (maybe we can start up a new thread in the Poser Tech forum to continue?). Most of this isn't related to the fragmenting issue, but I did want to bring it up so people using my STOMP program would know that they might lose some special grouping information (MOST poser .obj files won't have this type of multi-grouping, though I noticed that some Koz hair props, etc. do and - depending on how the naming is specified/ordered, STOMP may not adversely affect those either).

If a Poser geometry file contains the lines
g Body Arm Hand Pinky2
f 444 555 666 777
, and you output the posed model as .OBJ, in "output as groups" mode, the resulting output file will contain a face in group Body and another identical face in group Arm and another identical face in group Hand and another identical face in group Pinky2.

Message edited on: 05/06/2005 03:57

I'll definately have to look into this more after I get some sleep. Thanks for the info.

I have working on a dynamic dress and made several cloth simulations that were going very fast until I finalized the material zones ( since I wanted the users to turn on/off transparenciy for short, elbow and long sleeves). Once I added those materials to the obj, simulation times went to a complete crawl( even with absolutely no texture maps loaded), so much so that I am going back to a single material for that dress.

...just an update on the 'Silo' front... I just downloaded the latest demo version and while it seems to not create overly fragmented files as it relates to the material records, it does still create terribly bloated .obj files.

The test-case I looked at (less than 5k polygon model) was roughly 30% larger than it needed to be (947k vs 647k), to contain the relevent information needed to store that model. See my posts #58 & #59 above for details.

Message edited on: 05/12/2005 15:41

Sometimes my math leaves me dangling ;)... here's another way to look at it - if the file could be 600k, but ended up 900k, then it was 1 and a half times as big as it needed to be (600 x 1.5 = 900)... so.. 50% bigger? I need more coffee.

I just wanted to say THANK YOU to spanki for STOMP. I have LisaB's vines and it was taking forever for me to get tthrough adding objects before I could even start rendering. Firefly actually died on me twice rendering large. I ran the utility on them and it added the objects in like three seconds. Don't know if the render will still die but at least it doesn't take as long to find out anymore!

Render times... Since I upgraded recently from Win98 to WinXP, without changing the hardware, I've maybe got a feel for one or two details on this. There seem to be two distinct problems with similar symptoms. Both show as very slow, or no, progress at the loading objects stage of the render, which can happen several times if you use shadowmaps. The total halt version (I'd call an overnight run with no results a total halt) seems to have been fixed by the switch to WinXP. I still see very slow processing which may be the fragmented group/material problem, perhaps more often now. Since WinXP uses more RAM for the OS, I'm inclined to think virtual memory is one of the keys. The last instance I hit used DAZ's SP3 and V3; just the two figures each with only one or two INJ morphs loaded. Incidentally, this would be something that would be more likely to show up with a triangulated mesh. Right?

"Incidentally, this would be something that would be more likely to show up with a triangulated mesh. Right?" ...not necessarily, as it really has more to do with which app wrote the .obj file and compounded by how the model was created and/or broken up into material zones, during or after creation and/or wether the mesh was created as all triangles or triangulated later, etc. However, you are correct in the sense that, since a triangulated mesh DOES have twice as many polygons as the same mesh made up from quads, there is certainly more potential for fragmentation.

Yes, I think that was what I was groping for. And more data to shuffle around. I ran yout program over the Aiko3 mesh, and it saved about 380k out of 8400k; maybe not a huge amount but it all helps. The coordinates are given to 8 decimal places, with either a trailing zero or ending 98 or 02. Millionths of an inch, if I have it figured right. I don't think it would make any difference in a close-up, and it might depend on Poser internal data structures, but they used to teach about useless precision at school... Well, my school anyway, but that was a long time ago and in a foreign country, and besides... I did some quick checking, and it doesn't actually make a time difference. One Aiko 3 takes 10 seconds to load objects, two of them take 40 seconds. (Would three take 90 seconds?) Maybe I'm running just inside the limits. Aiko 3 is an awkward figure anyway, since it doesn't use the INJ/REM technology; neither does the Hiro figure. So the .cr2 files get pretty big with all the deltas in them, and they're unimesh figures; it needs just as many deltas as V3/M3. (Checks) A lot of the deltas are in exponent form, which does save a couple of bytes each, but still down to differences of a ten-thousandth of an inch. If these file sizes do matter, there's a lot of scope to trim them back.

Attached Link: http://www.renderosity.com/freestuff.ez?Form.Contrib=ockham&Topsectionid=0

I think I definitely need more RAM... Anyway, in Poser 5 at least, if you want soft-edged shadows you have to use shadowmaps instead of raytraced shadows. And each shadowmap has a preceding "Adding Objexts" phase. The actual rendering stage is faster with shadowmaps, but if you are getting a sluggish "Adding Objects" you can not only make coffee, you can bake the biscuits.

Yeah. Firefly is building a material database during "adding objects"

If there is fragrmenting is rebuids from scratch with each redundantly tagged material.

Like counting M&M's firefly behaves like this:

1 green
2 red
oops another green

2 green
2 red

oops another 3 red

2 green
5 red

oops another green

3 green
5 red

etc etc

Message edited on: 05/15/2005 08:28

.

I downloaded the program but am completely lost. What do I do with it? I get that I "Import" an .obj file, but then what? And what is this about saving? Where do I save it? Do I replace the .obj file in the geometries folder with the new one? I saw something about resaving it with a different name, but wouldn't that cause problems with the rest of the package and it's files?

Attached Link: http://www.byanton.com

Ahhh, that explains it. As per advice from another thread, I saved it to the same folder using the same name but put a number 1 at the end. When I rendered I didn't notice any change in render time at all, so it must have been utilizing the original .obj file and not the processed "stomp" version of it. I'll try again later by removing the original object file and renaming the processed one to that of the original name and see if that improves things. Thanks :) If this speeds up my rendering times, I'll be using it for all of my .obj files because patience isn't exactly one of my virtues. lol

I went back and deleted the files that I saved with a number 1 at the end. I then copied the original object files to another folder outside of the runtime. Using Stomp, I processed the original object files in the folder and replaced them with the new exported one when I saved it. So I started with 4 object files in the folder and ended with 4 object files in the folder, plus the .mtl files that were generated. I opened Poser and the figure was nude. The outfits were listed in the menu but weren't showing up on the figure. I deleted them and reapplied them from the library with the same result. The clothing is listed in the drop down menu, but the figure is nude. Help? lol

Whatversion of Poser are you using?

Sheesh! I got down to post 130, and had to back out of the thread, it was doing my (what is optimisticly called a) brain in! I understand most of what's being discussed, and where and why it matters, and how to fix it the problem. But as I mentally tried to apply the fixes to my own files, I got more and more cross-eyed... (very long bookmark for very long thread..) :-)) Cheers, Diolma

I'm using Poser 5. What I did was as follows: Copy the .obj files from the runtime folder to another folder for safe keeping. 1. Open STOMP 2. File, Import Mesh/obj, Browse to the runtime folder that contains the geometry .obj files that I want to process. 3. File, Export the files back to that runtime geometry folder and use the SAME name as the ones already there... replacing them with the new processed .obj files. Then I open Poser. Load my figure, then add the clothing. The clothing is listed in the drop down menu as being there. But they aren't visible on the figure. If I go to the folder where I saved the original geometry files for safe keeping, and copy them back to the runtime geometry folder, then go into Poser and delete the invisible clothes and reapply them from the library again, the clothing is not only in the drop down menu, but also visible on the figure. It's wierd. I think I did everything as indicated. I export as "material" like in the instruction window above, and all the right boxes are checked according to that instruction screenshot above. But for some reason the clothing and shoes are invisible after running it through STOMP.

• Which clothes and shoes are you running through stomp? - What's the size of the original .obj file(s)? - What's the size of the STOMPed ones?

Attached Link: http://market.renderosity.com/softgood.ez?ViewSoftgood=36619