PDA

View Full Version : Texturing Quads



Richard Hebert
01-03-2010, 11:25 AM
Is it customary to triple a quad mesh before creating a UV map or does it matter as long as no geometry is moved? What's the consensus among the industry? Might be a silly question but still learning. Thanks for insight.

Richard

biliousfrog
01-03-2010, 11:58 AM
Is it customary to triple a quad mesh before creating a UV map or does it matter as long as no geometry is moved? What's the consensus among the industry? Might be a silly question but still learning. Thanks for insight.

Richard

No need to triple, you can do that after it's UV'd if you need to but unless you have to just keep it as simple as possible.

Richard Hebert
01-03-2010, 12:42 PM
Thanks for the 'heads up'.

Captain Obvious
01-03-2010, 06:18 PM
In Lightwave, you should never ever turn polygons with four or more sides into triangles, unless there's a very specific issue you need to fix.

In Lightwave, triangles use more memory than quads, render more slowly, and have worse smoothing. Also, UV mapping a triangle mesh is really hard.

Richard Hebert
01-03-2010, 07:54 PM
Every professional model that I've downloaded so far has been triangulated. Granted, my experience with professional modeling is very limited. Is there a reason that these have been triangulated rather than left as original quad mesh? This is in general of course. Thanks for the input, btw. Every little bit helps me to understand the industry that much more.

Captain Obvious
01-03-2010, 08:20 PM
There are several reasons for why the mesh might be turned into triangles:

1: Modelled in something that either doesn't support anything else, or can't export anything else.

2: It's a scan of a real object.

3: The mesh was sculpted or modelled with displacement mapping or something such, and then frozen for export.

4: "Locking" the model. In order to limit the usefulness, the model has been turned into triangles.

5: The modeller ain't so professional.

OnlineRender
01-04-2010, 12:53 AM
or its for game engine !

jin choung
01-04-2010, 02:23 AM
4: "Locking" the model. In order to limit the usefulness, the model has been turned into triangles.


right.

