PDA

View Full Version : NGons don't render in OpenGL correctly?



Nicolas Jordan
11-13-2012, 10:03 AM
I run into this problem all the time, it's very annoying and it makes it very hard to see exactly what your modeling especially on complex arch viz models. Does anyone know if this is just a glitch/bug or is there a setting I need to turn on/off so that Ngons render correctly in OpenGL?

Sensei
11-13-2012, 12:06 PM
Attach above object. So we can check here. In Modeler or Layout or both?

If it would be LW issue, then everybody would see it, right?
If it's OpenGL driver issue, then only people with buggy driver will see it.
But NewTek can make their own triangulating routine, and no rely on driver tessellation routine..

Lewis
11-13-2012, 12:19 PM
What Lw version are you using ?

We had one BUG what behaved similarly when you had 2-point polys and GLSLS mode in modeler. But form what I remember it was fixed in 10.x era.

Nicolas Jordan
11-13-2012, 01:57 PM
Here is a NGon object that gives me the OpenGL problem. I'm using LW modeler 11.0.2 at the moment but this problem goes back to 10.1 but does not occur in 9.6. I have a Nvidia GTX 560M with the latest drivers. This problem only seems to happen when the NGon has 90 degree angles in it.

Lewis
11-13-2012, 02:15 PM
Ahh letter Ngons, yes that's long standing BUG/problem in 10/11.

I say FOG it to system and let them FIX it :).

Sensei
11-13-2012, 02:35 PM
It's not bug, so they can't fix it..

It's illegal polygon - polygon that has holes inside...

Attached poly is ever worse - reusing single vertex multiple times by single polygon..

Nicolas Jordan
11-13-2012, 02:35 PM
This object looks ok in both LW 9.6 and modo openGL. I use lwcad interactive boolean lots and end up with this problem often because of that. I guess I could try modeling things a bit differently but it just not as fast as being able to punch holes in large Ngons with LWCAD booleans. In the end the geometry renders fine but just very annoying to look at and figure out where the real faces are in a complex model.

Lewis
11-13-2012, 02:46 PM
It's not bug, so they can't fix it..

It's illegal polygon - polygon that has holes inside...

Attached poly is ever worse - reusing single vertex multiple times by single polygon..

Open up Lw 9.6 and check before you jump and scream it's pure user error. At first If is Illegal then application (modeler) shouldn't make it in first place. If it can't handle it why ts making it ? This kind of issues happen all the time with TEXT tool in LWM 10/11. It should offer "quadriangle" or "Triangle" all at creation of text like some other apps if is not able to handle them (Ngons) :).

Also as Nicolas says LWCad makes these kind of things all the time in MODELER and modeler cant' show them correctly so it's surely modeler openGL problem 'coz 9.x shows it fine with VBO/MTS on.

Sensei
11-13-2012, 02:51 PM
Here is better example of triangulating issue with proper polygon, but heavy concave polygon

109130.

Nicolas Jordan
11-23-2012, 11:08 AM
I finally took the time to submit a bug report for this problem so hopefully they will have it fixed for 11.5.

jwiede
11-24-2012, 02:22 PM
It'd be great if it was fixed in 11.5, but if they've not already fixed it, I suspect it might be too late to fix in time. We'll see.

Chrusion
11-24-2012, 03:21 PM
The work around for me is to Triangulate the offending poly, deselect the nearest "leg" or offending area of concave vertex forming polys (usually just two adjacent tris) and Merge the remaining tris back to a "legal" n-gon and then select the pair of tris in the concave portion or leg of a letter and merge.

I find it strange that you can make a letter T or H and it displays correctly in OGL, but as soon as you Extrude, BAM! the rear face (which is just a mirrored version of the front face) exhibits this "illegal" OGL annoyance.

Try this test on such an offending poly... simply mirror it with any amount of separation distance. The copy most likely will display correctly. So, how is the one poly "illegal" and the other not?

jwiede
11-24-2012, 07:24 PM
I find it strange that you can make a letter T or H and it displays correctly in OGL, but as soon as you Extrude, BAM! the rear face (which is just a mirrored version of the front face) exhibits this "illegal" OGL annoyance.

Try this test on such an offending poly... simply mirror it with any amount of separation distance. The copy most likely will display correctly. So, how is the one poly "illegal" and the other not?
That's just it, I'm not convinced there is anything "illegal" about the geometry, at least in the text cases. The inconsistency in behavior just furthers the argument that it's caused by some subtle bug in LW's OGL setup code, rather than something wrong with the geometry. If the problem is the geometry somehow, it's still a LW bug, as LW shouldn't create bad geometry in text prims, but I'm more inclined to believe the issue is in the OGL setup code.

