Well, I've done a few tests, but there's no difference whatsoever in render times. They're identical to the very second. I just tried it with a fairly large obj - 19 groups and 30 materials, but both renders were the same. Anton? What kind of models are you using - human or non-human? I ask because I'm using furniture models, not human figures. mac

SOme people don't have this issue with firefly. Also not all obj files are fragmented. I purpsoely framented a few different types. I also downloaded a few freebies and tested those as well.

It can be a figure or a prop or an imported obj. Basically it is just about some people having a hang on the firefly calculation that reads the materials from the mesh on rendering.

This particular issue has a very specific symptom being a long hang on the "adding objects" status bar. using a script or utility for defragmenting the obj g/usemtle lines is really just another thing people should do during content creation, like adding a white backdrop to a texture, etc. It just gets added to the list of things to check for when building a product.

Message edited on: 04/24/2005 18:08

Is this what causes Firefly to hang on certain geometries (LisaB's cherry trees, Neftis' hair, etc.)?

could well be... can you run STOMP on them LD?

I would guess that it is a strong possibility if the hang is during "adding objects". Fragmenting of this nature isn't a sign of a bad product, or sloppy work. It is a normal result from remapping/regrouping etc. But if the above hang occurs as described, I would recommend doing what was described above to see if the iissue goes away. If it does then you know that this is something "Your" system has issue with. Other people may see no problem at all. If you can solve the issue, contact your favorite merchants and suggest they see this thread.

Just as an aside, I hadn't checked back on this recently, but "Silo" is is/was writing out rediculously bad .obj files. I think in the one I looked at, it had the above problem (lots of interspersed #usemtl lines) as well as 'v' (vertex) records for every point of every polygon (typically, 3 or more polygons share any one vertex - that's the reason for the lookup table). Of course this was a few month ago - hopefully they've improved things since then.

ahh.. here's an example of what I was talking about...

~~ snip ~~
...
f 1/9 47/10 49/11 8/12
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 10/13 117/14 115/15 4/16
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 192/17 200/18 12/19 11/20
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 79/21 80/22 82/23 81/24
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 224/25 230/26 167/27 17/28
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 134/29 140/30 22/31 21/32
...
~~ snip ~~

...in this case, it's texture coordinates (and it goes on like that for several megabytes of file). Note that ALL of those "vt 0 0" lines could be replaced by ONE line, and then all the indices in the 'f' records point to that one line ('Compact Texture Indices' in STOMP does just that).

Message edited on: 04/24/2005 18:32

anton, You're probably right about this being particular to some meshes and not others. I've never had any hangs with 'adding objects' on my own products. Not that they're better than others, but I don't regroup them often. All I do is occasionally shift verts to another material. Anyway, I agree it's something that content creators should do to make things smoother for the end user. mac

Yeah. But it is aslo particular, it seems, to some systems. Some people have no hang, even with fragmented obj's. Not sure why.

EK, check you IMs.

My guess is that if some people's systems are sensitive to this particular ussue, some related Material room render problems will go away too with those fragmented obj's

The obj can be imported, figure, prop, hair, etc. Importing just the obj and hitting render will test it. You don't have to load a figure. It might be nice thing if maybe Poser had a option similar to SPanki's on import/export.

Message edited on: 04/24/2005 18:51

Just to clarify (a link to this thread was posted in one about hanging renders) the hang doesn't occur with any one specific object, but when a large number are together, or ones with a large number of polygons, at least that's my take. I don't think this thread is the answer.

Your mistaken. No it can be just one object. It is not unique to multiples or large polygon objects. I would venture to guess that mustiple figures with more reduntdant tags would jsut compound the issue.

I just did a test with the original MilDragon obj.

MilDragon

original obj fie size 7.70megs ---------------"adding objects" hang: 11sec
obj fie size after using Stomp 7.35megs ---------------"adding objects" hang: 1sec

Message edited on: 04/24/2005 19:38

I think we're talking about two different things. When I say "hang" I mean the render never continues. Since you have a time there, I'm guessing the render keeps going.

Message edited on: 04/24/2005 19:50

Yeah that is likely a different issue for you.

I just tried Spankis app with 'Urban sprawl'which has 71 material zones..there was no increase at all at render or adding objects time..though the obj did come down in size slightly. Should one expect improved render times on every obj given this process?

No, I wouldn't expect EVERY file to have such a significant speedup. The problem is in the way the OBJ's have been saved by some applications. If the OBJ is "well formed" (for Poser) one would expect no speedup whatsoever!

