Digital Art Zone

 
   
2 of 3
2
Hexagon crashing when selecting faces
Posted: 06 June 2012 05:37 PM   [ Ignore ]   [ # 16 ]
Member
Rank
Total Posts:  250
Joined  2009-01-27
de3an - 06 June 2012 01:44 PM

Interestingly, performing the same sequence with the Mac version of Hexagon 2.5.1.79, does not produce a crash

 
We PC users don’t wanna hear that!!!  LOL
 
Seriously though, that is interesting and makes me ask: 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.
 
This is also as good a place as any to mention that the crash occurs in “msvcr90.dll” (msvcr = microsoft visual C runtime) with an error code of “0xc0000417” (invalid_cruntime_parameter).
 

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.

 Signature 

For any arguments or illustrations I give, my system specs are:
Hexagon version 2.5.1.79,  XP pro 32 bit,  pentium core2 duo,  ATI radeon 3870, 2 gigs ram

Profile
 
 
Posted: 06 June 2012 07:44 PM   [ Ignore ]   [ # 17 ]
Active Member
Avatar
RankRank
Total Posts:  359
Joined  0
afreaginname - 06 June 2012 05:37 PM
de3an - 06 June 2012 01:44 PM

Interestingly, performing the same sequence with the Mac version of Hexagon 2.5.1.79, does not produce a crash

 
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.

 Signature 

-Dean

DAZ Gallery: http://www.daz3d.com/gallery/#users/1922/

Profile
 
 
Posted: 06 June 2012 09:19 PM   [ Ignore ]   [ # 18 ]
Member
Rank
Total Posts:  250
Joined  2009-01-27
de3an - 06 June 2012 07:44 PM

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.  smile
 
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/

 Signature 

For any arguments or illustrations I give, my system specs are:
Hexagon version 2.5.1.79,  XP pro 32 bit,  pentium core2 duo,  ATI radeon 3870, 2 gigs ram

Profile
 
 
Posted: 06 June 2012 11:51 PM   [ Ignore ]   [ # 19 ]
Active Member
Avatar
RankRank
Total Posts:  359
Joined  0
afreaginname - 06 June 2012 09:19 PM
de3an - 06 June 2012 07:44 PM

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.  smile
 
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.

 Signature 

-Dean

DAZ Gallery: http://www.daz3d.com/gallery/#users/1922/

Profile
 
 
Posted: 07 June 2012 01:11 AM   [ Ignore ]   [ # 20 ]
Member
Rank
Total Posts:  250
Joined  2009-01-27
de3an - 06 June 2012 11:51 PM

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.  smile
 
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…  grin
 
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

 Signature 

For any arguments or illustrations I give, my system specs are:
Hexagon version 2.5.1.79,  XP pro 32 bit,  pentium core2 duo,  ATI radeon 3870, 2 gigs ram

Profile
 
 
Posted: 07 June 2012 11:30 AM   [ Ignore ]   [ # 21 ]
Active Member
Avatar
RankRank
Total Posts:  277
Joined  2005-09-15

The only drawback is that the user would have to be aware of which poly(s) in his model are causing the problem.

Personally, I always check using this or one of the other options.

 

Image Attachments
ngon1.jpg
 Signature 

Cheers, Fanners.raspberry

Profile
 
 
Posted: 07 June 2012 05:24 PM   [ Ignore ]   [ # 22 ]
Member
Rank
Total Posts:  250
Joined  2009-01-27
Design Acrobat - 06 June 2012 06:28 AM

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.


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…  smile

 Signature 

For any arguments or illustrations I give, my system specs are:
Hexagon version 2.5.1.79,  XP pro 32 bit,  pentium core2 duo,  ATI radeon 3870, 2 gigs ram

Profile
 
 
Posted: 07 June 2012 05:25 PM   [ Ignore ]   [ # 23 ]
Member
Rank
Total Posts:  250
Joined  2009-01-27
RedSquare - 07 June 2012 11:30 AM

The only drawback is that the user would have to be aware of which poly(s) in his model are causing the problem.

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.  smile
 

 Signature 

For any arguments or illustrations I give, my system specs are:
Hexagon version 2.5.1.79,  XP pro 32 bit,  pentium core2 duo,  ATI radeon 3870, 2 gigs ram

Profile
 
 
Posted: 07 June 2012 10:42 PM   [ Ignore ]   [ # 24 ]
Power Member
Avatar
RankRankRank
Total Posts:  1315
Joined  2008-01-01

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

Profile
 
 
Posted: 07 June 2012 11:24 PM   [ Ignore ]   [ # 25 ]
Member
Rank
Total Posts:  48
Joined  2006-08-23
Roygee - 07 June 2012 10:42 PM

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:

Image Attachments
order.jpg
Profile
 
 
Posted: 08 June 2012 12:11 AM   [ Ignore ]   [ # 26 ]
Member
Rank
Total Posts:  250
Joined  2009-01-27
Roygee - 07 June 2012 10:42 PM

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?

 
No. no…winding orders are rarely of any concern to a user since these are automatically generated by a modelling program so that the normals face “outwards” (spheres, cubes, etc) or “upwards” or “frontwards” (surfaces and planes) with respect to the viewer creating them.
 
The “winding order” is just a way of explaining what’s going on down in the depths of “meshometry”, to coin a word, when something goes wrong. However, just by knowing this, you can easily create any poly to face either direction you want, and you’ll know why.  smile
 
In practice, if you create a poly “backwards” in a mesh, it still looks like a hole in the mesh. If you turn the mesh around so that you look at the other side of it, you’ll see the poly you just made but the rest if the mesh will disappear. To fix that, you just select all the faces on the mesh and apply the “unify normals” tool, so that all the facets are facing in the same direction. If that direction happens to be backwards, then you follow it up with the “reverse normals” tool.
What’s happening “down inside” is that “unify normals” winds all the polys in the same direction without regard to whether that direction is correct or not, and “reverse normals” simply rewinds all the polys in the opposite direction of what they were.
 
Another way to accidently flip normals is to mirror and rotate half an object in strange ways in an attempt to make another half to mate with the first, as happened here in this post: http://www.daz3d.com/forums/viewreply/5331/  Here, Eyeliner also included an HXN file of her mesh so you can take a look at the problem. Also keep in mind that in “show backfaces” mode, hexagon ALWAYS makes both sides of polys visible, and in order to see their directionality you have to be in “hide backfaces” mode.
 

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

 
Essentially, yes. Remember that almost all meshes we work with are “solids”; spheres, cubes, heads, arms, aircraft bodies, gun barrels…you get the drift…  smile
 
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.
 

 Signature 

For any arguments or illustrations I give, my system specs are:
Hexagon version 2.5.1.79,  XP pro 32 bit,  pentium core2 duo,  ATI radeon 3870, 2 gigs ram

Profile
 
 
Posted: 08 June 2012 04:10 AM   [ Ignore ]   [ # 27 ]
Power Member
Avatar
RankRankRank
Total Posts:  1315
Joined  2008-01-01

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

Profile
 
 
Posted: 08 June 2012 01:15 PM   [ Ignore ]   [ # 28 ]
Member
Rank
Total Posts:  250
Joined  2009-01-27
afreaginname - 08 June 2012 12:11 AM

The “winding order” is just a way of explaining what’s going on…however, just by knowing this, you can easily create any poly to face either direction you want, and you’ll know why

 
Oh crap…EXCEPT IN HEXAGON!!!  confused
 
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…  smile

 

 Signature 

For any arguments or illustrations I give, my system specs are:
Hexagon version 2.5.1.79,  XP pro 32 bit,  pentium core2 duo,  ATI radeon 3870, 2 gigs ram

Profile
 
 
Posted: 08 June 2012 02:27 PM   [ Ignore ]   [ # 29 ]
Member
Rank
Total Posts:  250
Joined  2009-01-27

Okay, I’m back…  smile
 
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
v -0.10 0.55 0 #<—vertex #2
v -0.05 0.55 0 #<—vertex #3
v -0.05 0.60 0 #<—vertex #4
f 1 2 3 4     #<—Proper CCW vertex winding order for Form0
 
g Form1
v 0.049 0.60 0 #<—vertex #5
v 0.099 0.60 0 #<—vertex #6
v 0.099 0.55 0 #<—vertex #7
v 0.049 0.55 0 #<—vertex #8
f 8 7 6 5     #<—Vertex winding order reversed to CCW by hexagon for Form1
 
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
v -0.10 0.55 0 #<—vertex #2
v -0.05 0.55 0 #<—vertex #3
v -0.05 0.60 0 #<—vertex #4
f 1 2 3 4     #<—Proper CCW vertex winding order for Form0
g Form1
v 0.049 0.60 0 #<—vertex #5
v 0.099 0.60 0 #<—vertex #6
v 0.099 0.55 0 #<—vertex #7
v 0.049 0.55 0 #<—vertex #8
f 5 6 7 8     #<—My intended CW vertex winding order for Form1
 
###
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.
 

Image Attachments
winding.jpg
winding_R.jpg
 Signature 

For any arguments or illustrations I give, my system specs are:
Hexagon version 2.5.1.79,  XP pro 32 bit,  pentium core2 duo,  ATI radeon 3870, 2 gigs ram

Profile
 
 
Posted: 08 June 2012 07:41 PM   [ Ignore ]   [ # 30 ]
Active Member
Avatar
RankRank
Total Posts:  335
Joined  2006-02-03

sknaht yrev hcum rof eht deliated noitanalpxe!

Profile
 
 
   
2 of 3
2