Sensei
11-24-2012, 07:28 PM
I find it strange that you can make a letter T or H and it displays correctly in OGL, but as soon as you Extrude, BAM! the rear face (which is just a mirrored version of the front face) exhibits this "illegal" OGL annoyance.

Because it depends on which point is the first one in polygon...

109356

109357

Sensei
11-25-2012, 08:08 AM
That's just it, I'm not convinced there is anything "illegal" about the geometry, at least in the text cases. The inconsistency in behavior just furthers the argument that it's caused by some subtle bug in LW's OGL setup code, rather than something wrong with the geometry. If the problem is the geometry somehow, it's still a LW bug, as LW shouldn't create bad geometry in text prims, but I'm more inclined to believe the issue is in the OGL setup code.

N-gons are programmers nightmare worser than quantum physics for scientists ;)

There are two possibilities:
- LW is triangulating by itself, and just sends triangles to OpenGL - is so, any single n-gon should look exactly the same regardless of used gfx card, gfx drivers or platform win/mac or 32/64. Same display error on all of them.
- LW is not triangulating by itself, and rely on OpenGL to do it; on one platform, on one gfx, on one gfx driver, it will look bad, on other might look correctly. OpenGL is just specification, not source code. Anybody can write their own opengl32.dll Issue present in one implementation will not be present in second implementation - written by somebody else. It'll have other issues instead.

LW SHOULD create any n-gon whether or not it can display it - LW has absolute no idea whether from human user point of view it looks bad or not.
Badly looking n-gon can be split manually by user. But it must be possible to make it in the first place to be able to split.. ;)

IMHO it's impossible to make triangulating routine that works in the all situations.

Here is super extreme situation of n-gon that can't be handled:
109362

Even after deleting some points, it's not working:
109363

Lewis
11-25-2012, 08:14 AM
Sensei your example is much more exaggerate, problem with TEXT/letters that they are FLAT/2D when LW creates them so it shouldn't be such a problem/error to show them as it happens and by comparison to Lw 9.x where it's NOT showing that error with same Letter/Text makes it no programers dilemma/nightmare but pure BUG :).

If something works in modeler 9.x it should work same or better in 11.x and not worse - period.

:)

Sensei
11-25-2012, 08:47 AM
Sensei your example is much more exaggerate, problem with TEXT/letters that they are FLAT/2D when LW creates them so it shouldn't be such a problem/error to show them as it happens and by comparison to Lw 9.x where it's NOT showing that error with same Letter/Text makes it no programers dilemma/nightmare but pure BUG :).


For computer there is no difference between them - mine example, triangle, quad, or 5-point polygon, or s, t, h letter is just the same array of vectors x,y,z...
Computer has no bloody idea it's flat.
Procedure can check whether one axis in all vectors is same value and then do some optimization - switch to different branch of code.
But user will move any point, or group, rotate, scale or whatever, and there will be introduced unpredictable little floating point error, and axis will be not 0.0 for example, but 0.0000001 or so, and whole optimized routine won't be called anymore, and general routine will be called.. Routine that must handle all 3 axes, without doing any 2d flat optimizations.


If something works in modeler 9.x it should work same or better in 11.x and not worse - period.

Tests don't prove your theory..

109364

109365

Same lwo, same issue.

Lewis
11-25-2012, 08:59 AM
Tests don't prove your theory..


Open up Nicks Test mesh and you'll see it proves so it's not Theory but FACT :).

Sensei
11-25-2012, 09:20 AM
109367

Pure luck.
Rotate it 46 degree or more in Y axis, and you have exactly the same effect as in LW v11.0.3..

For 90% it's OpenGL triangulating, and not LW..

jwiede, show how it looks in v9.6 and v11 on Mac. You have totally different opengl code than us, GeForce Windows users. Rotate it in all axes.

zardoz
11-25-2012, 09:43 AM
it also has to do with the coordinates. It's about concavity and convexity I guess. Lightwave triangulates in a way that creates these errors. If you move one of those points in one axis about 1um it goes away.
But I work with max and xsi and it has the same problems...

Lewis
11-25-2012, 11:04 AM
109367

Pure luck.


I'd like to have that "luck" in 11.x also then 'coz i see it much more (problem) than it was is in 9.6 :).

So we should write to NT and tell them to turn ON LUCK in Lw 11.x also? Can we get "Do you feel lucky today" checkmark in prefs :D :?

BTW this mesh works fine in 3DSMAX also no matter how you rotate it - i just tested.

zardoz
11-25-2012, 12:35 PM
yes but what I said is that max and xsi also have this kind of problems....not necessarily with the same meshes