One would expect it if their system was sensitive to this issue. As it says above, not everyone will encounter this issue.
It won't inmpove render times, aside from reducing the wait from "adding objects" which is also mentioned above. :)

If your system is sensitive to this issue, then all objs will take less time to get to the actual "rendering" status bar, if they are "de-fragmented". Though not related to actual rendering, you would get your render faster.

For example, I got my MilDragon render 10 seconds faster(see above). If there were multiple obj, props, clothing etc in your scebe, and your system is sensitive to this issue, it could shave minutes off your wait. Fragmented obj's are usually ones that have undergone repeated grouping changes and material assignment.

Message edited on: 04/24/2005 20:04

.

can you run STOMP on them LD?

Just tested it on one of the cherry trees, and it worked nicely. And it has the added benefit of not mucking with the vertex order, which means I can use it without worrying about what it'd do to morphs.

Cool.

Firefly renders LisaB Cherry Trees fine for me, and my PC system sure is old and clunky....

LittleDragon, Out of curiosity, what are your system hardware specs?

Athlon XP 2000+
1GB of DDR memory
A7N8X motherboard (nForce2)
GeForce FX 5700LE (128MB)
WinXP Home Edition
Latest builds of Posers 5-6

Actually this is not a new issue.. This is actually something left over from p5 if you remember the problem with Neftis hair and someone discovered if you regrouped it it worked fine. check out the OBJ it's fragmented. This can be seen in a lot of OBJ's. I actually figured it out with Will Dupree about a month or so ago. if you regroup the object it solves the problem. however regrouping it can also cause other problems. So.. P6 is actually showing it more but it's not a new issue

Thanks for the utility Spanki! I'm going to have to try this out with Aiko, there was a lot of hang when test rendering some morphs I was working on. Good idea to keep a back up of the original though, some updates and add on products will look for the .obj to confirm you own it - if the file has been modified, it might not be recognised. I'm still a complete novice with regards to modelling and mapping, could someone explain what the regions are before I let them go. Thanks!

yeah Storm, both versions use firefly.

Philebus,
regions are something UV mapper uses to help mapping layout. Most users/customers don't need them. They are really most useful to the creator. You can just save a backup.

Message edited on: 04/25/2005 01:59

I don't understand why this will make a difference in rendering time, it doesn't make sense, the only difference will be the time for loading the character. What I know is that transparencies render very slow in Poser.

Philebus (and others), yer welcome ;).

...and good point about keeping the original models around, un-altered. Any of the PFE-style encoded packages rely on finding the original files intact.
Anton explained some about UV-Mapper regions... most .obj file won't have them anyway. In case you're curious, here's an attempt at explaining what they are... UV-Mapper regions are something that (AFAIK) Steve Cox (the author of the UV-Mapper program) created. It's basically a modified 'comment' record within the .obj file that is yet another way of categorizing polygons as belonging to one label or another. Other categories are 'groups' (head, neck, chest, abdomen, etc.) and 'material zones' (SkinBody, SkinHead, Lips, Iris, etc.). Now, suppose you are UV-Mapping a humanoid figure like V2 or V3. ALL of the UV coordinate values fall between 0.0 and 1.0 (there are some exceptions to this for tiling textures). If you load V3 into UV-Mapper, you'll see one big blob of vertces/wireframe. But when you look at textures for V3, you'll notice that the head uses a separate texture file from the body (as do the eyes and teeth and some other parts). So, if you're going to do some changes on the body mapping, you'd typically hide everything, then selectively unhide material groupings like the SkkinTorso, SkinHip, SkinForearm, SkinHand, SkinLeg, etc., etc. until you had all of the materials that made up the 'body' texture map. To keep from having to do this every time you want to make some changes (or just write out a UV-map template), you can assign all of those material groups to a 'Body' region. Then do likewise for a 'Head' region, etc. Once you have some regions set up, you can then hide/unhide entire groups of materials (regions) with one action. The idea is that 'regions' can span or encompass or contain more than one 'group' or 'material' and provide a 3rd (handy) way to easily access groups of polygons.

kawecki, I think that's what Anton is saying... but he includes the 'loading objects' phase in the total rendering time. He's basically saying, from the time you hit the render button until the render is done (or starts, in this case) is faster on his system with unfragmented .obj files.

But you hit the render button once the object is loaded and posed. When you start the rendering the model has been loaded into the memory with all translations, rotations, morphs, deformers applied and all the textures loaded into memory. Unless Poser does the stupid actitude at the beginning of the render of doing all the job again loading from the disk.

