I've been using Hexagon to make a full body morph for a Poser character. Did a bunch of single group tests before starting. Everything looked good. No scaling issues. No reordering of vertices. Morphs worked fine back in Poser. So I started to work on my little project which requires working with a bunch of groups at the same time. "Tweak" with soft selection doesn't work across groups in Hex even when you've put them all into one group, but that's ok, translate does so I made do with that. After a few hours work I realized that every time I saved it seemed to take quite a while to finish so I checked the file size and discovered that my saved file was more than ten times the size of the original obj. Note that I'm only moving vertices around and not adding any new geometry. Dynamic geometry has been off the whole time. Did several little tests to see if maybe I had a setting wrong and same result, saved file more than ten times bigger than the original. So, just for the heck of it, I opened the original obj and immediately resaved it without doing any modeling at all. File size again was over ten times as big. Grr. Note that this is on a figure with about a dozen groups (I had deleted head, hands and feet). Then I opened each file in UVMapper Pro and the stats for each were identical even though one file was over ten times bigger than the other. Ran Spanki's Stomp utility on the saved file and it made it even bigger. Then I did another test. Opened a similar size obj that had only one group and resaved. This time the saved file was actually about 20 percent smaller. So, the problem at this point 'appears' to only happen with figures with several groups. Anyone know what's going on here? Is there a setting somewhere that I'm overlooking that could be causing it? I'm guessing that upon saving Hex is creating a bunch of redundancies (related to grouping?) that don't show up in file stats. Maybe there's a utility that can clean them up? My little project can't be done in Hexagon if I can't figure this out. Thanks for any help.

Find out from Eovia if Hexagon 2 will fix that problem?

What are your OBJ export option selections?

Sorry. Forgot to answer your question, Shonner. Yes, I'll post a bug report to Eovia tomorrow. Starting to nod off at the keyboard ;)

If you check "Merge equal uvs" it will cut the file size to about a third. Still unacceptable.

Hmmm, if you save as a .car, open it in Carrara and export as .obj with Materials turned off, the file size is pretty close to the original.

Does unchecking 'export normals' make any difference?

Export normals makes no difference. If I import, for example, blMilWom.obj (around 5 meg) into Hex using default settings (uvs and normals checked), and export the file using hex, the file size was 142 meg. If I export with 'Merge equal uvs' checked, the file size is around 38 meg. If I save the hex file as a .car, open in Carrara, then export as .obj with no material, the file size is around 6 meg, which is reasonable. Not good, but reasonable. I haven't had Hex long enough, or had enough time to fool with it very much- but I seem to remember having problems texturing in Carrara if I exported a Hex file as .obj. Seems like I had to save as .car to get it to work right. Hope I'm not rambling here.

...that probably very helpful info in your posts for Eovia to hopefully untangle the problem. Thanks, ValleyMist.

" Hmmm, if you save as a .car, open it in Carrara and export as .obj with Materials turned off, the file size is pretty close to the original." I just tried that work flow for my little project but unfortunately it didn't work. Scaling and orientation problems resulted and the morphs wouldn't load. It's a major problem for me and I'm sure others. Hex is great but there will be a lot of things I can't do with it until this is fixed.

I just imported the blMilWom_v3.obj file from DAZpeople (Free V3/M3 models from DAZ3D) found in my Poser 6 geometries folder which was around 8MB. When I exported back out as OBJ, the file was around 98MB. Maybe Hexagon 1.21 inserts "hum" between each point in the file?

Where exactly do you post bug reports to Eovia anyway?

There's a form on their tech support page.

I imported the 98MB OBJ file back into Hex 1.21 and RAM usage shot way past 1.5GB and fails with Internal Error Ocurred. Carrara got the file under control using only 134MB.

It appears that Hexagon makes models 10 times bigger during import rather than during export. Insane.

You found one helluva bug, Tunesy.

Message edited on: 03/18/2006 17:36

Well. Maya Doll was even worse. Came in over 27 times as big. Who knows what the actual magnitude might depend on. Maybe we should have a contest. First to find a file that saves at 50 times the original gets a free copy of Hex 2 ;)

Add another bug to your list. This one is a carry-over from Amapi 7. Hexagon 1.21 ignores any export options you choose in the dialogue box and uses the settings in your preferences for that filetype's exporting.

For example, unchecking export UV still exports UV.

Let us know if Eovia responds to these.

Message edited on: 03/18/2006 17:55

Considered getting Hex 2.0. So, it's very interesting, how Eovia deals with that problem.

Importing the 98MB file made from Hex 1.21 into Carrara Pro 5.05 and then exporting back out as OBJ brings the file size down to 11MB. But the file is so corrupted and useless. It's like a transporter malfunction occurred.

Might explain some performance issues I was having w/ a project. Both of those are significant.

I have Amapi Pro 7.5 as a stand-in for when Hexagon goes south on objects.

Yeah, well that file size export is a huge one. The options is also important, but the file size must be corrected.Sometimes I don't understand how these big bugs just never get fixed version after version.

I think of it as buying an old '64 Ford Galaxie for $99 in case my original '63 Ford Galaxie gives up the ghost one day.

From a thread over at DAZ "Actually, for creating morph targets it is really good, you are just missing a step. It DOES do what you say, but... if you save the file in Hexagon format first, THEN export out the file as on OBJ it will actually make the file SMALLER ! For example, a 3,518K Toon Dragon OBJ file exported back out WITHOUT saving to HXN format was 23,573K. When I did the same process but saved the file as a HXN file before exporting the OBJ file, it DROPPED the exported OBJ file size to 1,329K."

...very cool. I'll try that right now. Thanks.

Edit: Well. I just tried that and it made no difference. Is there a step missing from your description maybe?

Message edited on: 03/20/2006 20:34 Edit: Aah. Just tried again. This time I save to Hex format, then started a new scene and opened the Hex file and exported to obj much smaller like you said. Now to test with morphs. Thanks so much!

Message edited on: 03/20/2006 20:38

Tried it and for me at least I still get the dramatic increase in file size

Ok tried it again adding your step as well, and it works for me too now! Cool!

Tried two Poser full body morph tests so far. One succeeded partially. The other worked perfectly, but I was using every single group in a pretty heavy model in both tests which I would likely never do in practice. Your workaround will do just fine. Thanks so much rcr62! Edit: ...and the file (TY2) came out 50 percent smaller. Hehehe. Now you got me intrigued with the possibility of lightening up some of my main Poser figures permanently. Lots of tests to do. Thanks again ;)

Message edited on: 03/20/2006 21:02

Thanks goes to BluesDragon over at Daz. But glad I could pass it on.

Well that is helpful. May explain why is wasn't as obvious before. Well, how odd. Still hope it gets fixed. Shonner,didn't get a Ford Galaxie, but did have a dodge dart many yrs ago(in that yr range) that was a very reliable car. :D

...yea. I still need to do more tests, but it looks like they have some nice 'convert to obj' code. Maybe they should squeeze it in to the appropriate menu choices ;)

Did a few more tests. It appears the reason this work around generates smaller obj files is because it strips the UV data from the file, which is no big deal really. I've only done 4 or 5 tests so far all using the same model but when "Import UV's..." in UVMapper Pro was used to reapply the UV's from the original model then the file size reverted to the exact same as the original. So, there's no free lunch on file size but it looks like the work around is pretty sound.

. Glad to be of help :) I must have forgot the reopen the saved HXN file step when I posted. Good catch on that. Cheers, Steve AKA BluesDragon