Lewis
11-25-2012, 01:13 PM
yes but what I said is that max and xsi also have this kind of problems....not necessarily with the same meshes

Maybe but not in this case, also we have LOT more so called "junk geometry" than in MAX, there is no 1point or 2 point polys (which is nonsense anyway 'coz if you have 1 point that's point and if you have 2 points that line - neither quality for polygon in real :)) after welding in MAX so there is much less chances of such weird Ngons/OGL problems :).

zardoz
11-25-2012, 02:54 PM
yes, but our '2 point polys' have disadvantages and advantages, right? how many times we have used those operations that generate 2 point polys to use in some way?

Lewis
11-25-2012, 02:59 PM
yes, but our '2 point polys' have disadvantages and advantages, right? how many times we have used those operations that generate 2 point polys to use in some way?

Purely 'coz LW is unable to render splines, if we could render splines we would not need 2-point polys at all :). So it's more limitation/workaroudn that any advantage ;).

zardoz
11-25-2012, 03:20 PM
as always ahah

jwiede
11-25-2012, 03:43 PM
jwiede, show how it looks in v9.6 and v11 on Mac. You have totally different opengl code than us, GeForce Windows users. Rotate it in all axes.
Is that the mesh in Lewis' post? If not, what font was used? Headed in to office, but will check and post screen-grabs this evening.

jwiede
11-25-2012, 03:53 PM
Double post, dang "It's :43 after the hour, and time for the forum to halt and catch fire."

Sensei
11-25-2012, 08:20 PM
Is that the mesh in Lewis' post? If not, what font was used? Headed in to office, but will check and post screen-grabs this evening.

Post #18 has attached lwo.
Rotate (using tool) it in 9.x and 11.x

jwiede
11-26-2012, 01:39 AM
Post #18 has attached lwo.
Rotate (using tool) it in 9.x and 11.x
First two are Mac 9.6 (lighter gray bg), second two are Mac 11.0.3 (darker gray bg). For ref, 10.1 behaves same as 11.0.3, 9.6.1 same as 9.6, and CORE wasn't in a mood to run today (it's moody that way).

109377109376109375109374

BTW, neither C4D R12, R14, nor modo 601 had any problems with the LWO either, their viewports displayed it same as in LW 9.6. At this point, I'm with Lewis on this: Whatever changed between 9.6 and 10+ in OGL setup has introduced a bug, demonstrated by LWO as shown. That third-party implementation of LWO reading (C4D esp.) gives precise same result as 9.6 without problem is kind of strong evidence the fault isn't in the object/geometry, IMO. C4D R14 pics:

109378

Sensei
11-26-2012, 01:45 AM
On Win32 it's starting looking bad in LW v9.6 after rotating in Y axis by -46 degree.

http://forums.newtek.com/attachment.php?attachmentid=109367&d=1353860217

Try rotating the same amount.
Because you spin viewport instead of rotating geometry using Rotate tool..

Lewis
11-26-2012, 02:02 AM
On Win32 it's starting looking bad in LW v9.6 after rotating in Y axis by -46 degree.

http://forums.newtek.com/attachment.php?attachmentid=109367&d=1353860217

Try rotating the same amount.
Because you spin viewport instead of rotating geometry using Rotate tool..

Ok, BUT why only in LWM ? In MAX i can rotate it to any angle and as confirmed by jweide in C4D and modo works fine also ? Do they have different OpenGL ?

jwiede
11-26-2012, 02:07 AM
I'm busy working in modo atm, will try rotations in LW later. In both C4D and modo it displayed perfectly rotated in any/all axes (the object, not viewport) and also rotating the viewport around it in any/all axes. If C4D and modo are able to do a better job of drawing LWO geometry than LW itself, that's more than enough justification to fix LW in my book.