this seems to be THE OVERRIDING REASON with most "professional" downloaded geometry. they do it to f you up in your ability to further manipulate it. things like slicing and selecting edge loops and rings are complicated by having triangles (i.e. you can't do it) - not to mention that triangles produce ugly subdivision results.

as said, quads are more edit friendly and there is absolutely no advantage in triangulating specifically for texturing. the only real constraint in texturing is that the "aspect ratio" of an individual polygon as viewed from its normal (in 3d space) be maintained in uvspace - this eliminates STRETCHING.

of course, this is not 100% possible unless the model is taken apart poly by poly and is mostly UNCONNECTED in uvspace. in other words, unless you chop an animal pelt into very small sections (analagous to individual polys), there's no way that you can pin it flat to a board without SOME stretching of the skin.

but the goal is to do as little stretching as possible and to keep most of the egregious stretching and seams (using same animal skin example, you can't pin it flat to a board without slicing seams SOMEWHERE) to places that will not be seen.

so triangulation may be necessary for some other reason - game asset, etc. it is NOT necessary, standard or desirable to triangulate specifically for uv mapping.

jin

p.s. there are some good freeware plugins at flay.com that will go a long way toward quadrangulating triangulated meshes... you'll still have to do some hand merging but it gets you a good way there if you need to start editing a stock mesh. "merge trigons" is one such plugin.

biliousfrog
01-04-2010, 02:34 AM
1: Modelled in something that either doesn't support anything else, or can't export anything else.



It's my understanding (perhaps wrongly) that all 3d applications must work in triangles and it is only the editable mesh that is displayed in any other way...which is why Sub-D meshes in Layout display as triangles in wireframe mode and why highly non-planar polys will often have triangle shaped glitches. When the mesh is rendered it is converted into triangles to ensure that the polygons are all planar. When exporting to/from other applications the mesh will sometimes become triangulated depending on the output format.

jin choung
01-04-2010, 02:43 AM
It's my understanding (perhaps wrongly) that all 3d applications must work in triangles and it is only the editable mesh that is displayed in any other way...which is why Sub-D meshes in Layout display as triangles in wireframe mode and why highly non-planar polys will often have triangle shaped glitches. When the mesh is rendered it is converted into triangles to ensure that the polygons are all planar. When exporting to/from other applications the mesh will sometimes become triangulated depending on the output format.

it could still be entirely quad or ngon within the app (lw, maya, etc).

and actually, EVIDENCE of that is shading errors on quads and ngons! if it was all triangles all the time, there would never be shading errors (which are tied to a poly's NORMALS which are unequivocal when triangles because they CANNOT be non planar... but can be distorted when you have nonplanar faces like with quads and ngons).

also, the fact that you can do things like ring and edge loop select on quads and not on triangles is indicative that they are not the same... and also, the fact that the subdivision results are different.

they are NOT always "treated as triangles" in an app.


usually, triangulation is tied to RENDERING - either to file for final render or in opengl or direct3d for real time rendering to screen (which is why game assets would be triangulated... why leave that as an extra step the game engine has to do for EVERY frame it renders? if you triangulate ahead of time, that is one step not required before asset can be drawn to screen).

lw and maya and most renderers convert everything (quad polys as well as subds and nurbs surfaces) to triangles internally before rasterizing.

RENDERMAN does not - it dices into something it calls micropolys which are quads whose size is frequently tied to some percentage of 1 pixel of final render resolution.

realsoft3d does not tesselate either and it directlly rasterizes things like nurbs surfaces into pixels.

jin

Lightwolf
01-04-2010, 05:24 AM
lw and maya and most renderers convert everything (quad polys as well as subds and nurbs surfaces) to triangles internally before rasterizing.

Lightwave certainly doesn't. There is no internal triangular geometry when rendering.

SubDs are different, but their subdivision isn't tied to rendering per-se either.

Cheers,
Mike

Captain Obvious
01-04-2010, 05:26 AM
lw and maya and most renderers convert everything (quad polys as well as subds and nurbs surfaces) to triangles internally before rasterizing.
Oddly enough, Lightwave's renderer doesn't. Neither classic camera nor the new ray tracing render engine converts anything to triangles except subdivision surfaces. It actually renders n-gons as n-gons.

Captain Obvious
01-04-2010, 05:30 AM
It's my understanding (perhaps wrongly) that all 3d applications must work in triangles and it is only the editable mesh that is displayed in any other way...which is why Sub-D meshes in Layout display as triangles in wireframe mode and why highly non-planar polys will often have triangle shaped glitches.
Not quite. Some applications store polygons internally as triangles, but 'hide' certain edges from the user (I believe this is how 3dsmax works, for example). However, ALL 3D applications display the actual shading of the polygons as triangles, because it's the only thing Direct 3D and OpenGL supports. If you have an all-quad mesh in Modeler, any operations you apply to it will be done as quads, and you will see the wires as if it was quads, but the OpenGL display is triangles.

Sensei
01-04-2010, 01:29 PM
OpenGL API always supported quads and even >4 polygons f.e.
glBegin( GL_POLYGON );
glVertex3f( 0, 0, 0 );
glVertex3f( 1, 0, 0 );
glVertex3f( 1, 1, 0 );
glVertex3f( 0, 1, 0 );
glVertex3f( -0.5, 0.5, 0 );
glEnd();

But if gfx driver can't handle this directly it has to be triangulated/optimized to 3-4 polys before sending to driver, so for 3d application it's better not rely on built-in triangulation method and just do it. This way application has control over when triangulation is done- OpenGL would do it while spitting viewport, but application would do it just once while editing mesh and then just use what is generated in vertex/poly buffer. Although it's not required while using above glBegin()/glEnd() pair.

OnlineRender
01-04-2010, 01:59 PM
u learn something new everyday

caesar
01-04-2010, 03:37 PM
OpenGL API always supported quads and even >4 polygons f.e.
glBegin( GL_POLYGON );
glVertex3f( 0, 0, 0 );
glVertex3f( 1, 0, 0 );
glVertex3f( 1, 1, 0 );
glVertex3f( 0, 1, 0 );
glVertex3f( -0.5, 0.5, 0 );
glEnd();


This kind of post just makes me remember how dumb I am...

Captain Obvious
01-05-2010, 08:20 AM
But if gfx driver can't handle this directly it has to be triangulated/optimized to 3-4 polys before sending to driver, so for 3d application it's better not rely on built-in triangulation method and just do it.
Oh right. You wouldn't happen to know if Nvidia or ATI graphics drivers support this? Because I've never seen any Direct 3D or OpenGL application render anything other than triangles.

Sensei
01-05-2010, 09:40 AM
Because I've never seen any Direct 3D or OpenGL application render anything other than triangles.

How can you know what is used internally without looking at 3d application source code (of course except such obvious cases as using only triangles in whole application.. ;) ) ?

Drawing convex >4 polygon in one go is very easy. There are at least two ways, that don't require conversion to triangles:
http://en.wikipedia.org/wiki/Triangle_strip
http://en.wikipedia.org/wiki/Triangle_fan

Drawing f.e. circle, ellipse or disc using triangle fan method is just one command. No tripling in 3d application at all.

Problematic >4 polygons are concave.

Even mine renderer is using quads internally in ray-tracing, because they eat less memory and what is more important have less elements in KD-Tree (without tripling or using triangle fan/strip).. If quad is non-planar, tripling it will generate two triangles with completely different normal vectors.

Captain Obvious
01-05-2010, 01:32 PM
How can you know what is used internally without looking at 3d application source code (of course except such obvious cases as using only triangles in whole application.. ;) ) ?
Oh, it's simple. Look at a highly non-planar quad from the sides, and see what it looks like. In every single 3D software I have ever used, you can *clearly* see the triangle shapes. Actually turning it into triangles never changes the appearance. With a renderer that renders quads and n-gons directly (like Lightwave), turning a quad or n-gon into triangles does change the appearance.

Also, many 3D softwares have an option for displaying the OpenGL polygon count *in all the applications I've tried, this is the number of triangles.

warmiak
01-05-2010, 02:47 PM
How can you know what is used internally without looking at 3d application source code (of course except such obvious cases as using only triangles in whole application.. ;) ) ?