Yes, you'd think so. I guess we'd have to get the answer of exactly what it's doing from CL, but it sure seems to be at least 'processing' the loaded data, if not loading it all over again. The step/phase where Anton is seeing the improvement is in the "Adding Objects.." state. I suspect this has something (everything) to do with the render engine being separate from the display engine. BTW, just for the record... I ran V3 through the process... reduced the filesize by about 300k. I timed several renderings and got mixed results on my system (P4, 2ghz, 1gig memory), but there did seem to be a 5-10 second overall decrease in total render times. I suspect that 'your mileage may vary', depending on the particular model(s) in question and your system particulars.

kawecki,

When I say "loading objects", I am not refering to the physical act of you clicking from the library. I am refering to the status bar, using that phrase, that appears just before your rendering status bar.

What you are saying by "loading" is not what I was saying by "Loading objects".

Anton

In regards to memory and materials. That "adding objects" status bar is refering to the UVmaterials. It might as well say "i'm busy calculating where all the UV materials are." It would seem that calculation, or something similar is done at rendertime, and not full stored in memory, else there would be no "adding objects" status bar. I had asked CL what the "adding objects" status bar is calculating. The gentleman I spoke to said he wasn't 100% sure but knew it had to do with the UV/materials.

Message edited on: 04/25/2005 03:25

impressive bit of detective work folks. Thanks id'ing the problem and sharing a solution!

Thank you Anton and Spanki! I can now use my favourite Bombshell hair in Firefly without problems! Hardly surprising that there were problems, when you look at the OBJ files. Both the Neftis Mihai Hair (Nef_MihaiHair.OBJ) and the Bombshell hair (BombshellV3_Long.obj) appear to be fragmented in places on a 'line by line' basis. I'm so happy now, and grateful to you both for allowing me to use the Bombshell again without problems!!!

Well I'm glad at least one person liked that hairstyle. I thought it was neat. Daio did beautiful portraits with it. lol. It was meant to be shadowed.

Yeah, I remember the bombshell hair discussion, and thought it was odd since there was nothing wrong with it technically. Obviously this was the issue. Gratz!

Message edited on: 04/25/2005 05:57

It's working brill thus far Anton - even when I've tried to render with Texture Filtering enabled. One other thought occurs... might it also be possible that the issue you identify has some further connections with the (sometimes 'eternal') time it takes to load textures when Texture Filtering is enabled? Or is that something completely different?

"I know the number of people who might care about this are few but.." ...but there are 90 replies. :) Yes, I know they're mostly from the same people... I'd noticed this myself while nosing around in OBJ files, but never thought about it as a performance problem. Thanks to all involved. I notice that John Wind's Compose utility, which I use a lot, orders groups when saving to OBJ, so that doesn't really help any. Looks like STOMP is going to be a part of my workflow from now on!

I dunno, it could have many cross-over efefcts on anything connected to Poser reading the uv/materials at rendertime. It solved a couple problems I have with bump maps. The ones who would know best are those who wired firefly into Poser. I am curious about this obj/firefly relationship though and if it could extend outside of Poser at all. That's just thinking out loud though. Best way is to test something that always gave you trouble. I would excourage people to post that problems this does seem to fix though. Like I said, CL knows about this thread. Maybe they can get a fix into the service release if we can get them enough info.

EnglishBob wrote- "Looks like STOMP is going to be a part of my workflow." Yeah I am going to send Spanki a gift certificate this week. :)

Thanks for the explanations, I don't think I'm going to worry about the regions. I shall test Aiko again tonight (just at lunch now!).

is there a version of STOMP for us Mac users, or are we left out in the cold again? Tthe answer to this might be an argument for a Python script (that doesn't use TkInter). thanks!

hrm...this was mentioned by BLbarret when P5 came out but was lost in the P5 sucks threads. Spanki can I host this utility for you? I'll add a FAQ entry for it too.

"is there a version of STOMP for us Mac users, or are we left out in the cold again?" Keep that winter coat handy. I'm afraid there is no version of it for Macs. I hadn't done any python programming yet, so I'm not sure when/why Tkinter is used, but someone may come up with a Python soloution.

Tirjasdyn, let me think about that for a bit... it was/is not yet intended for mass distribution (it still has a 3 year-old (invalid) e-mail address in the readme for example). Maybe for the time-being, you can point people to this thread, so they at least get the other related info.

No prob Spanky, Let me know.

.