jwiede
11-26-2012, 02:19 AM
Do they have different OpenGL ?
Only in terms of the code that sets up the geometry handed to the OGL stack, not in OGL itself. That modo and C4D (and MAX, now) all are able to display the LWO just fine, through rotations of both object and viewport (though there really shouldn't be any difference between the two, OGL-wise) is really solid evidence that the problem rests in LW's OGL setup code.

Ultimately, LW should be displaying the LWO as well as competitors (if not better), and that it doesn't is, IMO, a sign of an issue that needs to be addressed.

BTW, tessellation of concave/non-planar/self-intersecting n-gons is definitely the responsibility of the host software, not OpenGL. If you want to get into GLU and gluTess() that's a different discussion, but the rules w.r.t. GL_POLYGON are quite clear, so I don't really see how this is supposed to be an OpenGL issue.

Sensei
11-26-2012, 03:11 AM
OpenGL code



GLfloat positions[] =
{
0,2.76648,1.8034,
0,2.76648,-1.8034,
0,0,1.49859,
0,0,0.584194,
0,2.61411,1.8034,
0,2.61407,1.49859,
0,2.61407,1.34619,
0,2.61407,0.736598,
0,1.24249,0.736598,
0,1.24249,1.34619,
0,0,1.34619,
0,1.09009,1.34619,
0,1.09009,0.736598,
0,0,0.736598,
0,2.61407,0.584194,
0,2.61407,-1.8034,
};

GLuint points[] =
{
16,15,4,14,13,12,11,3,6,7,10,9,8,7,6,5,1,2,
0,
};
glBegin( GL_POLYGON );
for( int i = 0; ; i++ )
{
GLuint index = points[ i ];
if( index == 0 ) break;
index--;
glColor3f( 1.0, 0.0, 0.0 );
glVertex3fv( &positions[ index * 3 ] );
}
glEnd();


Generates this:

109379

ps. That gave me idea for another plugin- exporting object directly to OpenGL C/C++ source code... ;)

jwiede
11-26-2012, 03:55 AM
I'm not sure what your point is with that, other than proving that per OGL spec "undefined behavior" is just that... undefined.

Nicolas Jordan
11-26-2012, 11:09 AM
On Win32 it's starting looking bad in LW v9.6 after rotating in Y axis by -46 degree.

http://forums.newtek.com/attachment.php?attachmentid=109367&d=1353860217

Try rotating the same amount.
Because you spin viewport instead of rotating geometry using Rotate tool..

I never ran into the OpenGL issue in 9.6 mainly because when modeling stuff for arch-viz almost every NGon that I create is oriented to the world on a 90 or 45 degree angle. I rarely have polygon faces oriented at a weird angle like 46 degrees. Even if this was fixed back to the way it functioned in 9.6 it would help a great deal and would be much better than it is currently in LW11.

Sensei
11-26-2012, 11:33 AM
It's probably caused by dividing by 0.0...

Bug appears:
109386

Rotated 0.0001 degree, and it's gone:
109385

Such things happen when there are done calcs like

( x1- x0 ) / ( y1 - y0 ) when point y0=y1...
dividing by 0 can't be done, so there is issue..

Moved selected point by 10 micro meter in Y, and again gone:
109387

Chrusion
11-26-2012, 05:45 PM
So, is this divide by zero in the OGL driver or the OGL setup code in LW? If in LW, then it seems a simple fix would be to add 1 um to both numerator and denominator results to prevent any zeros.

Nicolas Jordan
12-04-2012, 10:01 AM
Screen grabs of this problem rearing it's ugly head on the current project I'm modeling but looks fine in 9.6. I think I might go back to modeling in 9.6 for now even though there are some handy modeling tools in LW11.

Lewis
12-04-2012, 10:22 AM
I think I might go back to modeling in 9.6 for now even though there are some handy modeling tools in LW11.

I wonder what modeling tools you miss in 9.6 form LW11 ?

Nicolas Jordan
12-04-2012, 10:26 AM
I wonder what modeling tools you miss in 9.6 form LW11 ?

Not really very much. I use "align to plane" sometimes but most projects I never need it and LWCAD has pretty much everything I need anyway.

Lewis
12-04-2012, 10:41 AM
Not really very much. I use "align to plane" sometimes but most projects I never need it and LWCAD has pretty much everything I need anyway.

There is free plugins that do that in case you really need it (Cplane, JettoLocal...)

Nicolas Jordan
12-04-2012, 10:50 AM
There is free plugins that do that in case you really need it (Cplane, JettoLocal...)

I didn't know about those plugins. Thanks Lewis, I will have to take a look at them.

probiner
12-07-2012, 05:31 PM
Since we are talking of stuff behaving not as expected. Here goes a sample of a cube having it's points being moved around and the Quad Diagonal (the one that it's chosen to triple it) changing.

Couldn't replicate that in other apps.

For sure you can say no on would have bad quads like that... But when you are deforming a mesh you can't keep track of all geometry at all times. Though I don't know if the same thing happens in Layout. From sending this the attached object to Layout, all looked fine.

I also noticed that UV maps when they don't match the respective polygons shape in 3D space, some tearing takes places. When the Quad Diagonal changes also does the mapping.

Anyway, probably a non issue :D

Cheers

Sensei
12-07-2012, 05:38 PM
I was told it will be fixed in 12.
https://fogbugz.newtek.com/default.asp?53387_aqis1ckrdk86k0fl

probiner
12-07-2012, 05:49 PM
Cheers Sensei