Uhh .. because the underlying hardware doesn't support anything else ?

Lightwolf
01-05-2010, 03:20 PM
Uhh .. because the underlying hardware doesn't support anything else ?
Well, how do you know without dissecting it on a hardware level, especially as modern GPUs are extremely flexible (-> programmable)? The native APIs surely support more than just triangles.

Cheers,
Mike

Sensei
01-05-2010, 04:00 PM
Oh, it's simple. Look at a highly non-planar quad from the sides, and see what it looks like. In every single 3D software I have ever used, you can *clearly* see the triangle shapes. Actually turning it into triangles never changes the appearance.

It doesn't prove anything. It means only that somebody, somewhere displayed triangles, but knowledge who and when is unknown.

There are at least 4 possible cases:
- 3d application is using all the time triangles.
- 3d application is using polygons but while displaying triangulate for faster spinning viewport.
- 3d application is using polygons and sends them as-is to OpenGL. Then OpenGL detects that lower level gfx driver is supporting only triangles. OpenGL higher level is doing this triangulation as a RESULT of not supporting n-gons by lower level driver directly.
- 3d application is using polygons and sends them as-is to OpenGL. Then they're send to lower level driver also as polygons. And triangulation of polygon is done entirely by lower level gfx driver maybe even by hardware.


With a renderer that renders quads and n-gons directly (like Lightwave), turning a quad or n-gon into triangles does change the appearance.

Actually LW renderer has to convert >4 polygons to 3 and 4 polygons internally. Because LWShaderAccess and LWNodalAccess structures have only buffer for 4 vertexes with position, LWPntID and weight. Calculating weights of >4 polygon at render time, while checking ray-polygon intersection would be very ineffective.

caesar
01-05-2010, 04:39 PM
It doesn't prove anything. It means only that somebody, somewhere displayed triangles, but knowledge who and when is unknown.

There are at least 4 possible cases:
- 3d application is using all the time triangles.
- 3d application is using polygons but while displaying triangulate for faster spinning viewport.
- 3d application is using polygons and sends them as-is to OpenGL. Then OpenGL detects that lower level gfx driver is supporting only triangles. OpenGL higher level is doing this triangulation as a RESULT of not supporting n-gons by lower level driver directly.
- 3d application is using polygons and sends them as-is to OpenGL. Then they're send to lower level driver also as polygons. And triangulation of polygon is done entirely by lower level gfx driver maybe even by hardware.



Actually LW renderer has to convert >4 polygons to 3 and 4 polygons internally. Because LWShaderAccess and LWNodalAccess structures have only buffer for 4 vertexes with position, LWPntID and weight. Calculating weights of >4 polygon at render time, while checking ray-polygon intersection would be very ineffective.

Ok, now I feel miserable....

