Hexagon crashing when selecting faces
emfederin_9bc0c524c8
Posts: 0
Hold on a goddamned minute. This site SUCKS when it comes to posting images!!!
The damned page REFUSES to load images in order, and it REFUSES to post images inline with text!!
WORKAROUND: All my images are at the bottom of the page. I'm going to edit my post to point to the proper image which will be out-of-place in the list.
>rant off< My original attempted post continues below:
This would probably better serve as a "bug report", but I'll post it here for general information.
There is a fairly common problem here where Hexagon users have complained of crashing when they try to select faces on their meshes, and takes nothing more than a mouseover to do it.
A user here, Roygee, had that problem with one of his meshes, but was able to "fix" it by sending his model to DS and resaving the mesh from there. Luckily, he kept both the "bad" version of his model along with the "fixed" version, and he was kind enough to share them with me so I could examine them.
The first thing I noticed was that they both had 332 vertices, but the "bad" model only had 320 faces while the "fixed" version had 328.
After a line-by-line comparison I found the difference laid in 4 areas of his meshes, each of which was a 5-sided n-gon in the "bad" mesh, but the same areas had been converted to 3 triangles in the "fixed" version. Each area in the "bad" verison were 5 vertices filled by a single ngon, for a total of 20 vertices and 4 faces. Each area in the "fixed" version were the same 5 vertices filled by 3 triangles for a total of 20 vertices and 12 faces - which is where the difference of 8 faces came from.
Now Hexagon normally has no problems with ngons, so I figured that something else was going on and looked further to find out why Hexagon doesn't like THESE ngons. I believe I've found the answer, and it turns out that only 2 of the 4 ngons were responsible for crashing hex.
The problem isn't ngons; the problem is TWISTED ngons. To complicate matters, you can twist ngons all day long in your models without breaking Hexagon...UNTIL you SAVE them to a file and subsequently try reloading them!
Hexagon preserves the winding order of the "twisted" ngon vertices just fine and imports that data with no problem, but then it goes completely braindead when it tries to FACET the twisted vertices! It screws it up so badly that it crashes when you try to select these faces.
Allow me to demonstrate how to crash Hexagon with a twisted ngon:
Bring up Hexagon and imagine 5 points defining a 5-sided ngon in your workspace.
## See first image
Using the "facet" tool under the "3D Primitives" tab, create an ngon by connecting these points starting at "1", then "2", "3", "4", "5", then "validate", which closes the 5-sided ngon. BTW, to define a previous term I used, "1,2,3,4,5" is this polygon's "winding order".
## See 2nd image
Now let's "twist" it. Grab vertex #5 and drag it down below vertex #4:
## See FOURTH image
Note that we have no evident problems yet. You can still select its face and it acts like any other poly in the pack. If this were part of a larger model, you may not even be aware that some operation had twisted an ngon, and you might go off working on other areas before calling it for the night and saving your model.
So let's go ahead and do that now, and save our little single-faced model as "bozo.obj".
Come morning, and we're all set to do more work on bozo. So now go ahead and open "bozo.obj" back into Hexagon again:
## See THIRD image
With this single ngon, the difference in face configuration between what we saved and what we re-opened is glaring. But if it were part of a larger model, it may not be noticed at all among the crowd of polygons. In Roygee's model, these faces were even partially hidden behind other polys.
But the damage is done. One twisted ngon affects the entire mesh group, and when you select "face mode" and mouse over the affected goup, you're greeted with:
## See 5th image
So that appears to be the problem. Unfortunately, I have no better solution than Roygee's solution of sending a broken mesh to DS and resaving, which apparently automatically triangulates any polys larger than quads.
BTW, just to add insult to injury, Hexagon also crashes if you try to triangulate the above broken mesh. Go figure... :-)
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
The image posting is on the list of things to fix. Have you had this problem before or is it just starting now. What are your system specs and which version of Hex are you using?
Actually, I've never had the problem at all. This is what I found regarding someone else's problem, and then discovered I could easily duplicate the problem.
FWIW, my system is XP pro x86 running 2.5.1.79.
Stand by, I'm still trying to get some kind of inline imaging going on my first post...
Okay, I'm finished posting this nightmare. I hope you can all follow it with no problem.
Just for the record, this has nothing to do with how Hex saves the .obj.
http://www.4shared.com/zip/XN7B0Tah/knot.html
The same "twisted" n-gon made in XSI also crashes Hex when imported. I suspect it would be the same for any .obj imported regardless of where it was made.It looks to me that Studio adds an edge where one doesn't exist is why the export from it fixes it.
That's correct. It's not the object that's at fault; it's hexagon's inability to facet a twisted ngon correctly on import that's at fault. In fact, Roygee also sent me HXN files of his meshes, and the HXN with the twisted ngon crashed Hexagon as well.
2 edges. But yes; it does this by triangulating the 5-sided ngon into 3 tris as I pointed out above in detail.
Didn't download your file. The site requires registration to download.
If you're talking about the 4th image, that's a quad and a tri. The edge going from points 4 and 1 is the one that doesn't really exist and the one going from 5 and 1 simply overlaps the one from 3 and 4. There is no vertex there I can see.
I'm a simple minded person tho so maybe if you give the 3 tris their own shading domain and different colors I'll be able to see it?
If you're talking about the 4th image, that's a quad and a tri. The edge going from points 4 and 1 is the one that doesn't really exist and the one going from 5 and 1 simply overlaps the one from 3 and 4. There is no vertex there I can see.
I'm a simple minded person tho so maybe if you give the 3 tris their own shading domain and different colors I'll be able to see it?
No. The 4th Image is NOT a quad and a tri, it's a folded ("twisted") ngon. There are no tris or quads in any of my images. All my images are of a single ngon.
The tris I mentioned are in the FIXED file, not the broken one.
You're right, I was mistaken there, but you threw me off by stating you showed it in detail which I couldn't see so that was all I had to go by.
Irregardless, it doesn't change this:
"To be honest, non-planar geometry like that is bad to start off with and with all the problems Hex has with high poly geometry this isn’t a surprise. "
My thanks to you for going to all the trouble of identifying the problem.http://www.daz3d.com/forums/smileys/#
This has bugged many folk here - now we have a solution and I've found a useful function in Studio.
How this happened is a mystery because I'm pretty fastidious about making good mesh - I can only assume it was one of those occasions where the universal manipulator leaps about and does its own thing when you do a selection too close to it. Being hidden from view it escaped my notice.
From now on I'll check for N-gons before saving.
Personally, I try to avoid ngons like the plague. But this post is just the result of my attempts to track down the cause of a fairly common problem and may even underscore why they should be avoided or at least used sparingly and carefully. I don't know where these ngons may come from when building models, but clearly they exist. The least hexagon should be able to do is to read the ngons it writes. But then again, hexagon can write lines to an object file but can't read them back in either.
Hexagon has its problems, but I still think it's the greatest thing since sliced bread.
BTW, the only way of guaranteeing 100% planar geometry is to use tris exclusively; but I avoid that like the plague, too.
Thanks Roy! And no problem at all! As I mentioned before, tracking stuff like this down is a lot more more fun than doing crossword puzzles, and I enjoyed doing it! :-)
Just one more bug to add to the list of bugs added by DAZ in the latest version. It is bad geometry, but does not crash 2.1 and should not crash any poly-modeler.
Buggy software, buggy forum. At least consistency.
I didn't mean to imply that you or anyone else was making wonkie meshes on purpose. This shouldn't be a problem for Hex to handle and while sending back and forth to Studio seems like a temporary solution it's not an answer any more than triangulating the mesh before saving would be. Personally I don't look for things like that until I get ready call a model done and usually have a few issues of one kind or another at that point to clean up.
I also don't think this is anything that can be fixed without fixing the amount of polygons Hex can handle to begin with.
I repeated the exercise of the 'out of vertex order' polygon and it does crash Hexagon.
It also crashes Lightwave3D 9.6 Layout.
Hexagon will crash if I save the bozo.obj from Modeler 9.6 Lightwave and imported back into Hexagon.
Hexagon will crash if I save the bozo.obj from Carrara and import it back into Hexagon.
(note: Carrara did not crash if I selected the polygon in the model room and try to "fix it.")
Since the vertex order is "out of order" and not all of the n-gon is facing forward like it should, there is a problem and there isn't a way to resolve where normals should be.
You can test this in Carrara. The reverse normals will cause the "dragged down" portion of the n-gon to flip. It doesn't fix the crash problem, but it indicates that bad geometry where unresolved out of vertex order anomalies are bad for most 3D software.
Fixing normals in Hexagon also doesn't resolve the out of vertex order.
Interestingly, performing the same sequence with the Mac version of Hexagon 2.5.1.79, does not produce a crash. It does produce the same malformed facet when the twisted n-gon file is reloaded, however, it can be repaired by moving the previously moved corner back up to near where it was and performing "Merge coplanar facets".
Sweet! I didn't investigate far beyond what I posted, but now I find that this also works on my PC version. The only drawback is that the user would have to be aware of which poly(s) in his model are causing the problem.
Are you using the win32 OSX version or are you using the regular MAC version?
I ask because these functions are entirely mathematical, and the win32 version uses the "microsoft visual C runtime libraries" and I would guess that apple uses their own equivalent.
I'm using the version intended to operate on an Intel Mac running OS X.
As far as I know, there's only one Mac version of Hexagon available now. If you were referring to the older G4/G5 Power PC (PPC) Mac, then, no I'm not running that platform.
To be perfectly honest, I'm not entirely sure which file each of us is referring to. :)
Currently there's a win32 EXE file for PCs, and a ZIP file for macs which has strictly MAC files inside it.
Before the website revamp, there was also a MAC ZIP file, but I never looked to see what was in it. There was also a ZIP file for PCs that had the same EXE file as is available now for downloading a la carte for PCs. But inside that ZIP file was also a “__MACOSX” directory which implied to me that it was also installable on a MAC running OSX.
I detailed my confusion in the "missing serial number" thread with this post here: http://www.daz3d.com/forums/viewreply/7786/
To be perfectly honest, I'm not entirely sure which file each of us is referring to. :)
Currently there's a win32 EXE file for PCs, and a ZIP file for macs which has strictly MAC files inside it.
Before the website revamp, there was also a MAC ZIP file, but I never looked to see what was in it. There was also a ZIP file for PCs that had the same EXE file as is available now for downloading a la carte for PCs. But inside that ZIP file was also a “__MACOSX” directory which implied to me that it was also installable on a MAC running OSX.
I detailed my confusion in the "missing serial number" thread with this post here: http://www.daz3d.com/forums/viewreply/7786/
I participated in the private beta testing of Hexagon, and to the best of my knowledge there is no exe that is capable of running on both platforms.
That mystery Mac txt file you found may have actually been a rich-text file, which will open easily in the Mac's Preview application. I think MS Word will also open rich-text files.
You can run an EXE inside an emulator like WINE, although its efficiency will vary according to chip set and clock speed. Whether that was the intent behind including a "macosx" directory in with an EXE file or not, I may never know. :)
I also saw the "Rch" inside that "mystery mac file" and thought the same thing. I changed the extension to RTF and opened it with an MS Word viewer to no avail; still just gibberish, so it too shall remain a mystery to me... :-)
Still in all though, you pretty much satisfied here what I was asking - the hexagon you're running was installed using a non-EXE version, which means the MAC-specific files. And this in turn also means that your runtime libraries (by whatever name they may be known in the MAC world) are non-microsoft. That could conceivably introduce subtle functional differences which may explain why your MAC version didn't crash as the PC version does.
Ultimately, this could be just a "new bug" introduced in 2.5.1.79 as Steve mentioned, since it doesn't crash his 2.1
Personally, I always check using this or one of the other options.
Heheh...interesting observation, and I find it quite mind-bending to contemplate. I also think it's integral to the problem.
A few definitions for folk who want to follow along:
"Face normals" (which are entirely different animals than "vertex normals") determine which side of a polygon is "visible" to a viewer.
If the normal is facing the viewer, then the poly is visible. If it faces away from the viewer, then the poly is invisible. To see this effect in hexagon, users must make sure that the "hide / show backfaces" in the hexagon tray is set to "hide backfaces".
Moreover, face normals are derived from the winding order of the poly. If the poly vertices are wound counterclockwise (CCW), then the poly's normal is facing the viewer and its face is visible. If the vertices are wound clockwise (CW), then the normal is facing away from the viewer and the poly's face is invisible.
Okay...now I'll try to describe why Acrobat's observation is so interesting:
In my example, the ngon is wound CCW (12345), so it's normal is facing the viewer.
When I drag vertex #5 down below vertex #4, hexagon already knows which side the normal is facing, so it correctly flips it when it becomes inverted - it's like folding a blanket with a red side and a blue side: Turning down one corner of the blanket with the red side up, places the red side down on the folded section and shows the blue side.
With me so far?
Okay, so when we save this poly and open it back up, hexagon tries to facet the vertices using the correct winding order, *BUT* it seems as though hexagon wants to force all the normals to face the viewer, winding order be damned.
This creates a sort of "paradox". Winding the vertices 12345(1) with #5 below #4 means that the facet 1234 is wound CCW so the normal is correctly facing the viewer, but the vertices 345(1) are wound CLOCKWISE, so its normal should be facing AWAY from the viewer - yet hexagon draws the face with its normal facing the viewer anyway.
In terms of our red/blue blanket, if hexagon tried showing us what the folded over blanket should look like, it would think both sections facing the viewer should be red.
This can also be done on the fly. Using my ersatz pattern shown in image #1 above, use the facet tool to draw a facet from vertex 1-2-3-5-4 (instead of the original 1-2-3-4-5). Here again we've drawn part of the ngon CCW, and another part CW - yet hexagon is showing (in essence) a quad and a tri connected at a pseudo-vertex with BOTH faux polys facing the viewer even though the apparent tri should be facing away. Selecting this figure in "face select" mode will also crash hexagon.
Unfortunately, this tome is mere mental masturbation which doesn't solve the problem but only details the problem even further. Ultimately, the solution will lie in the minds of the programmers.
Maybe in version 3... :)
Personally, I always check using this or one of the other options
"Select over-4-points faces"
[slaps forehead]
OUTSTANDING, Red! Thank you! I was actually wondering if hexagon could do that, and I feel rather sheepish now for not having just come out and asked if anyone knew how to do it.
This is certainly an easy and effective procedure that will protect us from this bug completely.
Once identified, any ngons can either be repaired by the user (if the vertices are twisted) or better yet, simply triangulated out of hand to get rid of them completely.
The only warning is that it MUST be applied BEFORE saving a potentially affected model, since using this function on an imported bad ngon will still crash hexagon.
Very good! Thanks again for pointing that out, and I think your contribution pretty much serves as an exclamation point to put at the end of this thread. :)
Those functions at the bottom of the selection menu are what I always refer to as diagnostic - invaluable for identifying potential problems - I run through these periodically while modelling.
This winding order of which you speak - does that mean that if I make a poly, I must always do it CCW? i.e. The user determines the winding order? Secondly, this facing viewer - the viewer is always behind the camera, so regardless of what view I'm in, it is always facing me? What about working in multiple views - which one is the viewer facing - this all gets so confusing
If you draw a poly from points, or create one from a curve for example then it does make a difference as to which way the normals will face. Just like if you create a cube and delete all but 3 sides to make a floor and 2 walls, the normals will point the wrong way. I'm sure Hex has a way of reversing normals like every other app goes but I don't know off hand how to do it. I don't think that's the issue in this case for a couple reasons. The main one being it only seems to happen with 5 sided polygons, it doesn't happen with 4 sided ones anyway.
The winding order for the the one I made in xsi is clearly messed up tho as you can see in this screen shot from houdini:
Essentially, yes. Remember that almost all meshes we work with are "solids"; spheres, cubes, heads, arms, aircraft bodies, gun barrels...you get the drift... :)
And of course, solids all have their normals facing outwards, so they're visible no matter what angle you view them from.
If you split a model in half and look "inside" it, if you have "show backfaces" selected, you'll see all the polys. But if you have "hide backfaces" selected, then all the polys facing away from you will be invisible.
Thanks for the explanations, guys - fascinating stuff. Glad I don't have to bother about winding order - there's enough other stuff to be going on with
Oh crap...EXCEPT IN HEXAGON!!! :-S
I like checking my assertions for accuracy, and when I checked this one - hexagon made a liar out of me.
Turns out that when you draw a quad CCW and then draw a CW quad next to it in the workspace, hexagon instantly rewinds the CW quad so that both normals are facing you. Hexagon obviously assumes that if a user creates a quad, he's creating the face he wants to see. This isn't a bug, it's actually perfectly reasonable and in this case, hexagon does its job at the expense of making me look like an idiot. :lol:
Stand by...another tedious demonstration of this is forthcoming... :)
Okay, I'm back... :)
The image I've posted at the bottom here shows how I created 2 quads in Hexagon. The vertices are numbered in the order that I clicked them, CCW 1234 for Form0, and then CW 5678 to make Form1. Form1 SHOULD have been facing away from me, but hexagon drew both quads facing me. Examining the OBJ file's data reveals what happened:
===== OBJ file as saved by hexagon ===
#Wavefront OBJ file created by Hexagon 2
mtllib untitled_1.mtl
g Form0
usemtl def_surf_mat
# 4
v -0.100995 0.599621 0
v -0.100995 0.549621 0
v -0.0509953 0.549621 0
v -0.0509953 0.599621 0
usemtl def_surf_mat
f 1 2 3 4
g Form1
usemtl def_surf_mat
# 4
v 0.0492445 0.60032 0
v 0.0992445 0.60032 0
v 0.0992445 0.55032 0
v 0.0492445 0.55032 0
usemtl def_surf_mat
f 8 7 6 5
===== same OBJ file stripped of extraneous info ====
g Form0
v -0.100995 0.599621 0
v -0.100995 0.549621 0
v -0.0509953 0.549621 0
v -0.0509953 0.599621 0
f 1 2 3 4
g Form1
v 0.0492445 0.60032 0
v 0.0992445 0.60032 0
v 0.0992445 0.55032 0
v 0.0492445 0.55032 0
f 8 7 6 5
===== stripped OBJ file with values rounded for readability ====
g Form0
v -0.10 0.60 0 #<-- vertex #1<br /> v -0.10 0.55 0 #<-- vertex #2<br /> v -0.05 0.55 0 #<-- vertex #3<br /> v -0.05 0.60 0 #<-- vertex #4<br /> f 1 2 3 4 #<-- Proper CCW vertex winding order for Form0<br />
g Form1
v 0.049 0.60 0 #<-- vertex #5<br /> v 0.099 0.60 0 #<-- vertex #6<br /> v 0.099 0.55 0 #<-- vertex #7<br /> v 0.049 0.55 0 #<-- vertex #8<br /> f 8 7 6 5 #<-- Vertex winding order reversed to CCW by hexagon for Form1<br />
As you can see, Hexagon followed my instructions for Form0 and there's nothing "wrong" with it. But hexagon REVERSED my instructions for Form1 and rewound the quad CCW starting with my LAST vertex. This forced the normals for both quads to be facing me.
Had hexagon written my quads AS I WOUND THEM in the diagram, it would have written the following file instead:
g Form0
v -0.10 0.60 0 #<-- vertex #1<br /> v -0.10 0.55 0 #<-- vertex #2<br /> v -0.05 0.55 0 #<-- vertex #3<br /> v -0.05 0.60 0 #<-- vertex #4<br /> f 1 2 3 4 #<-- Proper CCW vertex winding order for Form0<br /> g Form1
v 0.049 0.60 0 #<-- vertex #5<br /> v 0.099 0.60 0 #<-- vertex #6<br /> v 0.099 0.55 0 #<-- vertex #7<br /> v 0.049 0.55 0 #<-- vertex #8<br /> f 5 6 7 8 #<-- My intended CW vertex winding order for Form1<br />
###
g Form0
v -0.10 0.60 0
v -0.10 0.55 0
v -0.05 0.55 0
v -0.05 0.60 0
f 1 2 3 4
g Form1
v 0.049 0.60 0
v 0.099 0.60 0
v 0.099 0.55 0
v 0.049 0.55 0
f 5 6 7 8
###
If you copy and paste the above lines between the "###"s into a text file and save it as "anotherbozo.obj" and open it in Hexagon, you'll see that Form0 is facing you while Form1 faces away from you and is thus invisible. Rotating the scene to look at the other side will then show Form1 becomes visible while Form0 disappears.
ADD:
I just got to thinking...it may further illuminate why these polys appear and diasappear as you rotate them by looking at what you see if I show my diagram from "the other side".
From the "front", Form0 is wound CCW so it's visible and Form1 is wound CW so it's invisible. If you look at the scene from the back, it's also like looking at my diagram from the back and so Form1 is now shown wound CCW and becomes visible, while Form0 appears wound CW and becomes invisible.
sknaht yrev hcum rof eht deliated noitanalpxe!