Captain Obvious
01-05-2010, 05:42 PM
- 3d application is using polygons but while displaying triangulate for faster spinning viewport.
- 3d application is using polygons and sends them as-is to OpenGL. Then OpenGL detects that lower level gfx driver is supporting only triangles. OpenGL higher level is doing this triangulation as a RESULT of not supporting n-gons by lower level driver directly.
- 3d application is using polygons and sends them as-is to OpenGL. Then they're send to lower level driver also as polygons. And triangulation of polygon is done entirely by lower level gfx driver maybe even by hardware.
Yeah, those are all reasonable theories. But if you read the post I made that started this whole thing, you'll notice that I said that the viewport display is triangles. I was under the impression it wasn't possible with current drivers/hardware to display anything else, but I really don't know for certain. It can be anything, really, but the fact still remains that every piece of 3D software I've ever used has displayed triangles in the viewports.




Actually LW renderer has to convert >4 polygons to 3 and 4 polygons internally.
Hm, really? Then why does memory usage increase when splitting up the polygons manually before the render?

warmiak
01-06-2010, 05:45 AM
Well, how do you know without dissecting it on a hardware level, especially as modern GPUs are extremely flexible (-> programmable)? The native APIs surely support more than just triangles.

Cheers,
Mike

Because it makes sense from hardware point of view ... as far as being programmable ... you still are able to insert your code only at predefined points in terms of rendering API so I am not sure what is your point here. As far as native APIs ... that's pretty meaningless because for instance DirectX can render stuff without any hardware whatsoever.

Lightwolf
01-06-2010, 06:22 AM
Because it makes sense from hardware point of view ...
Does it? That depends to a large extent on how it works internally, and if they do use a simple Z-Buffer based approach then it can actually make sense to support polygons.

as far as being programmable ... you still are able to insert your code only at predefined points in terms of rendering API so I am not sure what is your point here.
Erm, no. How are the actual drivers implemented? Do they rely on fixed, hardware based pipelines on the chip or is the DirectX/OpenGL API itself implemented on the GPU?
I'm not talking about injecting code through the API, but the API implementation itself.

I suppose it'd be worth a try to see what happens if you send skewed quads directly to OpenGL.

Cheers,
Mike

warmiak
01-06-2010, 08:25 AM
Does it? That depends to a large extent on how it works internally, and if they do use a simple Z-Buffer based approach then it can actually make sense to support polygons.


It is not just z-buffers but other things like clipping, rasterization.... there is a substantial difference between attempting to perform these operations on triangles and on arbitrary polygons.



. Erm, no. How are the actual drivers implemented? Do they rely on fixed, hardware based pipelines on the chip or is the DirectX/OpenGL API itself implemented on the GPU?


I don't really care much for the CPU side of things ... there is nothing there you couldn't do yourself and whatever is being run there doesn't benefit from hardware acceleration anyway ... I am talking about running your own code on the actual GPU ... here you are still fairly limited in what you can do.

As far as how much of the driver code is implemented on the GPU ... not much really ... both APIs are mostly a translation layer which implies that whatever an api like OpenGL is offering above what you get in DirectX, is pretty much all done on the CPU which, again, doesn't buy you anything in terms of performance.

Richard Hebert
01-08-2010, 12:28 PM
I'm going to cease asking questions, it has a tendency to start wars.

JeffrySG
01-08-2010, 03:55 PM
This kind of post just makes me remember how dumb I am...

lol, :agree:

Andyjaggy
01-08-2010, 04:14 PM
Yeah all the information you need to know was on the first page of this thread.

Basically avoid triangles at all costs. The make modeling, UV mapping, and just about everything else a pain in the butt. Even if the render engine does convert to triangles at render time you don't want to deal with them.

I seem to remember reading that Lightwave render engine is unique in that it is the only one that does NOT convert to triangles when rendering. Any truth to that?

Captain Obvious
01-08-2010, 06:55 PM
I seem to remember reading that Lightwave render engine is unique in that it is the only one that does NOT convert to triangles when rendering. Any truth to that?
I don't know if it's the only one, but yes there is some truth to that.

Andy Meyer
01-18-2010, 03:40 PM
good objects that are not poorely converted are "all quads".
non-planar polys should be triangulated.

Captain Obvious
01-18-2010, 04:39 PM
non-planar polys should be triangulated.
Unfortunately, it depends on *how* non-planar they are, as well as the number of vertices. Quads that are only somewhat nonplanar should certainly not be turned into triangles. For example, if you bevel all the edges on a cube you end up with nonplanar quads on the corners. You really don't need to turn these into triangles.

81211